no, a const es un const, no es estático, es un caso especial, con diferentes reglas; es única conjunto en tiempo de compilación (no en tiempo de ejecución), y se maneja de manera diferente
el punto crucial aquí es lo que los medios siguientes:
var foo = SomeType.StaticValue;
vs
var bar = SomeType.ConstValue;
en el primer caso, lee el valor en tiempo de ejecución desde SomeType
, es decir, a través de ldsfld
; sin embargo, en el segundo caso, se compilará con el valor, es decirsi ConstValue
pasa a ser 123
, entonces el segundo es idéntica a:
var bar = 123;
en tiempo de ejecución, el hecho de que se trataba de SomeType
no existe, como el valor (123
) se evaluó por el compilador, y almacenado. Por lo tanto, necesita una reconstrucción para recoger nuevos valores.
Cambiando a static readonly
significa que se conserva el "cargar el valor de SomeType
".
Así lo siguiente:
static int Foo()
{
return Test.Foo;
}
static int Bar()
{
return Test.Bar;
}
...
static class Test
{
public static readonly int Foo = 123;
public const int Bar = 456;
}
compila como:
.method private hidebysig static int32 Bar() cil managed
{
.maxstack 8
L_0000: ldc.i4 0x1c8
L_0005: ret
}
.method private hidebysig static int32 Foo() cil managed
{
.maxstack 8
L_0000: ldsfld int32 ConsoleApplication2.Test::Foo
L_0005: ret
}
Tenga en cuenta que en el Bar
, la ldc
está cargando un valor directamente (0x1c8 == 456), con Test
completamente ido.
Para completar, la const es implementado con un campo estático, pero - es un literal campo, lo que significa: evaluado en el compilador, no en tiempo de ejecución.
.field public static literal int32 Bar = int32(0x1c8)
.field public static initonly int32 Foo
Es porque el compilador "alineará" el valor de la constante, en lugar de hacer referencia a una variable que proviene de otro ensamblaje. – ken2k
Nunca se supo de este comportamiento de consensos entre los ensamblajes. Buena pregunta –