O que você pode fazer no MSIL e não no C # ou no VB.NET? [fechadas]

Todo o código escrito nas linguagens .NET é compilado para o MSIL, mas existem tarefas / operações específicas que você só pode fazer usando o MSIL diretamente?

Vamos também fazer coisas mais fáceis no MSIL do que C #, VB.NET, F #, j # ou qualquer outra linguagem .NET.

Até agora, temos o seguinte:

1. Recursão da cauda
2. Co / Contravariância Genérica
3. Sobrecargas que diferem apenas nos tipos de retorno
4. Substituir modificadores de acesso
5. Tem uma classe que não pode herdar do System.Object
6. Exceções filtradas (podem ser feitas em vb.net)
7. Chamando um método virtual do tipo de classe estática atual.
8. Identifique a versão em caixa de um tipo de valor.
9. Faça uma tentativa / falha.
10. Uso de nomes proibidos.
11. Defina seus próprios construtores sem parâmetros para tipos de valor .
12. Defina eventos com um raiseelemento.
13. Algumas conversões permitidas pelo CLR, mas não pelo C #.
14. Faça um main()método não como o .entrypoint.
15. trabalhe diretamente com os tipos intnativo e nativo unsigned int.
16. Brincar com ponteiros transitórios
17. diretiva emitbyte em MethodBodyItem
18. Lançar e capturar tipos não System.Exception
19. Herdar enums (não verificado)
20. Você pode tratar uma matriz de bytes como uma matriz de ints (4x menor).
21. Você pode ter um campo / método / propriedade / evento com o mesmo nome (Não verificado).
22. Você pode ramificar novamente em um bloco try a partir de seu próprio bloco catch.
23. Você tem acesso ao especificador de acesso famandassem ( protected internalé fam ou assem)
24. Acesso direto à <Module>classe para definir funções globais ou um inicializador de módulo.

O MSIL permite sobrecargas que diferem apenas nos tipos de retorno devido a

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

ou

callvirt int32 ...

A maioria dos idiomas .Net, incluindo C # e VB, não usa o recurso de recursão de cauda do código MSIL.

A recursão da cauda é uma otimização comum em linguagens funcionais. Ocorre quando um método A termina retornando o valor do método B, para que a pilha do método A possa ser desalocada depois que a chamada para o método B é feita.

O código MSIL suporta explicitamente a recursão da cauda e, para alguns algoritmos, isso pode ser uma otimização importante a ser feita. Mas como C # e VB não geram as instruções para fazer isso, isso deve ser feito manualmente (ou usando F # ou algum outro idioma).

Aqui está um exemplo de como a recursão de cauda pode ser implementada manualmente em 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;
    }
}

É prática comum remover a recursão movendo os dados locais da pilha de hardware para uma estrutura de dados da pilha alocada em heap. Na eliminação da recursão de chamada final, como mostrado acima, a pilha é eliminada completamente, o que é uma otimização bastante boa. Além disso, o valor de retorno não precisa subir uma longa cadeia de chamadas, mas é retornado diretamente.

Mas, de qualquer maneira, o CIL fornece esse recurso como parte do idioma, mas com C # ou VB ele precisa ser implementado manualmente. (O tremor também é livre para fazer essa otimização por conta própria, mas isso é outra questão.)

No MSIL, você pode ter uma classe que não pode herdar do System.Object.

Código de exemplo: compile-o com ilasm.exe ATUALIZAÇÃO: Você deve usar "/ NOAUTOINHERIT" para impedir a montagem automática da herança.

// 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

É possível combinar os modificadores protectede internalacesso. Em C #, se você escrever, protected internalum membro poderá ser acessado a partir do assembly e de classes derivadas. Via MSIL você pode obter um membro que é acessível a partir de classes derivadas dentro da montagem única . (Eu acho que poderia ser bastante útil!)

Ooh, eu não vi isso na época. (Se você adicionar a tag jon-skeet, é mais provável, mas eu não a checo com tanta frequência.)

Parece que você já tem respostas muito boas. Além do que, além do mais:

• Você não pode controlar a versão em caixa de um tipo de valor em C #. Você pode em C ++ / CLI
• Você não pode fazer uma tentativa / falha em C # ("falha" é como um "pegue tudo e repita no final do bloco" ou "finalmente, mas apenas com falha")
• Existem muitos nomes proibidos por C #, mas a IL legal
• O IL permite definir seus próprios construtores sem parâmetros para tipos de valor .
• Você não pode definir eventos com um elemento "raise" em C #. (No VB você precisa para eventos personalizados, mas os eventos "padrão" não incluem um.)
• Algumas conversões são permitidas pelo CLR, mas não pelo C #. Se você usar o objectC #, isso às vezes funcionará. Veja uma pergunta SO uint [] / int [] SO para obter um exemplo.

Vou acrescentar a isso se pensar em mais alguma coisa ...

