Logging Experiences

One reason to prefer readonly to const in C#

Posted in C#, Programming, Tips and Tricks by Sina Iravanian on April 21, 2010

First off, let’s talk about what’s going on in C# compiler when you use const or readonly in your field definitions. The const qualifier can be used with primitive data types, and strings only. When used, the value assigned to a const field, is inserted directly in all its references in the generated IL code. This is true about other assemblies too. Other assemblies that refer to that const field, are compiled as if they have used directly the value itself. This can be the source of problem that I’m going to talk about soon. Readonly fields are run-time constants. They occupy some place in memory, and references to them are resolved in run-time, as if we have referred to an ordinary variable. Actually they are variables that resemble constants.

Imagine that you have created and released a project to public. Your project contains several assemblies in form of .dll files. They make use of some constant value in one of the .dll files, e.g., SomeLibrary.dll stores a constant value in one of its classes, e.g.,

public class Options
   public const int NetworkTimeout = 2000; 

You realize that the value assigned to NetworkTimeout is less than expected, so you decide to update SomeLibrary.dll files in all your customer machines with a new one in which NetworkTimeout is set to 3000. But it will not work. Because all references to NetworkTimeout in other assemblies have been replaced with the constant 2000, and the new value will not be fetched any more. In this case the problem will be solved only when all other assemblies are rebuilt. No other update scenarios will do.

But if we have used readonly instead of const the problem would have been solved with updating SomeLibrary.dll only.

public class Options
    public static readonly int NetworkTimeout = 2000;

The static modifier has been added only to make the two codes above compatible. Note that all const fields are also static, but readonly fields can be either static or an instance field.

Tagged with: ,

YAXLib 2.0 is Released

Posted in C#, Programming by Sina Iravanian on April 17, 2010

I am finally finished with YAXLib 2.0. The CodeProject article is available here [+], and the source code is available from here [+].

See the ChangeLog file to see what is new, and read the CodeProject article and run the demo application to see what are the capabilities of the library. In short I can name these:

  • Structure freely the XML Result.
  • Serialize all known generic and non-generic collection classes in System.Collections, and System.Collections.Generic
  • Serialize single-dimensional, multi-dimensional, and jagged arrays.
  • Support for specifying path-like serialization addresses, e.g., "elem1/elem2/elem3", and "../elem1", and "./elem1".
  • Specify aliases for enums.
  • Choose the fields to serialize (public, or non-public properties, or member variables).
  • Serialize and deserialize objects through a reference to their base-class or interface.
  • Support for multi-stage deserialization,
  • and more …

The most joyful implementation parts of this library was adding the support for serialization and deserialization of multi-dimensional, and jagged arrays, and also the support for serialization and deserialization of objects through a reference to their base-class or interface.

Please let me know your bug reports and feature requests.

Tagged with: , ,