10

The title of the question is self explanatory. I wonder if a member that is declared const is singleton for all instances of the class or each instance has it's own copy.

I've read some questions about const but most of them refer to const variables inside a method.

rareyesdev
  • 2,337
  • 1
  • 25
  • 43

6 Answers6

8

C# constants are implemented as fields with the literal constraint in the Common Language Instructructure. Looking up ECMA-335 §I.8.6.1.2 provides the definitive answer (emphasis mine):

The literal constraint promises that the value of the location is actually a fixed value of a built-in type. The value is specified as part of the constraint. Compilers are required to replace all references to the location with its value, and the [Virtual Execution System] therefore need not allocate space for the location. This constraint, while logically applicable to any location, shall only be placed on static fields of compound types. Fields that are so marked are not permitted to be referenced from CIL (they shall be in-lined to their constant value at compile time), but are available using reflection and tools that directly deal with the metadata.

So there you go, the values of const fields must be copied by compilers directly into the instruction stream (typically using ldc.* instructions). They do not exist in a referencable location, but need to be available in the metadata and via reflection. They could be implemented like static fields, but do not have to.

Trillian
  • 6,207
  • 1
  • 26
  • 36
  • This is evident because the C# debugger does not allow breakpoints to be set at const assignments - i.e. they're "not there". –  Oct 03 '21 at 00:57
2

const implies static so there is only one instance per class.

Edit: Add Reference

clcto
  • 9,530
  • 20
  • 42
  • Necessarily that many? Can not a const be shared between classes? Think of `const string xyz="xyz";` - compile-time interning will take place. – ClickRick May 07 '14 at 22:40
  • I looked in [C# const reference](http://msdn.microsoft.com/en-us/library/e6w8fe1b.aspx) – rareyesdev May 07 '14 at 22:41
  • @ClickRick: Now you're talking about string interning and compiler optimizations, not semantics. – Ed S. May 07 '14 at 22:41
  • @agarwaen well in the [`static` reference](http://msdn.microsoft.com/en-us/library/98f28cdx.aspx) which I have linked you to 3 times now, it states "A constant or type declaration is implicitly a static member." – clcto May 07 '14 at 22:46
  • The constant definition is static, but the references to the constant itself are actually compiled with the constant's value. This has interesting ramifications for compatibility when constants change. – Paul Williams May 07 '14 at 22:49
  • @clcto Yes I read it. Thanks. I just wanted to point out that I looked in that place but didn't found anything. – rareyesdev May 07 '14 at 22:50
2

Constants are usually something that can be evaluated compile time and compiler is likely to replace it with the evaluated value.

Also Const means static (see link below)

A constant expression is an expression that can be fully evaluated at compile time. Therefore, the only possible values for constants of reference types are string and null.

Source:

C# static and const variables memory

Memory allocation for const in C#

C# do const fields use less memory?

Community
  • 1
  • 1
Dexters
  • 2,419
  • 6
  • 37
  • 57
2

Constants are resolved at compile time, and the actual value of the constant is stored in the compiled DLL in place of references to the constant.

In addition, the constant is saved as a member of the class in the DLL. This allows public constants to be referenced by external DLLs. However, the external references are also converted into the constant value when they are compiled.

A ramification of the compile properties of constants means that if DLL1 refers to a constant in an external DLL2, and the constant definition in DLL2 changes, then DLL1 will not have the updated value unless it is recompiled, too.

If you want to work around this problem, you're better off with public properties returning the constant. See the answer to this question for more information.

I confirmed the above behavior with .NET Reflector.

Community
  • 1
  • 1
Paul Williams
  • 16,585
  • 5
  • 47
  • 82
  • This is evident because the C# debugger does not allow breakpoints to be set at const assignments - i.e. they're "not there". :-) –  Oct 02 '21 at 21:06
1

I believe that value itself is in-lined anywhere it's referenced at compile time. Meaning, if I have const int x = 10; and then I use x 100 times throughout my source, each of those 100 references to x will actually just be replaced by 10 prior to the actual compilation.

evanmcdonnal
  • 46,131
  • 16
  • 104
  • 115
1

Const is meta-data...
It is not in memory, but using the const - telling the compiler "you see the literal under the name of that const... put it here" (literal is a number, or string, or null, in the middle of the code, like in for (int i = 0... that 0 is literal).

Now, in most cases - these (literals.. from now on - we're talking about literals) are value types... what singleton has to do with value types?! Nothing... The data of a value type is copied from one location to another. so it cannot be a singleton.

What about nulls? null is a possible value of a reference, which signals "I'm referencing nothing" - So again.. Singleton is irrelevant here (For nullable value types - null is just like the default constructor... And they're value types... So this is like case 1).

And what about string literals?! (eg: "hello world" in the middle of the code) This is a special case.

Every string literal is cached inside an intern table... So - every time you use the same string-literal - you're actually referencing the same object in memory. But is doesn't mean that every string with the same value is the same object: 

string ab = "ab";  
string anotherAB = "ab";  
string another = 'a'.ToString() + 'b'.ToString();    

Console.WriteLine(object.ReferenceEquals(ab, anotherAB)); // true
Console.WriteLine(object.ReferenceEquals(ab, "ab")); // true
Console.WriteLine(object.ReferenceEquals(ab, another)); // false
Console.WriteLine(object.ReferenceEquals("ab", another)); // false
Shlomi Borovitz
  • 1,700
  • 9
  • 9