const and readonly

[puzzlecracker]

What is the difference between two? when each one is used?

Thanks

[Peter Morris]

const is set at compile time, readonly is set within the constructor.

[puzzlecracker]

On Sep 29, 11:46*am, "Peter Morris" <[e-mail]:

const is set at compile time, readonly is set within the constructor.

Any reason to use readonly then?

[Peter Duniho]

On Mon, 29 Sep 2008 09:21:33 -0700, puzzlecracker <ir*********@gmail.com>
wrote:

On Sep 29, 11:46Â*am, "Peter Morris" <[e-mail]:

>const is set at compile time, readonly is set within the constructor.

Any reason to use readonly then?

Two reasons:

-- when you don't know the value of the variable at compile-time
-- when the variable is a type that doesn't support "const" (i.e. most
reference types)

Pete

[Peter Morris]

Any reason to use readonly then?

Yes. When you have a class that accepts a value in its constructor, you
store the passed value but do not think it should change. Marking it
readonly makes sure you don't screw up later and try to change it.

[Newsgroup]

Few more info

1) You cannot initialize a compile-time constant using the new operator
2) Const must be used when the value types are avaiable at compile time
3) For reference type constants use 'readonly'

"Peter Morris" <mr*********@SPAMgmail.comwrote in message
news:eg**************@TK2MSFTNGP03.phx.gbl...

>Any reason to use readonly then?

Yes. When you have a class that accepts a value in its constructor, you
store the passed value but do not think it should change. Marking it
readonly makes sure you don't screw up later and try to change it.

[Jon Skeet [C# MVP]]

Newsgroup <ji*******@gmail.comwrote:

Few more info

1) You cannot initialize a compile-time constant using the new operator
2) Const must be used when the value types are avaiable at compile time
3) For reference type constants use 'readonly'

Strings are reference types, and they can be const - and in fact any
other reference type field can be const to, but the only supported
value is null :)

--
Jon Skeet - <sk***@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

[Pavel Minaev]

On Sep 29, 8:21*pm, puzzlecracker <[e-mail]:

On Sep 29, 11:46*am, "Peter Morris" <[e-mail]:

const is set at compile time, readonly is set within the constructor.

Any reason to use readonly then?

Versioning. When you make a library, you should only use non-private/
internal const if you can guarantee that the value won't change in the
future versions of the library. The reason is simple: when an
application references your library, and its code uses the constant,
the value of that constant is substituted directly into the compiled
assembly. Even if you later change the library to a newer one, the
compiled client code will still use the old value of the constant.

With readonly, it is not the case - it is a proper variable, and its
value is actually read at run-time when the assembly is loaded, so if
it changes in the assembly, the change will be seen by all clients on
the next run.

In general, when in doubt, prefer readonly. The only thing you really
lose is the ability to use it as a case label in a switch statement;
but you will certainly not introduce silent breakage, as is possible
with const and separate builds.