Question on constants

[Simon Harvey]

Hi,

Is there any benefit to declaring variables as constants other than not
being able to overwrite them by mistake?
Thanks
Simon

[Anirudha Vengurlekar]

Hi,

I guess Constants get replaced with there value while compiling which helps
fast execution.

"Simon Harvey" <si**********@the-web-works.co.uk> wrote in message
news:uK*************@TK2MSFTNGP11.phx.gbl...

Hi,

Is there any benefit to declaring variables as constants other than not
being able to overwrite them by mistake?
Thanks
Simon

[J.Marsch]

Beware, though: I've read elsewhere that if you define a constant (as in a
const), and then use that constant as a parameter to a method call, that the
constant value (rather than a reference to the constant) will be encoded
method call. That's no big deal if you build all of your code at once, but
if the constant is in a shared shared, and you change its value in the
future, it won't necessarily "take" for existing, possibly deployed,
assemblies that use the constant value in a method call.
"Simon Harvey" <si**********@the-web-works.co.uk> wrote in message
news:uK*************@TK2MSFTNGP11.phx.gbl...

Hi,

Is there any benefit to declaring variables as constants other than not
being able to overwrite them by mistake?
Thanks
Simon

[Jared Parsons [MSFT]]

This is true. Declaring a variable const has that implication.

In fact, every reference made to a "const" variable, will be replaced with
the value of the variable when the code is compiled. Not just method calls.

This has some reprecussions when other people depend on your code. Take the
following scenario. Company A's product depends on your dll which contains
constant definitions. They ship their product built against version 1 of
your dll. Then you ship version 2 of the dll in which some of the
constants' values have changed. Because Company A's product was compiled
against version 1 of your dll, they are still using the constant values from
version 1. This could potentially cause their app to break.

--
Jared Parsons [MSFT]
ja******@online.microsoft.com
This posting is provided "AS IS" with no warranties, and confers no rights.
OR if you wish to include a script sample in your post please add "Use of
included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm"

"J.Marsch" <je****@ctcdeveloper.com> wrote in message
news:um**************@TK2MSFTNGP11.phx.gbl...

Beware, though: I've read elsewhere that if you define a constant (as in a const), and then use that constant as a parameter to a method call, that the constant value (rather than a reference to the constant) will be encoded
method call. That's no big deal if you build all of your code at once, but if the constant is in a shared shared, and you change its value in the
future, it won't necessarily "take" for existing, possibly deployed,
assemblies that use the constant value in a method call.
"Simon Harvey" <si**********@the-web-works.co.uk> wrote in message
news:uK*************@TK2MSFTNGP11.phx.gbl...

Hi,

Is there any benefit to declaring variables as constants other than not
being able to overwrite them by mistake?
Thanks
Simon

[Jon Skeet [C# MVP]]

Jared Parsons [MSFT] <ja******@online.microsoft.com> wrote:

This is true. Declaring a variable const has that implication.

In fact, every reference made to a "const" variable, will be replaced with
the value of the variable when the code is compiled. Not just method calls.

This has some reprecussions when other people depend on your code. Take the
following scenario. Company A's product depends on your dll which contains
constant definitions. They ship their product built against version 1 of
your dll. Then you ship version 2 of the dll in which some of the
constants' values have changed. Because Company A's product was compiled
against version 1 of your dll, they are still using the constant values from
version 1. This could potentially cause their app to break.

And this is why we have strong versioning, of course - Company A's
product should use version 1 of the DLL whether or not a version 2 is
also present.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Simon Harvey]

Thanks all

Simon

[Jared Parsons [MSFT]]

Another alternative.

Company A use a private copy of Company B's dll. That way when a global
update occurs (say in the GAC), Company A is not broken by the changes
Company B makes to their dll.

Then again, they may also be missing security updates.

--
Jared Parsons [MSFT]
ja******@online.microsoft.com
This posting is provided "AS IS" with no warranties, and confers no rights.
OR if you wish to include a script sample in your post please add "Use of
included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm"
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Jared Parsons [MSFT] <ja******@online.microsoft.com> wrote:

This is true. Declaring a variable const has that implication.

In fact, every reference made to a "const" variable, will be replaced with the value of the variable when the code is compiled. Not just method calls.
This has some reprecussions when other people depend on your code. Take the following scenario. Company A's product depends on your dll which contains constant definitions. They ship their product built against version 1 of your dll. Then you ship version 2 of the dll in which some of the
constants' values have changed. Because Company A's product was compiled against version 1 of your dll, they are still using the constant values from version 1. This could potentially cause their app to break.

And this is why we have strong versioning, of course - Company A's
product should use version 1 of the DLL whether or not a version 2 is
also present.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too