documentacion - referencia c#

¿El compilador de C#está optimizando los tipos anulables?

Question

¿Puede alguien arrojar alguna luz sobre por qué esta prueba de unidad está fallando en Visual Studio 2013?

[TestMethod]
public void Inconceivable()
{
    int? x = 0;
    Assert.AreEqual(typeof(int?), x.GetType());
}

Answer 1

Su prueba está fallando porque:

Al llamar a GetType en un tipo anulable, se realiza una operación de boxeo cuando el tipo se convierte implícitamente en Object . Por lo tanto, GetType siempre devuelve un objeto Type que representa el tipo subyacente, no el tipo de Nullable.

Puede leer más en Cómo identificar un tipo anulable .

Algunos ejemplos tomados del artículo anterior:

int? i = 5;
Type t = i.GetType();
Console.WriteLine(t.FullName); //"System.Int32"

También tenga en cuenta que:

El operador C # is también opera en un tipo subyacente de Nullable. Por lo tanto, no puede usar es para determinar si una variable es un tipo de Nullable. El siguiente ejemplo muestra que el operador is trata una variable <int> anulable como un int.

int? i = 5;
if (i is int) { ... } // true   

Tiene razón al suponer que el compilador de C # está optimizando los tipos anulables. Aquí hay una cita de C # de Jon Skeet en profundidad que debería responder a su pregunta:

Es solo con respecto al boxeo y al unboxing que el CLR tiene algún comportamiento especial con respecto a los tipos anulables. De hecho, el comportamiento solo se cambió poco antes del lanzamiento de .NET 2.0, como resultado de las solicitudes de la comunidad.

Una instancia de Nullable está encuadrada en una referencia nula (si no tiene un valor) o en un valor en caja de T (si la tiene). Nunca encaja en un "box nullable int", no existe tal tipo.

Hay un subproceso similar en : ¿El tipo de nullable no es un tipo de nullable?