Today, somebody asked me about the difference between constant and readonly type declarations and about when to use which one. Here is the interesting detailed comparison with three different examples…
a) private const int EXAMPLE1 = 450; b) private static readonly DateTime EXAPMLE2 = DateTime.Nowc) private readonly DateTime EXAMPLE3 = DateTime.Now;
The Difference:
1) Compile-time Constants
Symbols defined as const (EXAMPLE1 in this case) are replaced with the value of the constant at COMPILE TIME. Therefore statement if (ValueInConst == EXAMPLE1) would get converted to the same MSIL as if (ValueInConst == 450). The compiler replaces the symbol with the value of the constant. This is the main point to compile-time constants. Compile-time constants can only be used effectively for built-in integral and floating-point types (primitive types), enums, or strings. These are the only types that allow you to assign meaningful constant values as part of the initialization process. The IL generated for a compile-time constant contains the value, not the symbol. The value is "burned in" at compile time.
2) Readonly Values
Readonly values are those constants which cannot be modified after the constructor has executed. Readonly values are different, however, in that they're set at run time. You have much more flexibility in working with run time constants. Run-Time constants can be of any type; as long as you can assign them in your constructors, they will work. I could not create DateTime values with const but I can make readonly values from DateTime structures. Secondly, readonly values can be used for instance constants, storing different values for each instance of the class type. The main distinction is that readonly values are resolved at run time. The Intermediate Language generated when you reference a readonly constant reference the readonly variable, not the value.
Readonly values are those constants which cannot be modified after the constructor has executed. Readonly values are different, however, in that they're set at run time. You have much more flexibility in working with run time constants. Run-Time constants can be of any type; as long as you can assign them in your constructors, they will work. I could not create DateTime values with const but I can make readonly values from DateTime structures.
Secondly, readonly values can be used for instance constants, storing different values for each instance of the class type. The main distinction is that readonly values are resolved at run time. The Intermediate Language generated when you reference a readonly constant reference the readonly variable, not the value.
Which one to use?
The main difference between const and readonly fields is in their flexibility. Suppose you've defined both const and readonly fields like below: public class SomeValues { public static readonly constOne = 2; public const constTwo = 5; } Then, in an application these values are referenced and displayed using likely sum statement.Console.WriteLine("Sum is {0}",SomeValues.constOne + SomeValues.constTwo); If you run above snippet, Output will be “Sum is 7”. After few days you release a new version of the assembly with the following changes: public class SomeValues { public static readonly constOne = 50; public const constTwo = 30; } You distribute the assembly without rebuilding the application assembly. You'll get an absurd result as “Sum is 55” !!!!. The snippet now uses the value 50 as constOne, and 5 (OLD VALUE) as constTwo. The const value of cosntTwo (5) was placed into the application assembly by the compiler. On the other hand, constOne was declared as readonly, so it gets resolved at run time. Therefore, the application assembly uses the new value without recompiling the application assembly. Simply installing an updated version of the Infrastructure assembly is enough. Another advantage is that using readonly constants generates smaller sized assembly. Whenever you use a const value, compiler has to inserts the value of the constant. On the contrary, when you reference a readonly value compiler references that symbol not the value. On the flip side, readonly type doesn't work to initialize an attribute. The actual value of the object must be available at compile time for the attribute to get created correctly. Therefore, only values declared as const (or enums) can be used in this instance. One major advantage constants provide over readonly is that it can be used in places where readonly values cannot be used (as in Attributes). You can use const values as the parameters to attribute constructors but you can’t use readonly values, or variables There are some small performance gains using const instead of readonly but if you want to have little flexibility, readonly declaration has it for you. This flexibility overrides the small performance gains from using const. Everything except attribute parameters and enums should be declared readonly.
The main difference between const and readonly fields is in their flexibility. Suppose you've defined both const and readonly fields like below:
public class SomeValues { public static readonly constOne = 2; public const constTwo = 5; }
Then, in an application these values are referenced and displayed using likely sum statement.
Console.WriteLine("Sum is {0}",SomeValues.constOne + SomeValues.constTwo);
If you run above snippet, Output will be “Sum is 7”.
After few days you release a new version of the assembly with the following changes:
public class SomeValues { public static readonly constOne = 50; public const constTwo = 30; }
You distribute the assembly without rebuilding the application assembly. You'll get an absurd result as “Sum is 55” !!!!. The snippet now uses the value 50 as constOne, and 5 (OLD VALUE) as constTwo. The const value of cosntTwo (5) was placed into the application assembly by the compiler. On the other hand, constOne was declared as readonly, so it gets resolved at run time. Therefore, the application assembly uses the new value without recompiling the application assembly. Simply installing an updated version of the Infrastructure assembly is enough. Another advantage is that using readonly constants generates smaller sized assembly. Whenever you use a const value, compiler has to inserts the value of the constant. On the contrary, when you reference a readonly value compiler references that symbol not the value. On the flip side, readonly type doesn't work to initialize an attribute. The actual value of the object must be available at compile time for the attribute to get created correctly. Therefore, only values declared as const (or enums) can be used in this instance.
One major advantage constants provide over readonly is that it can be used in places where readonly values cannot be used (as in Attributes). You can use const values as the parameters to attribute constructors but you can’t use readonly values, or variables
There are some small performance gains using const instead of readonly but if you want to have little flexibility, readonly declaration has it for you. This flexibility overrides the small performance gains from using const. Everything except attribute parameters and enums should be declared readonly.
Remember Me
Page rendered at Wednesday, December 03, 2008 4:07:22 PM (Central Standard Time, UTC-06:00)
Disclaimer The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.