views:

6461

answers:

19

What is the difference between const and readonly and do you use one over the other?

A: 

I believe a const value is the same for all objects (and must be initialized with a literal expression), whereas readonly can be different for each instantiation...

Daren Thomas
+13  A: 

This explains it. Summary: const must be initialized at declaration time, readonly can be initialized on the constructor (and thus have a different value depending on the constructor used).

EDIT: See Gishu's gotcha above for the subtle difference

Vinko Vrsalovic
+6  A: 

A const is a compile-time constant whereas readonly allows a value to be calculated at run-time and set in the constructor or field initializer. So, a 'const' is always constant but 'readonly' is read-only once it is assigned.

Eric Lippert of the C# team has more information on different types of immutability

Wheelie
+57  A: 

There is a gotcha with consts! If you reference constant from other assembly it's value will be compiled right into calling assembly. That way when you update constant in referenced assembly it won't change in calling assembly!

aku
Uping you... coz you got in first. I took a few min more to write up an example :)
Gishu
Heh, I wounder what would happen when SO goes public. I just can't type so fast to be first out of N thousand users :)
aku
but there will be a thousand more questions. in the end, all will work out :)
David Schmitt
+110  A: 

Apart from the apparent diff of

  • having to declare the value at the time of a definition for a const VS readonly values can be computed dynamically but need to be assigned before the ctor exits.. after that it is frozen.
  • 'const's are implicitly static. You use a ClassName.ConstantName notation to access them.

There is a subtle difference. Consider a class defined in AssemblyA.

public class Const_V_Readonly
{
  public const int I_CONST_VALUE = 2;
  public readonly int I_RO_VALUE;
  public Const_V_Readonly()
  {
     I_RO_VALUE = 3;
  }
}

AssemblyB references AssemblyA and uses these values in code. When this is compiled,

  • in the case of the const value, it is like a find-replace, the value 2 is 'baked into' the AssemblyB's IL. This means that tomorrow if I update I_CONST_VALUE to 20 in the future. Assembly B would still have 2 till I recompile it.
  • in the case of the readonly value, it is like a ref to a memory location. The value is not baked into AssemblyB's IL. This means that if the memory location is updated, Assembly B gets the new value without recompilation. So if I_RO_VALUE is updated to 30, you only need to build AssemblyA. All clients do not need to be recompiled.

So if you are confident that the value of the constant won't change use a const.

public const int CM_IN_A_METER = 100;

But if you have a constant that may change (e.g. w.r.t. precision).. or when in doubt, use a readonly.

public readonly float PI = 3.14;

Update: Aku needs to get a mention coz he pointed this out first. Also I need to plug where I learned this.. Effective C# - Bill Wagner

Gishu
Gishu, thanks. In fact you're the first person on my memory who pointed out that he wasn't the first who posted something. I appreciate it. Unfortunately I stuck at 200 rep limit again, so I won't receive any points next 24 hours :-)
aku
+1  A: 

Variables marked const are little more than strongly typed #define macros, at compile time const variable references are replaced with inline literal values. As a consequence only certain built-in primitive value types can be used in this way. Variables marked readonly can be set, in a constructor, at run-time and their read-only-ness is enforced during run-time as well. There is some minor performance cost associated with this but it means you can use readonly with any type (even reference types).

Also, const variables are inherently static, whereas readonly variables can be instance specific if desired.

Wedge
Added that consts are *strongly typed* #define macros. Otherwise, we may scare off all the C or C++ people. :-)
Jason Baker
A: 

I fully aggree with Gishu's answer. As a rule of thumb, to make my life easier I use const only for private members.

Grzenio
+7  A: 

Just to add, ReadOnly for reference types only makes the reference readonly not the values. For example:

public class Const_V_Readonly
{
  public const int I_CONST_VALUE = 2;
  public readonly char[] I_RO_VALUE = new Char[]{'a', 'b', 'c'};

  public UpdateReadonly()
  {
     I_RO_VALUE[0] = 'V'; //perfectly legal and will update the value
     I_RO_VALUE = new char[]{'V'}; //will cause compiler error
  }
}
L2Type
A: 

One thing to add to what people have said above. If you have an assembly containing a readonly value (e.g. readonly MaxFooCount = 4; ), you can change the value that calling assemblies see by shipping a new version of that assembly with a different value (e.g. readonly MaxFooCount = 5;)

But with a const, it would be folded into the caller's code when the caller was compiled.

If you've reached this level of C# proficiency, you are ready for Bill Wagner's book, Effective C#: 50 Specific Ways to Improve Your C# Which answers this question in detail, (and 49 other things).

Anthony
A: 

The key difference is that Const is the C equivalent of #DEFINE. The number literally gets substituted a-la precompiler. Readonly is actually treated as a variable.

This distinction is especially relevant when you have Project A depending on a Public constant from Project B. Suppose the public constant changes. Now your choice of const/readonly will impact the behavior on project A:

Const: project A does not catch the new value (unless it is recompiled with the new const, of course) because it was compiled with the constants subtituted in.

