Cosa puoi fare in MSIL che non puoi fare in C # o VB.NET? [chiuso]

Tutto il codice scritto nei linguaggi .NET viene compilato in MSIL, ma esistono attività / operazioni specifiche che è possibile eseguire solo utilizzando MSIL direttamente?

Cerchiamo anche di fare le cose più facilmente in MSIL rispetto a C #, VB.NET, F #, j # o qualsiasi altro linguaggio .NET.

Finora abbiamo questo:

1. Ricorsione della coda
2. Co / Contravarianza generica
3. Sovraccarichi che differiscono solo per i tipi di restituzione
4. Sostituisci modificatori di accesso
5. Avere una classe che non può ereditare da System.Object
6. Eccezioni filtrate (può essere fatto in vb.net)
7. Chiamata a un metodo virtuale del tipo di classe statica corrente.
8. Ottieni un handle sulla versione in scatola di un tipo di valore.
9. Fai un tentativo / guasto.
10. Uso di nomi proibiti.
11. Definisci i tuoi costruttori senza parametri per i tipi di valore .
12. Definisci gli eventi con un raiseelemento.
13. Alcune conversioni consentite dal CLR ma non da C #.
14. Crea un main()metodo non come .entrypoint.
15. lavorare direttamente con i tipi nativi inte nativi unsigned int.
16. Gioca con puntatori transitori
17. direttiva emitbyte in MethodBodyItem
18. Lancia e cattura tipi non System.Exception
19. Inherit Enums (Non verificato)
20. È possibile trattare un array di byte come un array (4 volte più piccolo) di ints.
21. Puoi avere un campo / metodo / proprietà / evento tutti con lo stesso nome (Non verificato).
22. È possibile ramificare in un blocco try dal proprio blocco catch.
23. Hai accesso allo specificatore di accesso famandassem ( protected internalè fam o assem)
24. Accesso diretto alla <Module>classe per la definizione di funzioni globali o un inizializzatore del modulo.

MSIL consente sovraccarichi che differiscono solo per i tipi di ritorno a causa di

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

o

callvirt int32 ...

La maggior parte dei linguaggi .Net, tra cui C # e VB, non utilizza la funzione di ricorsione della coda del codice MSIL.

La ricorsione della coda è un'ottimizzazione comune nei linguaggi funzionali. Si verifica quando un metodo A termina restituendo il valore del metodo B in modo tale che lo stack del metodo A possa essere deallocato una volta effettuata la chiamata al metodo B.

Il codice MSIL supporta esplicitamente la ricorsione della coda e per alcuni algoritmi potrebbe essere un'importante ottimizzazione da realizzare. Ma poiché C # e VB non generano le istruzioni per farlo, deve essere fatto manualmente (o usando F # o qualche altra lingua).

Ecco un esempio di come la ricorsione della coda può essere implementata manualmente in 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;
    }
}

È pratica comune rimuovere la ricorsione spostando i dati locali dallo stack hardware su una struttura di dati dello stack allocata in heap. Nell'eliminazione della ricorsione in coda come mostrato sopra, lo stack viene eliminato completamente, il che è una buona ottimizzazione. Inoltre, il valore restituito non deve superare una lunga catena di chiamate, ma viene restituito direttamente.

Tuttavia, CIL fornisce questa funzionalità come parte del linguaggio, ma con C # o VB deve essere implementata manualmente. (Il jitter è anche libero di effettuare questa ottimizzazione da solo, ma questo è un altro problema.)

In MSIL, puoi avere una classe che non può ereditare da System.Object.

Codice di esempio: compilarlo con ilasm.exe AGGIORNAMENTO: È necessario utilizzare "/ NOAUTOINHERIT" per impedire che l'assemblatore erediti automaticamente.

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

È possibile combinare i modificatori protectede internalaccedere. In C #, se si scrive protected internalun membro è accessibile dall'assembly e dalle classi derivate. Via MSIL è possibile ottenere un membro che è accessibile da classi derivate all'interno del gruppo unico . (Penso che potrebbe essere abbastanza utile!)

Ooh, non l'ho notato al momento. (Se aggiungi il tag jon-skeet è più probabile, ma non lo controllo così spesso.)

Sembra che tu abbia già abbastanza buone risposte. Inoltre:

• Non è possibile ottenere un handle sulla versione in box di un tipo di valore in C #. È possibile in C ++ / CLI
• Non puoi fare un tentativo / errore in C # ("errore" è come un "prendi tutto e ripeti alla fine del blocco" o "finalmente ma solo in caso di fallimento")
• Ci sono molti nomi proibiti da C # ma IL legale
• IL consente di definire i propri costruttori senza parametri per i tipi di valore .
• Non è possibile definire eventi con un elemento "raise" in C #. (In VB si dispone per eventi personalizzati, ma gli eventi "predefiniti" non ne includono uno.)
• Alcune conversioni sono consentite dal CLR ma non da C #. Se vai objectin C #, a volte funzioneranno. Vedi una domanda SO uint [] / int [] per un esempio.

