const and readonly

[TonyJ]

Hello!!

Assume I have this class declaration of MyTest below.
I just want to check with you if the two declarations for tal1 and tal2 is
almost the same.
The only difference is that const is set at compile but readonly can be set
at compile time or run time appart from
that they are the same.
Both is actually a class field because const is always automatically static
so for me these two
decalations is almost the same appart from my comment above.
Do you agree?

class MyTest
{
public static readonly int tal1 = 1;
public const int tal2 = 1;
....
}

//Tony

 

[Jon Skeet [C# MVP]]

Assume I have this class declaration of MyTest below.
I just want to check with you if the two declarations for tal1 and tal2 is
almost the same.
The only difference is that const is set at compile but readonly can be set
at compile time or run time appart from
that they are the same.
Both is actually a class field because const is always automatically static
so for me these two
decalations is almost the same appart from my comment above.
Do you agree?

class MyTest
{
public static readonly int tal1 = 1;
public const int tal2 = 1;
...
}

If the constants are only used within the same assembly, that's all
correct (const is limited to a select set of types, too).

Things are messier when you refer to the constant from a different
assembly. Whenever you refer to a const (whether in the same assembly
or not) it bakes the value of the const into the *referring* code -
instead of actually looking up the value of the field at execution
time.

That has a significant effect if you build different assemblies at
different times. Suppose you have Const.dll and PrintConst.exe which do
the obvious things. If Const.dll has a const with the value "First"
when you compile PrintConst.exe against it, then you change the const
in Const.dll to "Second" and *just* rebuild Const.dll, running
PrintConst.exe will still show "First" because the value has been
compiled into PrintConst.exe.

Does that make sense?

 

[TonyJ]

Hello!!

I understand but the solution for how .NET framework has solved it when
dealing with const between assemblies was not the best choice.

//Tony

 

[Jon Skeet [C# MVP]]

I understand but the solution for how .NET framework has solved it when
dealing with const between assemblies was not the best choice.

Well, it's useful occasionally - and easy to avoid, just by using
static readonly instead.

 

[Lasse Vågsæther Karlsen]

Well, it's useful occasionally - and easy to avoid, just by using
static readonly instead.

Not to split hairs or anything, but if it is constant, why is it
changing?

 

[Jon Skeet [C# MVP]]

Not to split hairs or anything, but if it is constant, why is it
changing?

Because someone *thought* it was a constant with one value, but that
turned out to be wrong. Or because someone used "const" without really
thinking about whether or not it was genuinely a constant.

I'm not saying it should happen, just that it does and it's worth being
aware of the consequences