C# const declaration doc error

  • Thread starter Thread starter Blah
  • Start date Start date
B

Blah

In MSDN documentation it states..

Remarks
The constant declaration can declare multiple constants,
for example:
public const double x = 1.0, y = 2.0, z = 3.0;
The static modifier is not allowed in a constant
declaration.
A constant can participate in a constant expression, for
example:
public const int c1 = 5.0;
public const int c2 = c1 + 100;


Yet in VS.NET 2003 the compiler generates a static
modifier yet in MSDN it says its not allowed. If i dont
declare it static the object viewer says its static, and i
am also permitted to specify it as a static const. So,
MSDN wrong? or just typical developer badly explaining it?
 
What do you mean the compiler generates a static modifier? If you are
talking about what IL is produced, then you can't apply what is in the C#
language spec to what you see in the IL, because that follows a different
spec. Ultimately, a constant is represented as a static variable. It is a
C# construct only, and has nothing to do how it is represented in IL.

Hope this helps.
 
Hi Blah,

Blah said:
In MSDN documentation it states..

Remarks
The constant declaration can declare multiple constants,
for example:
public const double x = 1.0, y = 2.0, z = 3.0;
The static modifier is not allowed in a constant
declaration.
A constant can participate in a constant expression, for
example:
public const int c1 = 5.0;
public const int c2 = c1 + 100;


Yet in VS.NET 2003 the compiler generates a static
modifier yet in MSDN it says its not allowed. If i dont
declare it static the object viewer says its static, and i
am also permitted to specify it as a static const. So,
MSDN wrong? or just typical developer badly explaining it?
Click to expand...

