¿Qué puede hacer en MSIL que no puede hacer en C # o VB.NET? [cerrado]

Todo el código escrito en lenguajes .NET se compila en MSIL, pero ¿hay tareas / operaciones específicas que solo puede hacer usando MSIL directamente?

Hagamos también que las cosas se hagan más fácilmente en MSIL que C #, VB.NET, F #, j # o cualquier otro lenguaje .NET.

Hasta ahora tenemos esto:

1. Recursividad de la cola
2. Co / Contravarianza Genérica
3. Sobrecargas que difieren solo en los tipos de retorno
4. Anular modificadores de acceso
5. Tener una clase que no pueda heredar de System.Object
6. Excepciones filtradas (se puede hacer en vb.net)
7. Llamando a un método virtual del tipo de clase estática actual.
8. Obtenga un identificador de la versión en caja de un tipo de valor.
9. Haz un intento / falla.
10. Uso de nombres prohibidos.
11. Defina sus propios constructores sin parámetros para los tipos de valor .
12. Definir eventos con un raiseelemento.
13. Algunas conversiones permitidas por el CLR pero no por C #.
14. Hacer un main()método no como el .entrypoint.
15. trabajar con los tipos nativos inty nativos unsigned intdirectamente.
16. Juega con punteros transitorios.
17. directiva emitbyte en MethodBodyItem
18. Lanza y atrapa tipos que no sean del sistema.
19. Heredar enumeraciones (sin verificar)
20. Puede tratar una matriz de bytes como una matriz (4x más pequeña) de entradas.
21. Puede tener un campo / método / propiedad / evento, todos tienen el mismo nombre (sin verificar).
22. Puede volver a ramificarse en un bloque try desde su propio bloque catch.
23. Tiene acceso al especificador de acceso famandassem ( protected internales fam o assem)
24. Acceso directo a la <Module>clase para definir funciones globales, o un inicializador de módulo.

MSIL permite sobrecargas que difieren solo en los tipos de retorno debido a

call void [mscorlib]System.Console::Write(string)

o

callvirt int32 ...

La mayoría de los lenguajes .Net, incluidos C # y VB, no utilizan la función de recursión de cola del código MSIL.

La recursividad de cola es una optimización que es común en lenguajes funcionales. Ocurre cuando un método A termina devolviendo el valor del método B de tal manera que la pila del método A se puede desasignar una vez que se realiza la llamada al método B.

El código MSIL admite la recursión de cola explícitamente, y para algunos algoritmos podría ser una optimización importante. Pero dado que C # y VB no generan las instrucciones para hacerlo, debe hacerse manualmente (o usando F # o algún otro lenguaje).

Aquí hay un ejemplo de cómo la recursividad de cola puede implementarse manualmente en C #:

private static int RecursiveMethod(int myParameter)
{
    // Body of recursive method
    if (BaseCase(details))
        return result;
    // ...

    return RecursiveMethod(modifiedParameter);
}

// Is transformed into:

private static int RecursiveMethod(int myParameter)
{
    while (true)
    {
        // Body of recursive method
        if (BaseCase(details))
            return result;
        // ...

        myParameter = modifiedParameter;
    }
}

Es una práctica común eliminar la recursividad moviendo los datos locales de la pila de hardware a una estructura de datos de pila asignada en el montón. En la eliminación de recursión de cola como se muestra arriba, la pila se elimina por completo, lo cual es una optimización bastante buena. Además, el valor de retorno no tiene que recorrer una larga cadena de llamadas, sino que se devuelve directamente.

Pero, de todos modos, el CIL proporciona esta característica como parte del lenguaje, pero con C # o VB debe implementarse manualmente. (El jitter también es libre de hacer esta optimización por sí solo, pero ese es un problema completamente diferente).

En MSIL, puede tener una clase que no puede heredar de System.Object.

Código de muestra: compílelo con ilasm.exe ACTUALIZACIÓN: debe usar "/ NOAUTOINHERIT" para evitar que el ensamblador se herede automáticamente.

