C#: ¿Por qué las mutaciones en las estructuras de solo lectura no se rompen?

Question

En C#, si usted tiene un struct así:

struct Counter 
{ 
    private int _count; 

    public int Value 
    { 
     get { return _count; } 
    } 

    public int Increment() 
    { 
     return ++_count; 
    } 
} 

Y usted tiene un programa de este modo:

static readonly Counter counter = new Counter(); 

static void Main() 
{ 
    // print the new value from the increment function 
    Console.WriteLine(counter.Increment()); 
    // print off the value stored in the item 
    Console.WriteLine(counter.Value); 
} 

La salida del programa será:

1 
0 

Esto parece completamente incorrecto Yo esperaría que la salida fuera dos 1s (como lo es si Counter es un class o si struct Counter : ICounter y es un ICounter) o es un error de compilación. Me doy cuenta de que detectar esto en el tiempo de compilación es un asunto bastante difícil, pero este comportamiento parece violar la lógica.

¿Hay alguna razón para este comportamiento más allá de la dificultad de implementación?

Answer 1

structs son tipos de valor y, por lo tanto, tienen un tipo de valor sematics. Esto significa que cada vez que accede a la estructura, básicamente trabaja con una copia del valor de la estructura.

En su muestra no cambia el original struct sino solo una copia temporal del mismo.

ver aquí para más explicaciones:

Why are mutable structs evil

Answer 2

En .NET, un método de instancia estructura es semánticamente equivalente a un método estático con una estructura ref un parámetro adicional de la estructura tipo. Por lo tanto, teniendo en cuenta las declaraciones:

struct Blah { 
    public int value; 
    public void Add(int Amount) { value += Amount; } 
    public static void Add(ref Blah it; int Amount; it.value += Amount;} 
} 

El método llama:

someBlah.Add(5); 
Blah.Add(ref someBlah, 5); 

son semánticamente equivalentes, excepto por una diferencia: solamente se permitirá a esta última llamada si someBlah es una ubicación de almacenamiento mutable (variable, campo, etc.) y no si se trata de una ubicación de almacenamiento de solo lectura, o un valor temporal (resultado de leer una propiedad, etc.).

Esto enfrentó a los diseñadores de lenguajes .NET con un problema: no permitir el uso de cualquier función miembro en las estructuras de solo lectura sería molesto, pero no querían permitir que las funciones miembro escribieran a las variables de solo lectura. Decidieron "punt", y lo hacen de modo que llamar a un método de instancia en una estructura de solo lectura hará una copia de la estructura, invocar la función sobre eso y luego descartarla. Esto tiene el efecto de ralentizar llamadas a métodos de instancia que no escriben la estructura subyacente, y hacer que un intento de utilizar un método que actualice la estructura subyacente en una estructura de solo lectura produzca semántica rota diferente de lo que se lograría si se pasa la estructura directamente. Tenga en cuenta que el tiempo extra tomado por la copia casi nunca arrojará la semántica correcta en casos que no hubieran sido correctos sin la copia.

Uno de mis principales problemas en .net es que todavía hay (al menos 4.0, y probablemente 4.5) todavía ningún atributo a través del cual una función de miembro de estructura puede indicar si modifica this.La gente discute sobre cómo las estructuras deberían ser inmutables, en lugar de proporcionar las herramientas para permitir que las estructuras ofrezcan métodos de mutación seguros. Esto, a pesar del hecho de que las llamadas estructuras "inmutables" son una mentira. Todos los tipos de valores no triviales en ubicaciones de almacenamiento mutables son mutables, como todos los tipos de valores encuadrados. Hacer una estructura "inmutable" puede obligar a uno a reescribir una estructura completa cuando uno solo quiere cambiar un campo, pero desde struct1 = struct2 muta struct1 copiando todos los campos públicos y privados de struct2, y no hay nada que sea la definición de tipo para la estructura puede hacer para evitar que (excepto que no tenga ningún campo) no haga nada para evitar una mutación inesperada de los miembros de la estructura. Además, debido a problemas de enhebrado, las estructuras tienen una capacidad muy limitada para imponer cualquier tipo de relación invariable entre sus campos. En mi humilde opinión, generalmente sería mejor para una estructura permitir el acceso arbitrario al campo, dejando en claro que cualquier código que reciba una estructura debe verificar si sus campos cumplen con todas las condiciones requeridas, en lugar de tratar de evitar la formación de estructuras que no cumplan con las condiciones.