¿Alguien puede aclarar por qué falla esta prueba unitaria en Visual Studio 2013?
[TestMethod] public void Inconceivable() { int? x = 0; Assert.AreEqual(typeof(int?), x.GetType()); }Su prueba está fallando porque:
Llamar a GetType en un tipo que acepta valores NULL hace que se realice 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 que acepta valores NULL.
Puede obtener más información en Cómo: identificar un tipo que acepta valores NULL .
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 el tipo subyacente de Nullable. Por lo tanto, no puede usar is para determinar si una variable es de tipo Nullable. El siguiente ejemplo muestra que el operador is trata una variable Nullable<int> como un int.
int? i = 5; if (i is int) { ... } // trueTiene razón al suponer que el compilador de C# está optimizando los tipos que aceptan valores NULL. Aquí hay una cita de C # en profundidad de Jon Skeet que debería responder a su pregunta:
Solo con respecto al empaquetado y desempaquetado, CLR tiene un comportamiento especial con respecto a los tipos que aceptan valores NULL. De hecho, el comportamiento solo cambió poco antes del lanzamiento de .NET 2.0, como resultado de las solicitudes de la comunidad.
Una instancia de Nullable se encuadra en una referencia nula (si no tiene un valor) o en un valor T encuadrado (si lo tiene). Nunca encajona a un "int anulable encajonado"; no existe tal tipo.
Hay un hilo similar en StackOverflow: ¿el tipo anulable no es un tipo anulable?