469,575 Members | 1,441 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,575 developers. It's quick & easy.

Question on constants

Hi,

Is there any benefit to declaring variables as constants other than not
being able to overwrite them by mistake?
Thanks
Simon
Nov 15 '05 #1
6 1204
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

Nov 15 '05 #2
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

Nov 15 '05 #3
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


Nov 15 '05 #4
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
Nov 15 '05 #5
Thanks all

Simon
Nov 15 '05 #6
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

Nov 15 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

13 posts views Thread by poison.summer | last post: by
2 posts views Thread by yawnmoth | last post: by
4 posts views Thread by D. Yates | last post: by
10 posts views Thread by Steven W. Orr | last post: by
3 posts views Thread by Steven W. Orr | last post: by
6 posts views Thread by lazy | last post: by
3 posts views Thread by Microsoft | last post: by
54 posts views Thread by shuisheng | last post: by
reply views Thread by suresh191 | last post: by
4 posts views Thread by guiromero | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.