Constants are implicitly static. Since they can only be one value
there's no reason to make them instance members and being static makes them
more flexible (can reference without an instance of the class). Are you sure
you can specify "static const"? For me the compiler (VS 2003) detects an
error as expected ("The constant 'MyClass.MY_CONSTANT' cannot be marked
static").

Regards,
Dan
 
Hi Blah,
Actually constants are only a meta data. There is no any fields behind them.
You can see that so called field has attribute *literal* applied.
Nicholas is right. The way you declare and use constants in c# is according
the c# spec and has nothing to do with IL and CLR.

B\rgds
100
 
The documentation states that its not possible to declare them static, when
infact i was permited to, its a doc error. Or badly explained.

It clearly states...
"The static modifier is not allowed in a constant declaration."

Yet I can do what it says I cannot do. and also the compiler itself (if you
check object browser) states that they are what the documentation says they
are Not.


My point is, its confusing and inaccurate in the documentation.
 
What is the benifit of specifying a const in C# as static then? What is the
difference between a static const (which MSDN says clearly that cannot be
done but it can) and a non static const.

Anybody care to enlighten me as MSDN does a good job of confusing the issue.
 
Hi,
The documentation states that its not possible to declare them static, when
infact i was permited to, its a doc error.
Click to expand...

What do you mean? My C# compiler emits an error if I try to put *static*
modifier in constant declaration.

B\rgds
100
 
100 said:
Actually constants are only a meta data. There is no any fields behind them.
Click to expand...

In what way? I can't see anything in any spec saying there aren't any
fields behind them, and reflection can certainly get them as fields:

using System;
using System.Reflection;

public class Test
{
public const int x = 5;

static void Main()
{
foreach (FieldInfo fi in typeof(Test).GetFields())
{
Console.WriteLine ("{0}={1}", fi.Name, fi.GetValue(null));
}
}
}

Yes, references to them are inlined, but I don't think that means
they're not fields.
 
bwahahahaha said:
The documentation states that its not possible to declare them static, when
infact i was permited to, its a doc error. Or badly explained.

It clearly states...
"The static modifier is not allowed in a constant declaration."

Yet I can do what it says I cannot do.
Click to expand...

Really? I get a compile-time error:

using System;

public class Test
{
static const int x = 5;

static void Main()
{
}
}

Test.cs(5,22): error CS0504: The constant 'Test.x' cannot be marked
static

Does the above really compile for you?
 
Mine builds ok on 2003. Bloody odd.

public static const int WM_COMMAND = 0x112;

Works for me.
 
try VS.NET 2003.


Jon Skeet said:
Really? I get a compile-time error:

using System;

public class Test
{
static const int x = 5;

static void Main()
{
}
}

Test.cs(5,22): error CS0504: The constant 'Test.x' cannot be marked
static

Does the above really compile for you?
Click to expand...
 
bwahahahaha said:
Mine builds ok on 2003. Bloody odd.

public static const int WM_COMMAND = 0x112;

Works for me.
Click to expand...

Doesn't work for me with VS.NET 2003. Is it definitely, definitely
building that file? Quick way to check: if you change it to

public xxx const int WM_COMMAND = 0x112;

does it *then* give a compiler error?
 
FWIW, I get a compiler error, as expected, on (yes, I'm using VS.NET 2003)

public class MyClass
{
public static const int WM_COMMAND = 0x112;
}


The constant 'xxx.WM_COMMAND' cannot be marked static


Brian W



bwahahahaha said:
Mine builds ok on 2003. Bloody odd.

public static const int WM_COMMAND = 0x112;

Works for me.
Click to expand...
 
IT worked for me today, strange.


Jon Skeet said:
Doesn't work for me with VS.NET 2003. Is it definitely, definitely
building that file? Quick way to check: if you change it to

public xxx const int WM_COMMAND = 0x112;

does it *then* give a compiler error?
Click to expand...
 
Hi Jon,
I meant fields in terms of memory storage. They are literals. They are just
meta data. Internally.
This is the reason why the only reference type that can be used as constant
is String.
Constants are part of the type's meta data so they has to be accessible via
reflection. And because they are more like fields they are treated by
reflection as fields.
Unfortuantely at the moment I can't point you to any spec saying that, event
though I'm sure there is such spec. Anyway this can be found in the books.

Because there is no memory storage behind (they are part of the type's meta
data) declaring them as instance doesn't make sense.

The only evidence I came up with

struct TestStruct
{
public const int Const = 100;
public int Value;
}
....
unsafe static void Foo()
{

Console.WriteLine(sizeof(TestStruct));
}

Foo prints 4. Which means that there is no memory storage for the constant.

B\rgds
100
 
100 said:
I meant fields in terms of memory storage.
Click to expand...

They're certainly not *instance* fields, but I don't see why an
implementation shouldn't also decide to keep a copy of the value along
with the rest of its static fields.

Because there is no memory storage behind (they are part of the type's meta
data) declaring them as instance doesn't make sense.

The only evidence I came up with

struct TestStruct
{
public const int Const = 100;
public int Value;
}
...
unsafe static void Foo()
{

Console.WriteLine(sizeof(TestStruct));
}

Foo prints 4. Which means that there is no memory storage for the constant.
Click to expand...

Not per instance, no - but then that's true of static fields in
general, and they're still fields.
 
They're certainly not *instance* fields, but I don't see why an
implementation shouldn't also decide to keep a copy of the value along
with the rest of its static fields.
Click to expand...
Why should it. The value of the constants is used only by compilers. One
can't get the adress of constant neither change it event with unmanaged
code. Constant's value is avaluated at compile time as the oposite to the
readonly (initonly) fields, which have to have memory storage to hold the
value.
Actually I think that the *implementation* keeps the value in the type's
internal structure for reflection's performance's sake. But it doesn't have
to do so. The value can be extracted from the meta data.
Which is not true for any other fields - static or instance.

B\rgds
100
 
100 said:
Why should it. The value of the constants is used only by compilers. One
can't get the adress of constant neither change it event with unmanaged
code. Constant's value is avaluated at compile time as the oposite to the
readonly (initonly) fields, which have to have memory storage to hold the
value.
Click to expand...

Although that's true as of reality, it doesn't really have to be like
that... that's an optimization compilers make, because it's the obvious use,
but there is a difference between constants and preprocessor values, that's
why #define was not equal to const in C++ unless you used optimizations.

In the real world, though, they are the same, and, i'm not sure about C#,
but I wouldn't be surprised they would use const values at compile time
(even with no optimizations), coz that's the most obvious way to use them,
and it's the way they should be used, and the way optimizations can be
actually performed (that's where you gain a variable being const anwyay).
Actually I think that the *implementation* keeps the value in the type's
internal structure for reflection's performance's sake. But it doesn't have
to do so. The value can be extracted from the meta data.
Which is not true for any other fields - static or instance.
Click to expand...

I don't know how the C# implementation is, so I can't say anything about
it... that sounds right anyway, but I can't confirm.

Javier Campos
Virtual Media Systems, S.L.
 
Why should it.
Convenience?

The value of the constants is used only by compilers. One
can't get the adress of constant neither change it event with unmanaged
code. Constant's value is avaluated at compile time as the oposite to the
readonly (initonly) fields, which have to have memory storage to hold the
value.
Click to expand...

It's also available for reflection though.
Actually I think that the *implementation* keeps the value in the type's
internal structure for reflection's performance's sake. But it doesn't have
to do so. The value can be extracted from the meta data.
Which is not true for any other fields - static or instance.
Click to expand...

I never claimed that it *had* to - I was just arguing against the idea
that it definitely *didn't*.
 
Back
Top