// Metadata version: v2.0.50215
.assembly extern mscorlib
{
  .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )                         // .z\V.4..
  .ver 2:0:0:0
}
.assembly sample
{
  .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilationRelaxationsAttribute::.ctor(int32) = ( 01 00 08 00 00 00 00 00 ) 
  .hash algorithm 0x00008004
  .ver 0:0:0:0
}
.module sample.exe
// MVID: {A224F460-A049-4A03-9E71-80A36DBBBCD3}
.imagebase 0x00400000
.file alignment 0x00000200
.stackreserve 0x00100000
.subsystem 0x0003       // WINDOWS_CUI
.corflags 0x00000001    //  ILONLY
// Image base: 0x02F20000


// =============== CLASS MEMBERS DECLARATION ===================

.class public auto ansi beforefieldinit Hello
{
  .method public hidebysig static void  Main(string[] args) cil managed
  {
    .entrypoint
    // Code size       13 (0xd)
    .maxstack  8
    IL_0000:  nop
    IL_0001:  ldstr      "Hello World!"
    IL_0006:  call       void [mscorlib]System.Console::WriteLine(string)
    IL_000b:  nop
    IL_000c:  ret
  } // end of method Hello::Main
} // end of class Hello

Es posible combinar los modificadores protectedy internalacceder. En C #, si escribe protected internal, se puede acceder a un miembro desde el ensamblado y desde las clases derivadas. A través de MSIL puede obtener un elemento que se puede acceder desde las clases derivadas dentro del conjunto única . (¡Creo que podría ser muy útil!)

Ooh, no vi esto en ese momento. (Si agrega la etiqueta jon-skeet, es más probable, pero no la reviso con tanta frecuencia).

Parece que ya tienes respuestas bastante buenas. Adicionalmente:

• No puede obtener un identificador de la versión en caja de un tipo de valor en C #. Puedes en C ++ / CLI
• No puede hacer una prueba / falla en C # ("falla" es como "atrapar todo y volver a lanzar al final del bloque" o "finalmente, pero solo en caso de falla")
• Hay muchos nombres que están prohibidos por C # pero IL legales
• IL le permite definir sus propios constructores sin parámetros para los tipos de valor .
• No puede definir eventos con un elemento "raise" en C #. (En VB se tiene que para los eventos personalizados, pero los acontecimientos "por defecto" no se incluye uno).
• Algunas conversiones están permitidas por CLR pero no por C #. Si pasa por objectC #, a veces funcionará. Vea una pregunta uint [] / int [] SO para ver un ejemplo.

Agregaré a esto si pienso en otra cosa ...

El CLR ya admite co / contravarianza genérica, pero C # no obtendrá esta característica hasta 4.0

• Características de C # 4.0
• Co / Contravarianza

En IL puedes lanzar y atrapar cualquier tipo, no solo los tipos derivados System.Exception.

IL tiene la distinción entre cally callvirtpara llamadas a métodos virtuales. Al usar el primero, puede forzar la llamada a un método virtual del tipo de clase estática actual en lugar de la función virtual en el tipo de clase dinámica.

C # no tiene forma de hacer esto:

abstract class Foo {
    public void F() {
        Console.WriteLine(ToString()); // Always a virtual call!
    }

    public override string ToString() { System.Diagnostics.Debug.Assert(false); }
};

sealed class Bar : Foo {
    public override string ToString() { return "I'm called!"; }
}

VB, como IL, puede emitir llamadas no virtuales mediante el uso de la MyClass.Method()sintaxis. En lo anterior, esto sería MyClass.ToString().

En un try / catch, puede volver a ingresar el bloque try desde su propio bloque catch. Entonces, puedes hacer esto:

.try {
    // ...

  MidTry:
    // ...

    leave.s RestOfMethod
}
catch [mscorlib]System.Exception {
    leave.s MidTry  // branching back into try block!
}

RestOfMethod:
    // ...

AFAIK no puedes hacer esto en C # o VB

