¿Cómo traducir "por defecto (SomeType)" de C# a CIL?

Question

Actualmente estoy trabajando en un problema que involucra la generación de código System.Reflection.Emit. Intento averiguar qué CIL emitir en los lugares donde usaría default(SomeType) en C#.

He realizado algunos experimentos básicos de Visual Studio 11 Beta. JustDecompile me muestra el siguiente resultado CIL para default(bool), default(string) y default(int?:

.locals init (
    [0] bool           V_0, 
    [1] string          V_1, 
    [2] valuetype [mscorlib]System.Nullable`1<int32> V_2  
) 

// bool b = default(bool); 
ldc.i4.0 
stloc.0 

// string s = default(string); 
ldnull 
stloc.1 

// int? ni = default(int?); 
ldloca.s V_2 
initobj valuetype [mscorlib]System.Nullable`1<int32> 

A juzgar por esto, default(T) parece que se resolvió por el compilador para el CIL más adecuado para los tipos dados.

---

Fui a ver lo que sucedería en el caso más general, utilizando tres métodos genéricos:

T CreateStructDefault<T>() where T : struct { return default(T); } 
T CreateClassDefault<T>() where T : class { return default(T); } 
T CreateClassNull<T>()  where T : class { return null;  } 

Los tres métodos producen los mismos CIL método de cuerpo:

.locals init (
    [0] !!T V_0, 
    [1] !!T V_1 
) 

IL_0000: nop  
IL_0001: ldloca.s V_1 
IL_0003: initobj !!T 
IL_0009: ldloc.1 
IL_000a: stloc.0 
IL_000b: br.s IL_000d 
IL_000d: ldloc.0 
IL_000e: ret 

---

Pregunta:

¿Puedo concluir de todo esto que C# 's default(SomeType) corresponde más estrechamente a CIL & hellip;

• initobj para los tipos no primitivos (excepto string?)
• ldc.iX.0/ldnull/etc. para los tipos primitivos (más string)?

y por qué CreateClassNull<T> no sólo se traducen en ldnull, pero a initobj en su lugar? Después de todo, se emitió ldnull para string (que también es un tipo de referencia).

Answer 1

¿Puedo concluir de todo esto que el C# 's default(SomeType) corresponde más estrechamente a CIL de initobj para los tipos no primitivos y ldc.i4.0, ldnull, etc., para los tipos primitivos?

Eso es un resumen razonable, pero una mejor manera de pensar en ello es: si el compilador de C# clasificaría como una constante default(T) entonces el valor de la constante de tiempo se emite compilación. Eso es cero para tipos numéricos, falso para bool y nulo para cualquier tipo de referencia. Si no se clasificara como una constante, entonces debemos (1) emitir una variable temporal, (2) obtener la dirección del temporal, (3) initobj esa variable temporal a través de su dirección y (4) asegurar que el valor temporal sea en la pila cuando es necesario.

¿por qué CreateClassNull<T> no solo se traduce a ldnull, sino a initobj?

Bueno, vamos a hacerlo a su manera y ver lo que sucede:

... etc 
.class private auto ansi beforefieldinit P 
     extends [mscorlib]System.Object 
{ 
    .method private hidebysig static !!T M<class T>() cil managed 
    { 
    .maxstack 1 
    ldnull 
    ret 
    } 
    ... etc 

...

D:\>peverify foo.exe 

Microsoft (R) .NET Framework PE Verifier. Version 4.0.30319.17379 
Copyright (c) Microsoft Corporation. All rights reserved. 

[IL]: Error: 
[d:\foo.exe : P::M[T]] 
[offset 0x00000001] 
[found Nullobjref 'NullReference']  
[expected (unboxed) 'T'] 
Unexpected type on the stack. 
1 Error(s) Verifying d:\foo.exe 

Eso sería probablemente por qué no hacemos eso.

Answer 2

Sí, eso es lo que default hace. Está en lo correcto al deducir que es solo azúcar sintáctica básicamente para 0 (o equivalentes).