Was können Sie in MSIL tun, was Sie in C # oder VB.NET nicht tun können? [geschlossen]

Der gesamte in .NET-Sprachen geschriebene Code wird in MSIL kompiliert. Gibt es jedoch bestimmte Aufgaben / Vorgänge, die Sie nur direkt mit MSIL ausführen können?

Lassen Sie uns auch in MSIL einfacher arbeiten als in C #, VB.NET, F #, j # oder einer anderen .NET-Sprache.

Bisher haben wir Folgendes:

1. Schwanzrekursion
2. Generische Co / Contravariance
3. Überladungen, die sich nur in Rückgabetypen unterscheiden
4. Zugriffsmodifikatoren überschreiben
5. Haben Sie eine Klasse, die nicht von System.Object erben kann
6. Gefilterte Ausnahmen (können in vb.net durchgeführt werden)
7. Aufruf einer virtuellen Methode des aktuellen statischen Klassentyps.
8. Holen Sie sich einen Überblick über die Box-Version eines Werttyps.
9. Mach einen Versuch / Fehler.
10. Verwendung verbotener Namen.
11. Definieren Sie Ihre eigenen parameterlosen Konstruktoren für Werttypen .
12. Definieren Sie Ereignisse mit einem raiseElement.
13. Einige Konvertierungen sind von der CLR zulässig, jedoch nicht von C #.
14. Machen Sie eine Nicht- main()Methode als .entrypoint.
15. Arbeiten Sie direkt mit den nativen intund nativen unsigned intTypen.
16. Spielen Sie mit vorübergehenden Zeigern
17. Emitbyte-Direktive in MethodBodyItem
18. Nicht System.Exception-Typen werfen und abfangen
19. Enumit Enums (Unverified)
20. Sie können ein Array von Bytes als (4x kleineres) Array von Ints behandeln.
21. Sie können ein Feld / eine Methode / eine Eigenschaft / ein Ereignis haben, die alle denselben Namen haben (nicht überprüft).
22. Sie können von einem eigenen catch-Block zurück in einen try-Block verzweigen.
23. Sie haben Zugriff auf den Famandassem-Zugriffsspezifizierer ( protected internalist Fam oder Assem).
24. Direkter Zugriff auf die <Module>Klasse zum Definieren globaler Funktionen oder einen Modulinitialisierer.

MSIL ermöglicht Überladungen, die sich aufgrund nur in Rückgabetypen unterscheiden

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

oder

callvirt int32 ...

Die meisten .NET-Sprachen, einschließlich C # und VB, verwenden die Funktion zur Endrekursion von MSIL-Code nicht.

Die Schwanzrekursion ist eine Optimierung, die in funktionalen Sprachen üblich ist. Es tritt auf, wenn eine Methode A endet, indem der Wert von Methode B zurückgegeben wird, sodass der Stapel von Methode A freigegeben werden kann, sobald der Aufruf von Methode B erfolgt ist.

MSIL-Code unterstützt die Schwanzrekursion explizit, und für einige Algorithmen könnte dies eine wichtige Optimierung sein. Da C # und VB die entsprechenden Anweisungen nicht generieren, muss dies manuell erfolgen (oder mit F # oder einer anderen Sprache).

Hier ist ein Beispiel dafür, wie die Schwanzrekursion manuell in C # implementiert werden kann:

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 ist üblich, die Rekursion zu entfernen, indem die lokalen Daten vom Hardwarestapel auf eine vom Heap zugewiesene Stapeldatenstruktur verschoben werden. Bei der oben gezeigten Eliminierung der Tail-Call-Rekursion wird der Stapel vollständig eliminiert, was eine ziemlich gute Optimierung darstellt. Außerdem muss der Rückgabewert keine lange Aufrufkette durchlaufen, sondern wird direkt zurückgegeben.

Trotzdem bietet die CIL diese Funktion als Teil der Sprache an, aber mit C # oder VB muss sie manuell implementiert werden. (Der Jitter kann diese Optimierung auch selbst vornehmen, aber das ist ein ganz anderes Problem.)