Con IL y VB.NET puede agregar filtros al detectar excepciones, pero C # v3 no admite esta función.

Este ejemplo de VB.NET está tomado de http://blogs.msdn.com/clrteam/archive/2009/02/05/catch-rethrow-and-filters-why-you-should-care.aspx (tenga When ShouldCatch(ex) = Trueen cuenta Cláusula de captura):

Try
   Foo()
Catch ex As CustomBaseException When ShouldCatch(ex)
   Console.WriteLine("Caught exception!")
End Try

Hasta donde sé, no hay forma de crear inicializadores de módulo (constructores estáticos para un módulo completo) directamente en C #:

http://blogs.msdn.com/junfeng/archive/2005/11/19/494914.aspx

Native types
Puede trabajar directamente con los tipos int nativo e int sin signo nativo (en c # solo puede trabajar en un IntPtr que no es lo mismo.

Transient Pointers
Puede jugar con punteros transitorios, que son punteros a tipos administrados pero garantizados para no moverse en la memoria ya que no están en el montón administrado. No estoy completamente seguro de cómo podría usar esto de manera útil sin jugar con el código no administrado, pero no está expuesto a los otros idiomas directamente solo a través de cosas como stackalloc.

<Module>
puede meterse con la clase si así lo desea (puede hacerlo reflexionando sin necesidad de IL)

.emitbyte

15.4.1.1 La directiva .emitbyte MethodBodyItem :: =… | .emitbyte Int32 Esta directiva hace que se emita un valor de 8 bits sin signo directamente en el flujo CIL del método, en el punto en el que aparece la directiva. [Nota: la directiva .emitbyte se utiliza para generar pruebas. No es necesario para generar programas regulares. nota final]

.entrypoint
Tiene un poco más de flexibilidad en esto, puede aplicarlo a métodos que no se llaman Main, por ejemplo.

lea las especificaciones , estoy seguro de que encontrará algunas más.

Puede hackear la anulación de método co / contra-varianza, que C # no permite (¡esto NO es lo mismo que la varianza genérica!). Tengo más información sobre cómo implementar esto aquí , y las partes 1 y 2

Creo que lo que seguía deseando (con razones completamente equivocadas) era la herencia en Enums. No parece algo difícil de hacer en SMIL (ya que las enumeraciones son solo clases), pero no es algo que la sintaxis de C # quiera que hagas.

Aquí hay más:

1. Puede tener métodos de instancia adicionales en los delegados.
2. Los delegados pueden implementar interfaces.
3. Puede tener miembros estáticos en delegados e interfaces.

20) Puede tratar una matriz de bytes como una matriz (4x más pequeña) de entradas.

Utilicé esto recientemente para hacer una implementación rápida de XOR, ya que la función CLR xor opera en ints y necesitaba hacer XOR en una secuencia de bytes.

El código resultante medido es ~ 10 veces más rápido que el equivalente hecho en C # (haciendo XOR en cada byte).

===

No tengo suficiente stackoverflow street credz para editar la pregunta y agregar esto a la lista como # 20, si alguien más pudiera hacerlo, sería genial ;-)

Algo que usan los ofuscadores: puede tener un campo / método / propiedad / evento que todos tengan el mismo nombre.

La herencia de enumeración no es realmente posible:

Puede heredar de una clase Enum. Pero el resultado no se comporta como un Enum en particular. Se comporta ni siquiera como un tipo de valor, sino como una clase ordinaria. Lo del rango es: IsEnum: True, IsValueType: True, IsClass: False

Pero eso no es particularmente útil (a menos que desee confundir a una persona o el tiempo de ejecución en sí).

También puede derivar una clase del delegado System.Multicast en IL, pero no puede hacer esto en C #:

// La siguiente definición de clase es ilegal:

public class YourCustomDelegate: MulticastDelegate {}

También puede definir métodos de nivel de módulo (también conocido como global) en IL, y C #, por el contrario, solo le permite definir métodos siempre que estén asociados a al menos un tipo.