Aggiungerò a questo se penso ad altro ...

Il CLR supporta già la co / contravarianza generica, ma C # non ottiene questa funzionalità fino alla 4.0

• Funzionalità di C # 4.0
• Co / controvarianza

In IL puoi lanciare e catturare qualsiasi tipo, non solo i tipi derivati System.Exception.

IL ha la distinzione tra calle callvirtper chiamate di metodo virtuali. Utilizzando il primo è possibile forzare la chiamata di un metodo virtuale del tipo di classe statica corrente anziché della funzione virtuale nel tipo di classe dinamica.

C # non ha modo di farlo:

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, come IL, può effettuare chiamate non virtuali utilizzando la MyClass.Method()sintassi. In quanto sopra, questo sarebbe MyClass.ToString().

In un tentativo / cattura, è possibile immettere nuovamente il blocco try dal proprio blocco catch. Quindi, puoi farlo:

.try {
    // ...

  MidTry:
    // ...

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

RestOfMethod:
    // ...

AFAIK non puoi farlo in C # o VB

Con IL e VB.NET è possibile aggiungere filtri quando si rilevano eccezioni, ma C # v3 non supporta questa funzione.

Questo esempio di VB.NET è tratto da http://blogs.msdn.com/clrteam/archive/2009/02/05/catch-rethrow-and-filters-why-you-should-care.aspx (nota When ShouldCatch(ex) = Truenella Clausola di cattura):

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

Per quanto ne so, non c'è modo di creare inizializzatori di moduli (costruttori statici per un intero modulo) direttamente in C #:

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

Native types
Puoi lavorare direttamente con i tipi int nativi e int intatti senza segno (in c # puoi lavorare solo su un IntPtr che non è lo stesso.

Transient Pointers
È possibile giocare con puntatori temporanei, che sono puntatori a tipi gestiti ma che non possono spostarsi in memoria poiché non si trovano nell'heap gestito. Non sono del tutto sicuro di come si possa utilmente usare questo senza fare confusione con codice non gestito, ma non è esposto alle altre lingue direttamente solo attraverso cose come stackalloc.

<Module>
puoi fare casino con la classe se lo desideri (puoi farlo riflettendo senza bisogno di IL)

.emitbyte

15.4.1.1 La direttiva .emitbyte MethodBodyItem :: =… | .emitbyte Int32 Questa direttiva provoca l'emissione di un valore senza segno a 8 bit direttamente nel flusso CIL del metodo, nel punto in cui appare la direttiva. [Nota: la direttiva .emitbyte viene utilizzata per generare test. Non è necessario per generare programmi regolari. nota finale]

.entrypoint
Hai un po 'più di flessibilità su questo, puoi applicarlo a metodi non chiamati Main per esempio.

leggi le specifiche Sono sicuro che ne troverai altre.

Puoi hackerare il metodo ignorando la co / contro-varianza, cosa che C # non consente (questo NON è lo stesso della varianza generica!). Ho maggiori informazioni sull'implementazione qui e parti 1 e 2

Penso che quello che continuavo a desiderare (con ragioni completamente sbagliate) fosse l'eredità in Enums. Non sembra una cosa difficile da fare in SMIL (dato che gli Enum sono solo classi) ma non è qualcosa che la sintassi di C # vuole che tu faccia.

Eccone alcuni di più:

1. È possibile disporre di metodi di istanza aggiuntivi nei delegati.
2. I delegati possono implementare interfacce.
3. È possibile avere membri statici in delegati e interfacce.

20) È possibile trattare un array di byte come un array (4x più piccolo) di ints.

L'ho usato di recente per eseguire un'implementazione XOR rapida, poiché la funzione xor CLR opera su ints e avevo bisogno di eseguire XOR su un flusso di byte.

Il codice risultante misurato è ~ 10 volte più veloce dell'equivalente fatto in C # (facendo XOR su ogni byte).

===

Non ho abbastanza credz di stackoverflow street per modificare la domanda e aggiungerla all'elenco come # 20, se qualcun altro potesse farlo sarebbe gonfio ;-)

Qualcosa che gli offuscatori usano - puoi avere un campo / metodo / proprietà / evento tutti hanno lo stesso nome.

L'eredità Enum non è davvero possibile:

È possibile ereditare da una classe Enum. Ma il risultato non si comporta come un Enum in particolare. Non si comporta nemmeno come un tipo di valore, ma come una normale classe. La cosa srange è: IsEnum: True, IsValueType: True, IsClass: False

Ma questo non è particolarmente utile (a meno che tu non voglia confondere una persona o l'autonomia stessa).

Puoi anche derivare una classe dal delegato System.Multicast in IL, ma non puoi farlo in C #:

// La seguente definizione di classe è illegale:

public class YourCustomDelegate: MulticastDelegate {}

Puoi anche definire metodi a livello di modulo (aka globali) in IL e C #, al contrario, ti consente di definire metodi solo se sono collegati ad almeno un tipo.