Posts Tagged With '.NET' RSS Feed

Very Quick Guide To DLinq: Part 3 (LIKE, IN, DATEDIFF)

pheaven — Wed, 30 Apr 2008 06:50:28 -0700

Much of the time, it's fairly straightforward to express an SQL query in Linq instead. However, there are some things that aren't quite so clear how to do. In this article, I'll take a look at some of those.

=== LIKE ===
There are a couple of ways to replace LIKE. If you just want to directly use LIKE, then you can do so using the SqlMethods class. To use this, you must add the following using declaration at the top of the file:

using System.Data.Linq.SqlClient;

Then we can use it like this:

var Result = from Book in DB.BookResources
             where SqlMethods.Like(Book.Title, "%java%")
             select Book;

This will create an SQL query that locates all books containing "java" (case-insensitively). Interestingly, you can also do the following:

var Result = from Book in DB.BookResources
             where Book.Title.Contains("java")
             select Book;

And it is equivalent. This is useful and results in the same SQL, but also a tad confusing: you get the case sensitivity (or default lack thereof) configured in the database, even though normally in C# code outside of a Linq query this method is case sensitive.

You can also use the .StartsWith and .EndsWith methods of a string, which can replace some LIKE queries a little more readably. They have the same case quirks, though (under the hood, they all compile down to a LIKE query).

=== IN ===
Our example table has a rating field that allows us to store a book's rating out of ten. We want to get those books scoring between 7 and 10 points (or some other arbitrary List of scores). We can use the List's Contains method inside the Linq query, which will cause it to generate an IN query in the SQL.

var GoodRatings = new List<short>() { 7, 8, 9, 10 };
var Result = from Book in DB.BookResources
             where GoodRatings.Contains(Book.Rating)
             select Book;

Nice and easy.

=== DATEDIFF ===
The SqlMethods class also contains various methods to allow us to express the SQL DATEDIFF built-in. In the following example, we select all books that were added to the database in the last 30 days.

var Result = from Book in DB.BookResources
             where SqlMethods.DateDiffDay(Book.EntryDate, DateTime.Now) <= 30
             select Book;

There are a variety of related methods available, including DateDiffYear, DateDiffHour and so forth, depending what unit of time you want to get the result back in. These compile to an SQL DATEDIFF query.

Note that methods on TimeSpan objects are not translated by Linq, therefore you can not write:

var Result = from Book in DB.BookResources
             where DateTime.Now.Subtract(Book.EntryDate.Value).Days < 30
             select Book;

Trying to do so will give you a NotSupportedException at runtime (unfortunately meaning that you won't find out that this won't work at compile time).

=== If All Else Fails ===
If you are really stuck trying to express a tricky SQL query in Linq, but using Linq generally, then you can still use the DataContext's ExecuteQuery method to send a query directly to the database in SQL.

var Result = DB.ExecuteQuery<BookResource>(
    "SELECT * FROM [BookResources] WHERE Title LIKE '%java%'");

We use a type parameter to specify the type of object that will contain the result of our query, then just specify the query to execute as a string. Note that we could have expressed this one in Linq, it's just an example.

If you want to just get one field, write the type of that field.

var Result = DB.ExecuteQuery<string>(
    "SELECT [Title] FROM [BookResources] WHERE Title LIKE '%java%'");

If you're getting a few fields back, then you will probably need to create a class with properties that have names matching those of the fields that you use in the query. However, there is another variant of ExecuteQuery that takes a Type object as a first parameter, so you can most probably instantiate an anonymous type using new() { ... } with some dummy values to get the member types correct, then call GetType and pass that as the parameter. I'll leave testing this beautiful bit of evil as an exercise for the reader.

=== Final Thoughts ===
Linq works to make working with databases feel close to working with other objects in your program. Thus IN feels very natural and, while they provide a direct way to use LIKE, some methods of the String class are usable too. However, in some cases you have to fall back to using some of the methods in the SqlMethods class, and in an extreme few further cases you might need to drop all the way back to using SQL.

When Linq and ref Parameters Meet

pheaven — Tue, 01 Apr 2008 07:17:31 -0700

It's fair to say that I'm a pretty heavy user of Linq. You'll find uses of it scattered across my code, from the obvious (using DLinq to query a database) to the slightly more exotic (writing queries over collections obtained from classes in System.Reflection). Linq often allows you to express a problem very neatly, resulting in compact, readable code. It also factors out the application of operations and leaves you to worry about the operations themselves, likely decreasing bugs.

=== Fixing A Bug ===
Today I ran across some code that took a parameter, then used it in a Linq query. Omitting the clutter, it looked something like this:

public void Lookup(string URL, ref int ID, ref int Status)
{
    // ...stuff...
    var Result = from D in DB.Datas
                 where D.URL == URL
                 select D;
    // ...more stuff...
}

It then set the couple of ref parameters based upon the results of the query (they really should have been out parameters, and I'll likely do some further refactoring later). However, the code calling this also appeared to be assuming that that the URL parameter would be updated to exactly match the entry in the database. This mattered because the "where" clause would actually match if the case was different, and the calling code wanted to know when this was the case. Clearly, this code couldn't be updating URL; it wasn't a ref parameter. Making it a ref parameter here and in the calling code was the obvious fix, so I did that. The code now looked more like this:

public void Lookup(string ref URL, ref int ID, ref int Status)
{
    // ...stuff...
    var Result = from D in DB.Datas
                 where D.URL == URL
                 select D;
    // ...more stuff, including updating URL...
}

And then I hit compile.

=== The Compile Error ===
Making the above change gave me the following compile error.

Cannot use ref or out parameter 'URL' inside an anonymous
method, lambda expression, or query expression

Or, re-phrased to fit this specific problem, "you can't use ref parameters in a Linq query". My first thought was, "huh, what the...". My second was, "OK, we can easily work around that." But of course, the main question that lingered after the initial "just do something that works so I can fix the bug" was, "but why can't I?"

=== The Workaround ===
The workaround is straightforward enough: you just make a local variable and assign the ref parameter to it.

public void Lookup(string ref URL, ref int ID, ref int Status)
{
    // ...stuff...
    var Lookup_URL = URL;
    var Result = from D in DB.Datas
                 where D.URL == Lookup_URL
                 select D;
    // ...more stuff, including updating URL...
}

This compiles and works just fine. So if that's all you were looking for, you have an answer. But now let's dig into the "why".

=== Introducing ILDASM ===
ILDASM is short for Intermediate Language Disassembler. A .Net executable contains a sequence of low-level instructions encoded in a binary format that we call bytecode, as well as tables of metadata about the classes and methods it contains. ILDASM turns that bytecode into IL, or Intermediate Language: a human readable representation of the binary data.

To get us started, let's just look at disassembling the Hello World program. First, we compile the following C# into an EXE file:

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine("Hello, world!");
    }
}