In MSIL können Sie eine Klasse haben, die nicht von System.Object erben kann.

Beispielcode: Kompilieren Sie ihn mit ilasm.exe. UPDATE: Sie müssen "/ NOAUTOINHERIT" verwenden, um zu verhindern, dass Assembler automatisch erben.

// 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 ist möglich, die Modifikatoren protectedund zu kombinieren internal. Wenn Sie in C # schreiben, kann auf protected internalein Mitglied über die Assembly und über abgeleitete Klassen zugegriffen werden. Via MSIL können Sie ein Mitglied erhalten , die von abgeleiteten Klassen innerhalb der Baugruppe zugänglich ist nur . (Ich denke, das könnte ziemlich nützlich sein!)

Oh, ich habe das damals nicht bemerkt. (Wenn Sie das Jon-Skeet-Tag hinzufügen, ist es wahrscheinlicher, aber ich überprüfe es nicht so oft.)

Es sieht so aus, als hätten Sie bereits ziemlich gute Antworten. Zusätzlich:

• Sie können die Box-Version eines Werttyps in C # nicht in den Griff bekommen. Sie können in C ++ / CLI
• Sie können in C # keinen Versuch / Fehler machen ("Fehler" ist wie "Alles fangen und am Ende des Blocks neu werfen" oder "Endlich, aber nur bei Fehler").
• Es gibt viele Namen, die von C # verboten sind, aber legal IL
• Mit IL können Sie Ihre eigenen parameterlosen Konstruktoren für Werttypen definieren .
• Sie können keine Ereignisse mit einem "Raise" -Element in C # definieren. (In VB Sie haben zu für benutzerdefinierte Ereignisse, aber „default“ Ereignisse umfassen nicht ein.)
• Einige Konvertierungen sind von der CLR zulässig, nicht jedoch von C #. Wenn Sie objectin C # übergehen, funktionieren diese manchmal. Ein Beispiel finden Sie in einer uint [] / int [] SO-Frage .

Ich werde das ergänzen, wenn mir noch etwas einfällt ...

Die CLR unterstützt bereits generische Co / Contravarianz, aber C # erhält diese Funktion erst ab 4.0

• C # 4.0-Funktionen
• Co / Contravariance

In IL können Sie jeden Typ werfen und fangen, nicht nur Typen, von denen abgeleitet wurde System.Exception.

IL unterscheidet zwischen callund callvirtfür virtuelle Methodenaufrufe. Mit der ersteren können Sie den Aufruf einer virtuellen Methode des aktuellen statischen Klassentyps anstelle der virtuellen Funktion im dynamischen Klassentyp erzwingen .

C # hat keine Möglichkeit dazu:

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 kann wie IL mithilfe der MyClass.Method()Syntax nicht- virtuelle Aufrufe ausgeben . Oben wäre dies MyClass.ToString().

In einem try / catch können Sie den try-Block von seinem eigenen catch-Block aus erneut eingeben. Sie können dies also tun:

.try {
    // ...

  MidTry:
    // ...

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

RestOfMethod:
    // ...

AFAIK Sie können dies nicht in C # oder VB tun

Mit IL und VB.NET können Sie Filter hinzufügen, wenn Ausnahmen abgefangen werden, aber C # v3 unterstützt diese Funktion nicht.

Dieses VB.NET-Beispiel stammt von http://blogs.msdn.com/clrteam/archive/2009/02/05/catch-rethrow-and-filters-why-you-should-care.aspx (beachten Sie das When ShouldCatch(ex) = Truein der Fangklausel):

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

Soweit ich weiß, gibt es keine Möglichkeit, Modulinitialisierer (statische Konstruktoren für ein gesamtes Modul) direkt in C # zu erstellen:

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

Native types
Sie können direkt mit den Typen int und native int ohne Vorzeichen arbeiten (in c # können Sie nur mit einem IntPtr arbeiten, der nicht identisch ist.

Transient Pointers
Sie können mit vorübergehenden Zeigern spielen, bei denen es sich um Zeiger auf verwaltete Typen handelt, die sich jedoch garantiert nicht im Speicher bewegen, da sie sich nicht im verwalteten Heap befinden. Ich bin mir nicht ganz sicher, wie Sie dies sinnvoll nutzen können, ohne mit nicht verwaltetem Code herumzuspielen, aber es ist nicht direkt durch Dinge wie stackalloc den anderen Sprachen ausgesetzt.

<Module>
Sie können mit der Klasse herumspielen, wenn Sie dies wünschen (Sie können dies durch Nachdenken tun, ohne IL zu benötigen).

.emitbyte

15.4.1.1 Die .emitbyte-Direktive MethodBodyItem :: =… | .emitbyte Int32 Diese Anweisung bewirkt, dass ein vorzeichenloser 8-Bit-Wert an der Stelle, an der die Anweisung angezeigt wird, direkt in den CIL-Stream der Methode ausgegeben wird. [Hinweis: Die .emitbyte-Direktive wird zum Generieren von Tests verwendet. Es ist nicht erforderlich, um reguläre Programme zu generieren. Endnote]

.entrypoint
Sie haben etwas mehr Flexibilität, Sie können es beispielsweise auf Methoden anwenden, die nicht Main heißen.

Lesen Sie die Spezifikation. Ich bin sicher, Sie werden noch ein paar mehr finden.

Sie können die Co / Contra-Varianz von Hack-Methoden überschreiben, was C # nicht zulässt (dies ist NICHT dasselbe wie generische Varianz!). Ich habe hier und in Teil 1 und 2 weitere Informationen zur Implementierung

Ich denke, derjenige, den ich mir immer wieder gewünscht habe (aus völlig falschen Gründen), war die Vererbung in Enums. In SMIL scheint es nicht schwierig zu sein (da Enums nur Klassen sind), aber die C # -Syntax verlangt nicht, dass Sie dies tun.

Hier noch etwas mehr:

1. Sie können zusätzliche Instanzmethoden in Delegaten haben.
2. Delegierte können Schnittstellen implementieren.
3. Sie können statische Mitglieder in Delegaten und Schnittstellen haben.

20) Sie können ein Array von Bytes als (4x kleineres) Array von Ints behandeln.

Ich habe dies kürzlich verwendet, um eine schnelle XOR-Implementierung durchzuführen, da die CLR-xor-Funktion mit Ints arbeitet und ich XOR für einen Bytestream ausführen musste.

Der resultierende Code ist ~ 10x schneller als der in C # durchgeführte Wert (XOR für jedes Byte).

===

Ich habe nicht genug Stackoverflow Street Credz, um die Frage zu bearbeiten und diese als # 20 zur Liste hinzuzufügen, wenn jemand anderes könnte, wäre das gut ;-)

Etwas, das Verschleierer verwenden - Sie können ein Feld / eine Methode / eine Eigenschaft / ein Ereignis haben, die alle denselben Namen haben.

Enum-Vererbung ist nicht wirklich möglich:

Sie können von einer Enum-Klasse erben. Das Ergebnis verhält sich jedoch nicht wie eine Aufzählung. Es verhält sich nicht einmal wie ein Werttyp, sondern wie eine gewöhnliche Klasse. Die seltsame Sache ist: IsEnum: True, IsValueType: True, IsClass: False

Dies ist jedoch nicht besonders nützlich (es sei denn, Sie möchten eine Person oder die Laufzeit selbst verwirren.)

Sie können eine Klasse auch vom System.Multicast-Delegaten in IL ableiten, dies ist jedoch in C # nicht möglich:

// Die folgende Klassendefinition ist unzulässig:

öffentliche Klasse YourCustomDelegate: MulticastDelegate {}

Sie können in IL auch Methoden auf Modulebene (auch als globale Methoden bezeichnet) definieren, und in C # können Sie dagegen nur Methoden definieren, solange sie an mindestens einen Typ angehängt sind.