O CLR já suporta co / contravariância genérica, mas o C # não está recebendo esse recurso até 4.0

• Recursos do C # 4.0
• Co / Contravariância

Em IL, você pode lançar e capturar qualquer tipo, não apenas os tipos derivados System.Exception.

IL tem a distinção entre calle callvirtpara chamadas de método virtual. Usando o primeiro, você pode forçar a chamada de um método virtual do tipo de classe estática atual em vez da função virtual no tipo de classe dinâmica.

C # não tem como fazer isso:

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!"; }
}

O VB, como o IL, pode emitir chamadas não virtuais usando a MyClass.Method()sintaxe. No exposto, isso seria MyClass.ToString().

Em uma tentativa / captura, você pode inserir novamente o bloco try a partir do seu próprio bloco catch. Então, você pode fazer isso:

.try {
    // ...

  MidTry:
    // ...

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

RestOfMethod:
    // ...

AFAIK, você não pode fazer isso em C # ou VB

Com o IL e o VB.NET, você pode adicionar filtros ao capturar exceções, mas o C # v3 não suporta esse recurso.

Este exemplo do VB.NET é obtido em http://blogs.msdn.com/clrteam/archive/2009/02/05/catch-rethrow-and-filters-why-you-should-care.aspx (observe a When ShouldCatch(ex) = Trueseção Cláusula de captura):

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

Até onde eu sei, não há como criar inicializadores de módulo (construtores estáticos para um módulo inteiro) diretamente em C #:

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

Native types
Você pode trabalhar diretamente com os tipos int nativo e int não assinado nativo (em c #, você só pode trabalhar em um IntPtr que não seja o mesmo.

Transient Pointers
Você pode jogar com ponteiros transitórios, que são ponteiros para tipos gerenciados, mas garantidos para não serem movidos na memória, pois não estão no heap gerenciado. Não tem muita certeza de como você poderia usá-lo de maneira útil sem mexer com código não gerenciado, mas ele não é exposto a outros idiomas diretamente apenas através de coisas como stackalloc.

<Module>
você pode mexer com a classe se assim o desejar (você pode fazer isso refletindo sem precisar de IL)

.emitbyte

15.4.1.1 A diretiva .emitbyte MethodBodyItem :: =… | .emitbyte Int32 Essa diretiva faz com que um valor de 8 bits não assinado seja emitido diretamente no fluxo CIL do método, no ponto em que a diretiva aparece. [Nota: A diretiva .emitbyte é usada para gerar testes. Não é necessário na geração de programas regulares. nota final]

.entrypoint
Você tem um pouco mais de flexibilidade nisso, pode aplicá-lo a métodos não chamados Main, por exemplo.

leia as especificações . Tenho certeza que você encontrará mais algumas.

Você pode hackear a substituição de método co / contra-variação, que o C # não permite (NÃO é o mesmo que variação genérica!). Eu tenho mais informações sobre como implementar isso aqui , e as partes 1 e 2

Eu acho que o que eu continuava desejando (com razões inteiramente erradas) era herança na Enums. Não parece uma coisa difícil de fazer no SMIL (já que Enums são apenas classes), mas não é algo que a sintaxe do C # queira que você faça.

Aqui está um pouco mais:

1. Você pode ter métodos de instância extras em delegados.
2. Delegados podem implementar interfaces.
3. Você pode ter membros estáticos em delegados e interfaces.

20) Você pode tratar uma matriz de bytes como uma matriz (4x menor) de entradas.

Eu usei isso recentemente para fazer uma implementação rápida do XOR, já que a função CLR xor opera em ints e eu precisava fazer o XOR em um fluxo de bytes.

O código resultante medido para ser ~ 10x mais rápido que o equivalente feito em C # (executando XOR em cada byte).

===

Eu não tenho credibilidade de rua de stackoverflow suficiente para editar a pergunta e adicioná-la à lista como # 20, se alguém puder, isso seria inchado ;-)

Algo que os ofuscadores usam - você pode ter um campo / método / propriedade / evento, todos com o mesmo nome.

A herança de enum não é realmente possível:

Você pode herdar de uma classe Enum. Mas o resultado não se comporta como um Enum em particular. Ele se comporta nem mesmo como um tipo de valor, mas como uma classe comum. A coisa mais interessante é: IsEnum: True, IsValueType: True, IsClass: False

Mas isso não é particularmente útil (a menos que você queira confundir uma pessoa ou o próprio tempo de execução.)

Você também pode derivar uma classe do delegado System.Multicast em IL, mas não pode fazer isso em C #:

// A seguinte definição de classe é ilegal:

classe pública YourCustomDelegate: MulticastDelegate {}

Você também pode definir métodos em nível de módulo (também conhecidos como globais) em IL, e o C #, por outro lado, permite definir métodos apenas desde que estejam anexados a pelo menos um tipo.