And then we use ILDASM to get the Intermediate Language. Stripping away some sections we need not care about, we get:

.class private auto ansi beforefieldinit Program
       extends [mscorlib]System.Object
{
  .method private hidebysig static void  Main(string[] args) cil managed
  {
    .entrypoint
    // Code size       13 (0xd)
    .maxstack  8
    IL_0000:  nop
    IL_0001:  ldstr      "Hello, world!"
    IL_0006:  call       void [mscorlib]System.Console::WriteLine(string)
    IL_000b:  nop
    IL_000c:  ret
  } // end of method Program::Main

  .method public hidebysig specialname rtspecialname
          instance void  .ctor() cil managed
  {
    // Code size       7 (0x7)
    .maxstack  8
    IL_0000:  ldarg.0
    IL_0001:  call       instance void [mscorlib]System.Object::.ctor()
    IL_0006:  ret
  } // end of method Program::.ctor

} // end of class Program

You'll see that there is a class declaration and two method declarations. The first is the Main method that we wrote. We can see that it loads the string "Hello, world!" onto the stack, then calls the the System.Console class' WriteLine method. Note that it finds its argument on the stack. The second method is actually a constructor and was generated for us; all it does is call our superclass' constructor.

As an aside for those of you wandering, "why the two nop (no operation) instructions", the reason for these is that I build this in debug mode. It inserts nop instructions anywhere that you could want to insert a breakpoint, and then at runtime actually patches the bytecode when you attach a debugger to contain "break" rather than "nop" opcodes.

=== The .Net CLR Doesn't Do Anonymous Methods ===
Now we'll write an example with an anonymous method. This code simply creates a list of integer values, then removes all of those that are less than or equal to five. I've highlighted the anonymous method - written with the compact lambda syntax - in red. It takes a single parameter, x, written to the left of the "=>", then checks that it is less than 5, producing a boolean result.

class Program
{
    static void Main(string[] args)
    {
        var TestList = new List<int>() { 1, 3, 8, 9, 10 };
        TestList.RemoveAll(x => x <= 5);
        foreach (var Val in TestList)
            Console.WriteLine(Val.ToString());
    }
}

If you run ILDASM on this program, you get quite a lot of output. I'll spare you the full listing (but feel free to try it) and just show you the parts that matter. The biggest thing you'll notice when going through the listing is that we have a new method.

.method private hidebysig static bool '<Main>b__1'(int32 x)
  cil managed
{
  .custom instance void [mscorlib]System.Runtime.CompilerServices.
    CompilerGeneratedAttribute::.ctor() = ( 01 00 00 00 )
  // Code size       12 (0xc)
  .maxstack  2
  .locals init ([0] bool CS$1$0000)
  IL_0000:  ldarg.0
  IL_0001:  ldc.i4.5
  IL_0002:  cgt
  IL_0004:  ldc.i4.0
  IL_0005:  ceq
  IL_0007:  stloc.0
  IL_0008:  br.s       IL_000a

  IL_000a:  ldloc.0
  IL_000b:  ret
} // end of method Program::'<Main>b__1'

This is actually our anonymous method, but it's not so anonymous once compiled. It's name is "<Main>b__1" - a name that we could never write in C# since it contains angle brackets, and thus has no chance of conflicting with anything else in our program. What's notable is that this is a method of its own, with only the name to hint to us what method it was originally contained within.

There are other interesting things in IL that we could spend a while looking at, including the fact that it makes it a delegate for this method and caches it in a private field to aid performance, however we'll put that aside for now and look at the next issue.

=== The .Net CLR Doesn't Do Lexical Scope ===
In the .Net CLR, methods can't see each other's local variables (unless we call one and pass it as a "ref"). This is normally the case in C# too, until we start writing anonymous methods. Then we can write anonymous methods that refer to variables in the enclosing method. Let's change our program to exhibit this.

class Program
{
    static void Main(string[] args)
    {
        var TestList = new List<int>() { 1, 3, 8, 9, 10 };
        int Maximum = 5;
        TestList.RemoveAll(x => x <= Maximum);
        foreach (var Val in TestList)
            Console.WriteLine(Val.ToString());
    }
}

This produces the same results as the previous version of the program. Now let's look at the disassembly. The first surprise we get is to discover that our Program class now actually contains a new, nested class!

  .class auto ansi sealed nested private beforefieldinit
    '<>c__DisplayClass2'
         extends [mscorlib]System.Object
  {
    .custom instance void [mscorlib]System.Runtime.CompilerServices.
      CompilerGeneratedAttribute::.ctor() = ( 01 00 00 00 )
    .field public int32 Maximum
    .method public hidebysig specialname rtspecialname
            instance void  .ctor() cil managed
    {
      // Code size       7 (0x7)
      .maxstack  8
      IL_0000:  ldarg.0
      IL_0001:  call       instance void [mscorlib]System.Object::.ctor()
      IL_0006:  ret
    } // end of method '<>c__DisplayClass2'::.ctor

    .method public hidebysig instance bool
            '<Main>b__1'(int32 x) cil managed
    {
      // Code size       17 (0x11)
      .maxstack  2
      .locals init ([0] bool CS$1$0000)
      IL_0000:  ldarg.1
      IL_0001:  ldarg.0
      IL_0002:  ldfld      int32 Program/'<>c__DisplayClass2'::Maximum
      IL_0007:  cgt
      IL_0009:  ldc.i4.0
      IL_000a:  ceq
      IL_000c:  stloc.0
      IL_000d:  br.s       IL_000f

      IL_000f:  ldloc.0
      IL_0010:  ret
    } // end of method '<>c__DisplayClass2'::'<Main>b__1'

  } // end of class '<>c__DisplayClass2'