ReadOnly: Project A will always ask project B for it's variable value, so it will pick up the new value of the public constant in B.

Honestly, I would recommend you use readonly for nearly everything except truly universal constants ( e.g. Pi, Inches_To_Centimeters). For anything that could possibly change, I say use readonly.

Hope this helps, Alan.

AlanR
+1  A: 

You can use const variables as input to attribute constructors but not readonly variables.

Example:

public static class Text {
  public const string ConstDescription = "This can be used.";
  public readonly static string ReadonlyDescription = "Cannot be used.";
}

public class Foo 
{
  [Description(Text.ConstDescription)]
  public int BarThatBuilds {
    { get; set; }
  }

  [Description(Text.ReadOnlyDescription)]
  public int BarThatDoesNotBuild {
    { get; set; }
  }
}
Hallgrim
+1  A: 
Mark T
Yes that is more of a general theme. If you have a get only property exposing an arraylist, you can still modify the arraylist. You cannot set a different arraylist to that property, but you cannot stop the user from altering the arraylist.
Gishu
A: 

One of the team members in our office provided the following guidance on when to use const, static, and readonly:

  • Use const when you have a variable of a type you can know at runtime (string literal, int, double, enums,...) that you want all instances or consumers of a class to have access to where the value should not change.
  • Use static when you have data that you want all instances or consumers of a class to have access to where the value can change.
  • Use static readonly when you have a variable of a type that you cannot know at runtime (objects) that you want all instances or consumers of a class to have access to where the value should not change.
  • Use readonly when you have an instance level variable you will know at the time of object creation that should not change.

One final note: a const field is static, but the inverse is not true.

Scott A. Lawrence
+2  A: 

There is a small gotcha with readonly. A readonly field can be set multiple times within the constructor(s). Even if the value is set in two different chained constructors it is still allowed.


public class Sample {
    private readonly string ro;

    public Sample() {
        ro = "set";
    }

    public Sample(string value) : this() {
        ro = value; // this works even though it was set in the no-arg ctor
    }
}
Mike Two
+4  A: 

Constants

  • Constants are static by default
  • They must have a value at compilation-time (you can have e.g. 3.14 * 2, but cannot call methods)
  • Could be declared within functions
  • Are copied into every assembly that uses them (every assembly gets a local copy of values)
  • Can be used in attributes

Readonly instance fields

  • Must have set value by the time constructor exits
  • Are evaluated when instance is created

Static readonly fields

  • Are evaluated when code execution hits class reference (when new instance is created or a static method is executed)
  • Must have an evaluated value by the time the static constructor is done
  • It's not recommended to put ThreadStaticAttribute on these (static constructors will be executed in one thread only and will set the value for its thread; all other threads will have this value uninitialized)
splattne
+3  A: 

Here's another link demonstrating how const isn't version safe, or relevant for reference types.

Summary:

  • The value of your const property is set at compile time and can't change at runtime
  • Const can't be marked as static - the keyword denotes they are static, unlike readonly fields which can.
  • Const can't be anything except value (primitive) types
  • The readonly keyword marks the field as unchangeable. However the property can be changed inside the constructor of the class
  • The readonly only keyword can also be combined with static to make it act in the same way as a const (atleast on the surface). There is a marked difference when you look at the IL between the two
  • const fields are marked as "literal" in IL while readonly is "initonly"
Chris S
+1  A: 

A constant will be compiled into the consumer as a literal value while the static string will serve as a reference to the value defined.

As an exercise, try creating an external library and consume it in a console application, then alter the values in the library and recompile it (without recompiling the consumer program), drop the DLL into the directory and run the EXE manually, you should find that the constant string does not change.

Brett Ryan
I sincerely doubt that is true... I will go check.
kronoz
Russ Cam
@kronoz - This answer _is_ correct.
Andrew Hare
http://my.safaribooksonline.com/0321245660/pref01#X2ludGVybmFsX1NlY3Rpb25Db250ZW50P3htbGlkPTAzMjEyNDU2NjAvY2gwMWxldjFzZWMy
Russ Cam
Wow. It is true...! How frightening.
kronoz
@Andrew Hare - yes, I just checked. I am very surprised, that is a real gotcha, I'm really very surprised by that, amazed that is the case...!
kronoz
I do object, however, to the use of the word pointer here. It's not a pointer, it's a reference, and there *is* a difference in C# as you can manipulate unmanaged pointers in unsafe mode so it's important to distinguish between the two.
kronoz
Not to mention the value itself is immutable, so you can't change it (well, not without some funky evil underhand manipulation). Anyway :)
kronoz
+1  A: 

Principally; you can assign a value to a static readonly field to a non-constant value at runtime, whereas a const has to be assigned a constant value.

kronoz
+1  A: 

Yet another gotcha: readonly values can be changed by "devious" code via reflection.

var fi = this.GetType().BaseType.GetField("_someField", BindingFlags.Instance | BindingFlags.NonPublic);
fi.SetValue(this, 1);

Can I change a private readonly inherited field in C# using reflection?

Greg