C# const declaration doc error

[100]

Re: C# const declaration doc error

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.WriteLi ne(sizeof(TestS truct));
}

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

B\rgds
100

"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.19f8d5 2b7a97be809898a 6@msnews.micros oft.com...[color=blue]
> 100 <100@100.com> wrote:[color=green]
> > Actually constants are only a meta data. There is no any fields behind[/color][/color]
them.[color=blue]
>
> 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.Reflecti on;
>
> public class Test
> {
> public const int x = 5;
>
> static void Main()
> {
> foreach (FieldInfo fi in typeof(Test).Ge tFields())
> {
> Console.WriteLi ne ("{0}={1}", fi.Name, fi.GetValue(nul l));
> }
> }
> }
>
> Yes, references to them are inlined, but I don't think that means
> they're not fields.
>
> --
> Jon Skeet - <skeet@pobox.co m>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]

[Jon Skeet [C# MVP]]

Re: C# const declaration doc error

100 <100@100.com> wrote:[color=blue]
> I meant fields in terms of memory storage.[/color]

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.

<snip>
[color=blue]
> 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.WriteLi ne(sizeof(TestS truct));
> }
>
> Foo prints 4. Which means that there is no memory storage for the constant.[/color]

Not per instance, no - but then that's true of static fields in
general, and they're still fields.

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[100]

Re: C# const declaration doc error

> They're certainly not *instance* fields, but I don't see why an[color=blue]
> implementation shouldn't also decide to keep a copy of the value along
> with the rest of its static fields.[/color]
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

[Javier Campos]

Re: C# const declaration doc error


"100" <100@100.com> escribió en el mensaje
news:epV92TBlDH A.2068@TK2MSFTN GP09.phx.gbl...[color=blue]
> 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.[/color]

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).
[color=blue]
> 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[/color]
have[color=blue]
> to do so. The value can be extracted from the meta data.
> Which is not true for any other fields - static or instance.
>[/color]

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.

[Jon Skeet [C# MVP]]

Re: C# const declaration doc error

100 <100@100.com> wrote:[color=blue][color=green]
> > 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.[/color][/color]
[color=blue]
> Why should it.[/color]

Convenience?
[color=blue]
> 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.[/color]

It's also available for reflection though.
[color=blue]
> 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.[/color]

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

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[100]

Re: C# const declaration doc error

> I never claimed that it *had* to - I was just arguing against the idea[color=blue]
> that it definitely *didn't*.[/color]

I haven't said it definitely didn't. I said that this is the idea behind the
literals. How it is implemented is different story, isn't it.

B\rgds
100