Because methods can not see each other's locals, the compiler has to resort to using fields to exchange information between them. So how is this class used inside our Main method?

First, it stores an instance of this class as a local variable of Main, instantiating it right at the start of the method. Yes, that means that you have an instance of the nested class created per call to the method! This is needed to get the correct semantics in multi-threaded code.

Whenever we reference the Maximum variable in our method, even outside of the lambda expression, it actually gets compiled down to a store field or load field instruction. This means that it's not, at the bytecode level, a local variable any more, which means it will be more expensive to access at runtime.

=== Code That Uses ref ===
So what does code that uses ref look like at an Intermediate Language level? Once again, we'll write a small test program:

class Program
{
    static void Main(string[] args)
    {
        var Test = 2;
        DoubleMe(ref Test);
        Console.WriteLine(Test);
    }

    static void DoubleMe(ref int Val)
    {
        Val *= 2;
    }
}

This program produces 4. Next up, we'll disassemble it:

.class private auto ansi beforefieldinit Program
       extends [mscorlib]System.Object
{
  .method private hidebysig static void  Main(string[] args) cil managed
  {
    .entrypoint
    // Code size       19 (0x13)
    .maxstack  1
    .locals init ([0] int32 Test)
    IL_0000:  nop
    IL_0001:  ldc.i4.2
    IL_0002:  stloc.0
    IL_0003:  ldloca.s   Test
    IL_0005:  call       void Program::DoubleMe(int32&)
    IL_000a:  nop
    IL_000b:  ldloc.0
    IL_000c:  call       void [mscorlib]System.Console::WriteLine(int32)
    IL_0011:  nop
    IL_0012:  ret
  } // end of method Program::Main

  .method private hidebysig static void  DoubleMe(int32& Val) cil managed
  {
    // Code size       8 (0x8)
    .maxstack  8
    IL_0000:  nop
    IL_0001:  ldarg.0
    IL_0002:  dup
    IL_0003:  ldind.i4
    IL_0004:  ldc.i4.2
    IL_0005:  mul
    IL_0006:  stind.i4
    IL_0007:  ret
  } // end of method Program::DoubleMe

  .method public hidebysig specialname rtspecialname
          instance void  .ctor() cil managed
  {
    // Code size       7 (0x7)
    .maxstack  8
    IL_0000:  ldarg.0
    IL_0001:  call       instance void [mscorlib]System.Object::.ctor()
    IL_0006:  ret
  } // end of method Program::.ctor

} // end of class Program

I have colored the interesting lines in red. The first line shows us using the lodloca instruction rather than ldloc, which loads the address of the local variable onto the stack rather than the value of the local variable. Then, inside DoubleMe, it uses ldind and stind to load and store the value indirectly, that is, using the address.

=== So could they have made it work? ===
If all the IL has made you feel woozy, it's about to get worse. Now we've seen all the previous examples, let's try hand-editing some IL to see if we can actually get ref parameters to work in lambdas, and if not working out exactly why we can't. The first step is to write a program that is as close to what we want as we can get C# to compile, since editing IL is a pain.

class Program
{
    static void Main(string[] args)
    {
        var TestList = new List<int>() { 1, 3, 8, 9, 10 };
        int MaxVal = 5;
        RemoveVal(TestList, MaxVal);
        foreach (var Val in TestList)
            Console.WriteLine(Val.ToString());
    }

    static void RemoveVal(List<int> TheList, int Maximum)
    {
        TheList.RemoveAll(x => x <= Maximum);
    }
}

Next we can used ILDASM to get the IL code. Now let's start doing some small changes. First, we'll change the signature of RemoveVal to take an int32&, and the call to it to load the address of the MaxVal local and pass that instead of passing the value itself. Then inside RemoveVal, where we previously just loaded the parameter and assigned it to the Maximum field in the generated nested class, we'll add an extra instruction to load the indirect field.

    IL_0007:  ldarg.1
    IL_00071: ldind.i4
    IL_0008:  stfld      int32 Program/'<>c__DisplayClass2'::Maximum

Using ILASM, we can re-assemble this to an executable file, and discover that the program still works. However, that's not really got us any further than a temporary local would have in C#. What we actually want is to store the indirect reference in a field. Can we have a field of type int32&, though? To find out, in the anonymous class let's add one:

    .field public int32& MaximumTest

If we try and assemble this, it produces an EXE file. It all looks good until we try and run it, at which point the CLR crashes, leaving the following message behind:

Unhandled Exception: System.Runtime.InteropServices.COMException (0x801312E4):
Field of ByRef type. (Exception from HRESULT: 0x801312E4)
   at Program.RemoveVal(List`1 TheList, Int32& Maximum)
   at Program.Main(String[] args)

Why, though? Well, the reason is quite simply that, in general, it is unsafe to allow fields of ByRef type. This is because a ByRef is essentially a pointer into a stack frame, which is where local variables are stored. If you store a pointer into it, and that pointer exists beyond the stack frame (that is, until after we return from the method that declared the local we passed a reference to), you are pointing into unknown and very likely invalid memory. That would compromise the type-safety of the VM. I'd run across this very issue before in a different situation, so it was interesting to see it coming up as the answer to the question we set out to answer.

=== Summary ===
So, to summarize all of this drawn-out analysis, the reason we can't use ref and out parameters in an anonymous method (and thus a Lambda expression or a Linq query) is as follows. Anonymous methods compile down to separate methods. If they are accessing parameters or local variables, to share those with the method implementing the lambda expression we are required to put them in a field. To ensure the type safety of the CLR, we can not store a ByRef value (what we get when we use ref and out) in a field.

I suspect that fixing this well would require adding some extra support to the .Net Common Language Runtime itself, which is relatively unlikely to happen; this happened between .Net 1.x and .Net 2.x and I suspect they won't be in a hurry to do that again (the underlying VM between .Net 2.x and .Net 3.x is actually the same, it's just some extra libraries). You could do it by making stack frames garbage-collectible so it's OK for them to live beyond an invocation (but that probably hurts performance a lot), or you could do it by adding support for lexical scopes and closures, so the compiler doesn't have to fake them using fields. The Parrot VM, which I work on, does the second of these.

Anyway, I hope this analysis has given you more of a sense of the Real Answer, rather than the compilers simple, "you can't".

Very Quick Guide To DLinq: Part 2

pheaven — Tue, 25 Mar 2008 02:45:59 -0700

In this part I'm going to take a look at inserts, updates and deletes using DLinq.

=== The Overall Model ===
First, to make changes to a database, you instantiate the data context object, just as we did before doing selections in the previous part.

var DB = new ResourcesDB();

You then do the required changes; we'll look at this part in just a moment. However, the inserts, updates and deletions are not performed immediately. They do not take place until you explicitly submit the changes:

DB.SubmitChanges();

This means that you can make many changes, then send them to the database all at once.

=== Inserting Data Into A Table ===
To make a single new entry to a database table, use the InsertOnSubmit method on the Table object. This takes a single parameter: an instance of the object that represents a row in the the table. You can use the object initializer syntax to write this very neatly.

DB.BookResources.InsertOnSubmit(new BookResource()
{
    Title = "How To Make Fondue",
    Author = "Mr S. Cheese"
});

Of course, you can instantiate and set up that object elsewhere. You may end up with many object to insert, in which case you can build a List<BookResource> (or anything else that implements the IEnumerable<T> interface) and then use the InsertAllOnSubmit method.

DB.BookResources.InsertAllOnSubmit(NewBooksThisWeek);

Remember that the inserts will not take place until you call the SubmitChanges method on the data context (you don't call it on the table itself).

=== Updating Data ===
To update data, first you need to write a Linq query to get the data that is to be updated. If you want to update just one item, you can use .First() on the query result to just get that item.

var ToEdit = (from Book in DB.BookResources
              where Book.BookID == 42
              select Book).First();
ToEdit.Author = "Mr Swiss Cheese";

If you have many items that you want to update, select all of them and then write a foreach loop.

var ToEdit = from Book in DB.BookResources
             where Book.Author == "Mr S Cheese"
             select Book;
foreach (var Book in ToEdit)
    Book.Author = "Mr Swiss Cheese";

And once again, don't forget to call SubmitChanges when you've done your changes, else they won't be saved back to the database.

=== Deleting Data ===
Deletions follow a similar approach to updates. However, rather than changing the object(s) you select from the database you pass them as a parameter to the table's DeleteOnSubmit for one item:

DB.BookResources.DeleteOnSubmit(
    (from Book in DB.BookResources
     where Book.Author == "Mr S Cheese"
     select Book).First());

Or DeleteAllOnSubmit for many items:

DB.BookResources.DeleteAllOnSubmit(
    from Book in DB.BookResources
    where Book.Author == "Mr S Cheese"
    select Book);

You may assign the selection to a temporary variable and then pass that to delete as you wish. Call SubmitChanges to actually delete these items in the database.

=== Next Time ===
Next time we will look at how to handle various special queries that are less obvious how to express using Linq, including the SQL LIKE and IN operators.

Very Quick Guide To DLinq: Part 1

pheaven — Fri, 14 Mar 2008 09:10:53 -0700

We have already written about using Linq, but didn't cover DLinq. This post takes a quick look at getting started with DLinq, which allows you to write Linq queries against databases. Once you're up to speed, you can take a database and be writing Linq queries against it in under five minutes!

In future parts in this series of posts, we'll look at doing database updates, writing more complex queries and debugging. In this one, we'll just look at doing some simple queries.

=== Creating The Linq to SQL Classes ===
The bad news is that before you can use DLinq, you have to create Linq to SQL classes to represent your database tables. The good news is that Visual Studio 2008 (aside from the Express Edition) can do all of the hard work for you in this.

To get started, right click in the Solution Explorer in your project (or a directory in your project), go to the Add sub-menu and choose "New Item...". In the resulting dialog, choose the "Data" category to the left, then "LINQ to SQL Classes" in the resulting list on the right. Enter a name for the group of classes (collectively known as a Data Context), and press OK.

[includeimage:1]

Next, you need to connect to the database holding the tables that you want to do queries on. To do this, open the Server Explorer (if you don't see it, it's on the View Menu). Right-click on "Data Connections", then choose "Add Connection..." Fill out the fields in the resulting dialog, and click OK. You will then have your database in the list.

[includeimage:2]

Open up the Tables subtree beneath the connection you just created. Select the tables that you want to be able to do queries on (select multiple by holding down Control or Shift). Then drag them to the left pane of the data context. Visual Studio will then create the classes for these tables, and you'll see the tables represented in the data context.

[includeimage:3]

Finally, click in the data context somewhere other than on a table. Go to the properties window and set the namespace and the class name for the class that represents the data context as a whole.

[includeimage:4]

Finally, save this.

=== Writing Queries ===
For the sake of this article, I've just created DLinq classes for a couple of bits of the Programmer's Heaven resources database, where we store details of files, links, articles, books and so forth. I'm using a Console Application to play with this.

First, we need to instantiate the data context.

var DB = new ResourcesDB();

The members of DB represent, amongst other things, the tables in the database. We can use these to write queries on those tables.

var Result = from Book in DB.BookResources
             where Book.Published == "1997"
             select Book;

Remember that we use C# syntax rather than SQL syntax; it's all to easy to forget this and write SQL "=" rather than C# "==". Thankfully, if you make this mistake, the compiler will complain. Of course, you don't have to just select the Book; you can instantiate and populate any class that you wish to instead.

=== Getting At The Query Results ===
In the previous query we selected all books in our database published in 1997. We can now iterate over the Result collection and print the title of the books.

foreach (var Found in Result)
    Console.WriteLine(Found.Title);

Which produces a list of titles of the books that were found.

=== The Next Steps ===
If you have already read our Linq tutorial, you'll have seen how you can write some pretty complex queries over collections of objects. All of that same power is available in DLinq too, so if you want to learn how to write more complex queries then you should refer to that. In future parts of this series, I will look at other DLinq specific bits.

Float, Double and Decimal: do you know the differences?

pheaven — Tue, 11 Mar 2008 03:17:36 -0700

There are a number of data types available in the .Net framework for storing numbers with fractional parts. They are each appropriate for different situations, and using the wrong one can lead to errors in calculations.

=== Thinking About Accuracy ===
In some applications, you require that calculations involving numbers with fractional parts are exact. Examples of this are in financial applications, where losing the odd cent here and there in a calculation is unacceptable. Customers expect their accounts to be completely accurate, not to mention the tax man.

In other applications, you don't care about exact results, but you are interested in having an answer that is correct to a certain number of significant digits. This is the case in experimental physics, for example. When you make a measurement of something, you can only measure it as accurately as your equipment will allow you. Therefore, you have an inherent error in that value already, which is going to cascade through any calculations you do with it. This means that while your computed answer may be 5.1826, you may know that the values this answer was calculated from were only accurate to three significant digits, and so the last two digits in this result (the 0.0026) don't matter. If there is a computational error in them, so be it - it's not going to hurt us.

=== Number Representations ===
There is more than one way to represent a number with fractional parts. Decimal represents the number as an integer, then also stores an integer power of ten (the exponent) that states where the decimal point is. The .Net decimal type allows you to shift it between 0 and 28 places to the left, so the most fractional places you can have is 28. Since both the value and the position of the point are represented as integer types, and because (with enough bits) we can represent any integer value exactly in binary, we can store the number exactly.

Single and Double (also known as float and double, depending on your language) work differently. Glossing over a few details (but if you want them, look up the IEEE 754 standard), they are stored with both a mantissa (which specifies the digits making up the number) and an exponent, which specifies where the binary point goes. That is, we're working in base two for everything. Further, the mantissa is normalized, so your number is always stored as something of the form 1.10010101 (with only a single bit to the left of the point) followed by binary columns that represent a half, a quarter, and eighth and so forth.

The important thing to realize here is that many decimal numbers are not exactly representable in binary. Consider decimal 0.3, for example. If we try to represent it as the sum of powers of two, we end up with a sequence like 1/4 + 1/32 + 1/64 + 1/512 + ... - in fact, we never actually get to an exact value. We'd need infinitely many bits. This is not unique to binary; in decimal, for example, we can not specify 1/3 exactly. However, it does mean that we have the potential to lose data.

=== Range ===
The decimal data type uses 96 bits to store the number itself. There is a special bit for storing the sign, meaning that you get a range of -79,228,162,514,264,337,593,543,950,335 to 79,228,162,514,264,337,593,543,950,335, if you have no fractional parts. This is 29 digits, meaning that you can move decimal point all the way to just after the initial digit. This is, with the maximum exponent you get a range of -7.9228162514264337593543950335 to 7.9228162514264337593543950335.

With floating point types (float and double), you store the mantissa in a normalized form, meaning you can shift the binary point in either direction to get really small or really large numbers. However, remember that unlike the decimal data type, you are not able to represent every value in the range. You get it accurate to a certain number of significant bits.

With a float, you can store numbers from -3.402823e38 to 3.402823e38, where e38 means "10 raised to the power of 38" - a bit of a wider range than with decimal. However, also interesting is the smallest positive or smallest negative number you can represent, which is around 1.4e-45 - really very tiny.

With a double, the range is -1.79769313486232e308 to 1.79769313486232e308, and the smallest is around 5e-324! While the range is greater, the main advantage of the double type isn't so much the extra range of values - due to a small increase in exponent size - but a big increase in precision by having a much larger mantissa. That is, you get a lot more significant digits.

=== Size In Memory ===
A float (Single) takes 32 bits of memory, a double takes 64 bits of memory and a decimal takes 128 bits of memory. Note that the reason a decimal is so much larger is because it can store a huge number of significant digits, giving a great deal of accuracy/precision. Note that a 32-bit float can only represent as many values as a 32-bit integer; you are trading in precision to get an increased range. It's worth noting that about half of the values you can represent with a floating point number are between -1.0 and 1.0.

=== Performance ===
In any modern PC, your CPU will have a dedicated Floating Point Unit, which is a chunk of hardware that performs operations on floating point numbers (floats and doubles). However, in embedded environments you may not have an FPU available. If you do have an FPU, operations on floats and doubles will be fast (and the non-floating point execution units can also be used to do other integer computation in parallel, thanks to in-hardware optimization). If you don't and it is being emulated in software, it will be much slower.

The exact performance differences in operations on floats and doubles is highly platform and application specific. We can certainly say that floats require double the memory, and thus twice as much CPU cache space, but how much that actually impacts performance is specific to how your application uses memory. Due to the fact that cache lines store multiple words anyway, there's not an obvious answer.

The decimal type does integer operations. Normally that would be faster than floating point ones, apart from there isn't dedicated hardware to deal with the 96-bit values, not to mention handling differences in the exponent, so it can wind up being much slower. If you didn't have an FPU, fixed point would likely beat floating point. It's the hardware support that makes the big difference here.

=== Conclusions ===
Always remember that floating point numbers can't represent every value in the range they cover, while decimal numbers can (though the range is somewhat smaller).

The inability of floating point numbers to represent every possible value in the range they cover can have important consequences in application design. For example, adding a bunch of numbers smallest first to largest first can end up with a different result to if you had done the largest first and finished up adding on the smallest one. The reasons behind that are complex and for another post, but it's good to be aware that there are a lot of subtleties to worry about when working with floating point. The other big thing to avoid in most circumstances is comparing floating point values exactly, rather than checking that the difference between them doesn't lie in an acceptably small range.

As a general rule, if you're dealing with currency and/or need exact results, use decimal. If you are writing scientific applications, you likely want to be using a floating point type (either single or double).

Do try...catch blocks hurt runtime performance?

pheaven — Tue, 19 Feb 2008 06:23:04 -0700

Recently, a friend mentioned that someone had told him that writing a try...catch block in C# (or substitute some other .Net language here) resulted in a "huge penalty" in terms of performance compared to if you had not written it. That is, merely writing such a block actually hurt program performance, even if an exception was never thrown. He didn't believe this was true, and rightly so - it's completely wrong. This post is a tidied up version of my explanation.

=== Inside a .Net Assembly ===
A .Net assembly, if we ignore various headers, consists of three things:
* Bytecode: a sequence of low-level instructions that specify the body of a method
* Metadata: a set of tables, a little bit like a database, describing higher level constructs such as classes, methods, signatures and so forth
* Heaps: places where string constants and other such things are stored
That is, bytecode is what we actually execute and the rest is there to describe the extra details. To give you an example of the interplay between them, consider a method call. The bytecode stream contains the call instruction, followed by a method token, which is actually an index into the methods table. The methods table in turn allows us to find out where the bytecode for the method we're calling starts, so we can execute it.

(As an aside, these lookups wouldn't be all that expensive to do per call, though in reality they likely won't actually happen more than once per call site, unless it's done through reflection or a delegate. That's because when the CLR JIT-compiles the bytecode, it can compile the method call down to call instructions at the CPU level that refer directly to the method being called. You don't need to know this bit; it's just here for the curious.)

=== How Exception Handlers Are Stored ===
The .Net CLR has a concept known as a "protected region". A protected region is a sequence of instructions that has an associated handler. In C# or VB.NET, the instructions in a protected region correspond to code in a try block. There are various types of handlers, including typed ones (that catch only a certain type of exception) and finally ones. Note that a try...catch...finally will result in two protected regions at the CLR level, one for the catch and one for the finally. The protected regions will cover the exact same sequence of instructions, just have different handler addresses.

Each method that has protected regions comes with a table of them. For each protected region, it contains four entries:
* The starting instruction in the bytecode for this protected region
* The number of bytes worth of instructions from the starting point that are protected
* The type of handler
* The location in the bytecode of the handler
They are ordered with innermost handlers coming first.

=== What happens at runtime ===
Here is the important part when it comes to performance when an exception is not thrown. Since the protected regions are stored in a table and are not in the bytecode, and because the CLR does not need to worry about the exception handlers unless an exception is thrown, then there is no runtime penalty for having a try...catch block. For finally handlers it is a little different, because we do need to run those even when we don't have exceptions. However, since we can compute what we will need to run when statically, the JIT compiler can still emit code that jumps to the finally handler at the appropriate time, making the execution overhead of one of those most likely just a jump and a return.

So that's most of the answer to the question that was asked, but for interest let's take a look at what happens when an exception is thrown. Provided the current method has protected regions, you scan through the table to find if there are any that cover the instruction where the exception was thrown and that are capable of handling it (they are looking for an exception of the correct type, for example). If there are multiple nested handlers that could handle the exception, the ordering of innermost first means that we will find the correct handler.

If we find a handler, we execute it. If we don't find one, we move down to the next method in the call stack and check if it has a suitable handler, keeping going until we find one (or we discover that the exception is user-unhandled and terminate the program). This means that the cost of throwing and catching an exception is dependent on how far down the call stack you have to go to find a handler.

From this we can conclude that .Net is optimized for the case where you do not get exceptions. Since exceptions are intended to happen only in exceptional (that is, unexpected) circumstances, this is a sensible design decision. If you inclined to use exceptions for ordinary flow control, this should give you another reason not to.

=== And the cost of a try...catch block is... ===
So what can we conclude? The overall cost of a try...catch block that never handles an exception is a few bytes of memory - or at worst a few words - for the entry in the protected regions table. The only possible runtime penalty is the extra time to load those extra few bytes into memory. Since they are stored way away from the JITted bytecode stream, it's highly unlikely you're going to incur any additional cache-misses at runtime as a result of the handler too. Thus, the cost is essentially nothing.

The cost of not handling an exception that you should have may well be that your program crashes. This results in unhappy customers, a hit to your reputation and development time to go and do a bug-fix, which will almost certainly be much greater than if you had put it in there in the first place. Obviously, protecting code that can not throw an exception under any circumstances is a waste of your development time. But otherwise, it's best to be safe rather than sorry, safe in the knowledge that even if an exception never does occur in that bit of code, it's not really costing anything anyway.

C#.NET or VB.NET?

pheaven — Mon, 11 Feb 2008 09:10:09 -0700

We get a lot of emails from Programmer's Heaven users. Amongst the requests that we do people's homework, which we ignore, we also get some more interesting questions sent to us too. We figured that when we do, we may as well share our answers more widely, and also this gives other folks a chance to give their input too. Recently we got one from someone who had discovered us through the C# School e-book and asked, "please kindly advise which of the two, C# and VB .NET is better for developing commercial applications like Payroll".

=== The Similarities ===
Both languages run in the Common Language Runtime and allow you to have full access to the .Net Class Library. This means that pretty much whatever is in the .Net Class Library is equally available to both VB.NET and C#.NET. Both languages have a similar feature set too, providing strong support for Object Oriented Programming, which is good for developing database-backed applications, as your Payroll surely will be.

If you take the list of additions to C# 3.0 and the list of additions to VB 9.0, both released at the same time along with Visual Studio 2008, they are not too far from identical. Both added support for Linq, both added type inference, both added anonymous types and so on. In fact, there's only one thing I see in the VB 9.0 list that wasn't in the C# 3.0 list: they've supported XLinq (queries over XML) with some special syntax in addition to normal queries. If you're not working with XML, you may find that of limited value, though.

=== Spot The Difference ===
The single biggest difference is syntax. Basically, VB.NET uses syntax derived from the BASIC language family, whereas C# uses syntax derived from the C language family. What you prefer will be just that: a preference. I know that I find VB.NET a bit harder to read, basically because it's more verbose and it's that little bit harder to pick out names of variables, methods and types (because more of the syntax is expressed in words, whereas C# uses non-alphanumerics). However, other people may find that more real words being used in the syntax makes it more readable.

There is the odd feature difference. For example, C# has no equivalent to the With blocks in VB, which let you topicalize. I wish it did have one, so that's a minor point I have to award to VB. More importantly, C# allows you to write unsafe code (that is, code that does direct memory operations and pointer arithmetic), while VB provides no way to do this. However, for a payroll application you just won't need to do this. Heck, I've been writing C# for a couple of years and haven't ever needed to use this feature. There are, of course, use cases, but they aren't ones you're going to run across while implementing a payroll application.

Then there are just different ways to do things. C# chose to let you use the "this" keyword on a parameter to denote an extension method, whereas VB gets you to mark it with an attribute. But at the end of the day, that's not much more than a syntactic difference either.

=== Does it matter? ===
From a technology point of view, I really don't think that it matters which language you choose. I know which I prefer and I can give reasons why I prefer it, but it's little more than that: a preference. You're going to be able to write the same application in VB.NET or C#.NET. The differences are really not much more than syntax deep, so much so that there are translators out there that will take your code in one and turn it into the other, retaining comments. The other thing to realize is that you've only got one set of concepts to learn to know both languages, and two lots of syntax. And syntax is easier to learn than semantics.

Other than your own personal preference, you might want to consider the backgrounds of anyone else who will be working on the project, or may maintain or contribute to it in the future. If they have programmed before, their background may suggest which language they'll be most comfortable with, and if it doesn't matter much to you then then you may want to base your decision on that.

=== Conclusion ===
The differences between the languages are not much more than skin deep. They have a near identical feature list, and the features have near identical semantics - basically, those provided by the underlying .Net Common Languages Runtime. Both are suitable for your project, and I doubt the outcome will be greatly affected by which one you choose. Pick one and go for it. If you need to, you'll be able to learn the other one easily later anyway.

Running C# .NET Applications On Fedora 8 Linux

digioz — Sun, 09 Dec 2007 19:21:29 -0700

One of the main challenges and the reason most corporations choose to target a windows operating system for their custom applications is that developing custom linux applications is not something that most entry level developers know how to do. To acomplish this they would have to rely on some of the most unreliable groups of programmers to control in the business: The Linux GUI or Java GUI Developers, both of which are hard to find, and even harder to manage. Some have even been known to walk off of jobs just because they weren't given enough of a say on how their master pieces should run and function!

The .NET Framework is changing all of that through the use of the Mono Project. The Mono Framework, is a Framework that is essentially a carbon copy of all the libraries in the original .NET Framework, compiled for other platforms like Linux, Mac OS X, Solaris and even Nokia 770 and 800 Devices! This puts the .NET Framework a step ahead of other frameworks like Java, because of the fact that it turns your standard C# developer (very easy to please group) to do the work that Java type developers used to do. Needless to say that this phenomenon is speading like wildfire through more and more coprorations, because now you can develop applications on your standard Windows .NET Development environment, and have it run on Linux, which comes free! To make things even more convinient, you can even write Webservices and other types of .NET Applications for Linux!

It shouldn't come as a big surprise therefore that Fedora 8 Linux distribution (Redhat) comes with the Mono framework pre-installed fresh out of the box. I have also noticed a surge in the number of open source C# linux projects on open source community sites like SourceForge.net that take advantage of the Mono framework to write fairly complex linux applications in record time, and take advantage of the CLR type debugging that the framework has to offer to find bugs and fix them even faster.

Most developers at one point or another have thought about installing a linux OS on a Virtual Machine like "Microsoft Virtual PC 2007", which can be downloaded for free HERE simply because that way they wouldn't have to take up a whole PC for testing on a Linux OS, and at the same time this allows them to try out several different flavors (distributions) of linux on the same machine. Most of you however are discouraged when you notice that neither your Mouse, Nor your Display (either one or both) functions, which eventually forces you to delete the whole virtual PC and forget about linux yet once more, cursing Microsoft for not making their Programs a bit more competitor friendly! I am here however to tell you that it IS POSSIBLE to run a Linux OS on a Virtual Machine (with a few tweaks to the grub booting agent).

THE OPERATING SYSTEM - Fedora 8

For my experiment with the Mono Framework, I choose Fedora 8, since I have worked with other Redhat products in the past, and find it to be one of the most active Linux distributions out there. I probably would have considered Open SuSE 10.3 instead, if they had the mono framework preinstalled on it like Fedora 8 does (call me lazy, but that's a good hour or two that I don't have to keep messing with the OS to get mono working correctly, which I can spend on other thing like figuring out how to run the OS on Virtual PC and work).

So go ahead and grab the ISO image for Fedora 8 from HERE. This is the DVD ISO image, which you have to burn on a DVD to install Fedora 8. Other download options can be found HERE. Be prepared to take a nice long 3-4 hour coffee break while it is downloading, just don't overdue it with the coffee, because then you got to take a bathroom break every 5 minutes while trying to do the work, and that makes it hard to focus on the task at hand. :)

While you are waiting for the Fedora image to download, go ahead and grab a copy of Microsoft Virtual PC 2007 for Free (special thanks to our good friend Billy Gates for that) from HERE. I assume that everyone knows how to do a simple install of this, so I am not going to walk you through that part. I ran my experiment on a Windows XP SP 2, but Virtual PC does also install on Windows Vista (even though you get a warning that it is not a supported OS, but it still runs). Run Virtual PC, and you should see this screen:

[includethumb:1]

Click on "New" to create a new virtual PC. Hit "Next" to go to the next screen. Choose "Create a Virtual Machine" and hit "Next". On the next screen, enter "Fedora 8" for description and go to the next screen. Notice that it automatically selects OS of "Other" for you. Accept it and hit "Next". Check "Adjust the Ram" and enter 512 for your RAM. Select "A New Virtual Hard Disk", go to the next screen and select the default path and hard drive size and click "Finish" to complete.

Hopefully your Fedora 8 download is done at this point. Burn the ISO image to a DVD with your favorite DVD burning software and pop it in your drive. You should have a new icon in your Virtual PC Console called "Fedora 8" at this point. Select it and click on "Start" to start the install process. You may have to reset the virtual machine once to get thei Fedora 8 installer to work right. Go to "Action > Reset" to reboot the Virtual Machine.

The actual Fedora 8 installation is sadly not a very straight forward process, because you will have to tweak it to get the Mouse and Display to work right. I am not going to go through every detail of the install process, but to get the Display and Mouse to work correctly:

On Install: Hit the button and add the following to the boot line:

vmlinuz initrd=initrd.img vesa i8042.noloop

After Install: Stop reboot at the grup by hitting the ESC key or Spacebar. Press "e" to edit the boot line, and add the "i8042.noloop" to the second line. Hit "Enter" key followed by pressing the "b" key to boot.

To Fix Mouse Problem for good: After logging in, go to Applications > System Tools > Terminal, and enter the following:

su
nano /boot/grub/menu.lst

sunano /boot/grub/menu.lstGo down to the line that starts with "Kernel" and add "i8042.noloop" to the end of that line. Press Ctrl+O to write out, hit "Enter" followed by a Ctrl+X to exit out. Reboot and you should be good to go.

Running Standard .NET Applications

Lets first start by logging in as your regular user. I have created two test applications using C#, which can be downloaded from my website. The Command Line Test Application can be downloaded HERE and the GUI TEST Application from HERE. Both of those are simple "Hello World!" type applications written in C#. One outputs it to the Command Prompt and the other pops up a GUI messagebox for it, to proove the concept.

If you are a hardcore windows application developer, the first thing you will do is to double click on the executables once you have them downloaded on your Fedora Desktop. If you did that, you would see the following message:

[includethumb:2]

You are NOT in Windows any more, so snap out of it! You can't just go around double clicking on a windows application on Linux! What you have to do instead is to call mono and have it launch your program for you instead. So lets do that real quick. Go to "Applications > System Tools > Terminal" and open a new Terminal window. Next, navigate to the folder you downloaded the "exe" files to (in my case its "/home/Pedram/Documents") and type "mono HelloWorldCS.exe". You will get the output "Hello World!" back, showing you that everything is working OK. Congratulations! You have just run your first .NET Application on Linux! Here is what your desktop should look like at this point:

[includethumb:3]

Getting our GUI Application to run is a bit more complicated then this. Don't get me wrong, the process is exactly the same. But there are some file permission issues with it that I myself have yet to figure out. So lets do the same for our GUI Application. Type "mono HelloWorldGUICS.exe" in your Terminal Window. You would expect to see a standard messagebox like this:

[includethumb:4]

But instead, the first time you run it, you will see an error message saying Mono can not find GDI+ library. That's because the first time you run the GUI "exe", mono tries to recompile it to a Linux compatible application before runnning it, but does not have permission to several critical GUI related libraries! Log out as your regular user, log back in as "root" user and try the same thing. This time you should get the correct message pop up.

If you now go back and log in as your original user, you will notice that you can now run this application as your regular user as well! That's because the GUI Application has already been compiled by the root user, and Mono grabs that compiled version when you try to run the Application under a regular user.

At this point you are probably ready to shout for joy, jump up and down and start coding all kinds of weird .NET GUI Applications for Linux. But with Fedora 8 being a newly release Operating System, and having the advanced security system on it that kind of behaves like Vista Security, there will be all kinds of error messages that will pop up here and there that will puzzle the heck out of you. If you do come across some weird error message that you would like to share with me or get my opinion on, email me at webmaster@digioz.com to talk about it. Best of luck with Mono!

Pete Soheil
DigiOz Multimedia
http://www.digioz.com/

Learn C# 3.0 With Our New Series!

pheaven — Wed, 21 Nov 2007 09:31:37 -0700

This week we are starting a brand new four part series, covering the new features of C# 3.0! The first article of the series covers type inference. You'll learn:
* What is type inference anyway?
* How can you take advantage of it?
* What does the new "var" keyword do?
* Is this at all related to Variant types in Visual Basic?
* Will using this hurt the performance of your programs at runtime?
Check out the article!

Visual Studio 2008 .Net Goes Gold!

pheaven — Wed, 21 Nov 2007 04:35:21 -0700

The Microsoft Visual Studio .Net development team have released Visual Studio 2008 to manufacturing. That means it will be in our hands Real Soon Now. For those of us who have been eagerly awaiting the advances made in this new version of Visual Studio .Net, this is exciting news.

First of all, there are significant language updates. Both C# and VB.NET have new language features that will increase developer performance, allow more opportunities for abstraction and code re-use and help us to write more readable code.

Linq is one of the big new features. It integrates a query language into C# and Visual Basic, allowing for writing of declarative, SQL-like queries directly into programs. These can be type-checked at compile time, unlike strings of SQL. Furthermore, this is not just for databases: you can run queries over collections of objects, XML documents and more. For databases there's another win - because you are writing in C# or VB syntax, you don't need to worry about the syntax of SQL, or which database server you are using.

There was no matching Visual Studio release for the .Net 3.0 framework, so if you have not started using it then this release will bring you the new features of that too. This includes WPF - the Windows Presentation Foundation - which will help with building powerful and beautiful user interfaces with less work than it would have required before, and WCF - the Windows Communication Foundation - which helps to abstract away the details of the transport mechanism and make building service oriented architecture easier. Note that the framework version is now as 3.5 - a little confusing, given C# is version 3.0. Just use and enjoy.

Vertical Label Control

sheijin — Mon, 12 Nov 2007 03:30:30 -0700

I have published an article regarding vertical label control at the Code Project website. Kindly go to http://www.codeproject.com/useritems/Vertical_Label_Control.asp to check it out.