Que pouvez-vous faire dans MSIL que vous ne pouvez pas faire en C # ou VB.NET? [fermé]

Tout le code écrit dans les langages .NET compile vers MSIL, mais y a-t-il des tâches / opérations spécifiques que vous ne pouvez effectuer qu'en utilisant directement MSIL?

Laissez-nous aussi faire les choses plus facilement dans MSIL que C #, VB.NET, F #, j # ou tout autre langage .NET.

Jusqu'à présent, nous avons ceci:

1. Récursivité de la queue
2. Co / Contravariance générique
3. Surcharges qui ne diffèrent que par les types de retour
4. Remplacer les modificateurs d'accès
5. Avoir une classe qui ne peut pas hériter de System.Object
6. Exceptions filtrées (peut être fait dans vb.net)
7. Appel d'une méthode virtuelle du type de classe statique actuel.
8. Obtenez une poignée sur la version encadrée d'un type valeur.
9. Faites un essai / erreur.
10. Utilisation de noms interdits.
11. Définissez vos propres constructeurs sans paramètre pour les types valeur .
12. Définissez des événements avec un raiseélément.
13. Certaines conversions sont autorisées par le CLR mais pas par C #.
14. Créez une main()méthode non comme .entrypoint.
15. travailler directement avec les types natifs intet natifs unsigned int.
16. Jouez avec des pointeurs transitoires
17. emitbyte directive dans MethodBodyItem
18. Lancer et intercepter les types non System.Exception
19. Hériter des énumérations (non vérifiées)
20. Vous pouvez traiter un tableau d'octets comme un tableau (4x plus petit) d'entiers.
21. Vous pouvez avoir un champ / méthode / propriété / événement tous avoir le même nom (non vérifié).
22. Vous pouvez revenir à un bloc try à partir de son propre bloc catch.
23. Vous avez accès au spécificateur d'accès famandassem ( protected internalest fam ou assem)
24. Accès direct à la <Module>classe pour définir des fonctions globales, ou un initialiseur de module.

MSIL autorise les surcharges qui ne diffèrent que par les types de retour en raison de

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

ou

callvirt int32 ...

La plupart des langages .Net, y compris C # et VB, n'utilisent pas la fonctionnalité de récursivité de queue du code MSIL.

La récursivité de la queue est une optimisation courante dans les langages fonctionnels. Cela se produit lorsqu'une méthode A se termine par renvoyer la valeur de la méthode B de sorte que la pile de la méthode A puisse être désallouée une fois l'appel à la méthode B effectué.

Le code MSIL prend en charge explicitement la récursivité de queue, et pour certains algorithmes, cela pourrait être une optimisation importante à faire. Mais comme C # et VB ne génèrent pas les instructions pour ce faire, cela doit être fait manuellement (ou en utilisant F # ou un autre langage).

Voici un exemple de la façon dont la récursivité de queue peut être implémentée manuellement 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;
    }
}

Il est courant de supprimer la récursivité en déplaçant les données locales de la pile matérielle vers une structure de données de pile allouée au tas. Dans l'élimination de la récursivité des appels de queue comme indiqué ci-dessus, la pile est complètement éliminée, ce qui est une très bonne optimisation. De plus, la valeur de retour n'a pas à remonter une longue chaîne d'appels, mais elle est renvoyée directement.

Mais, de toute façon, le CIL fournit cette fonctionnalité dans le cadre du langage, mais avec C # ou VB, il doit être implémenté manuellement. (La gigue est également libre de faire cette optimisation elle-même, mais c'est un tout autre problème.)

Dans MSIL, vous pouvez avoir une classe qui ne peut pas hériter de System.Object.

Exemple de code: compilez-le avec ilasm.exe MISE À JOUR: Vous devez utiliser "/ NOAUTOINHERIT" pour empêcher l'assembleur d'hériter automatiquement.

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

Il est possible de combiner les modificateurs d'accès protectedet internal. En C #, si vous écrivez protected internalun membre est accessible à partir de l'assembly et des classes dérivées. Via MSIL, vous pouvez obtenir un membre accessible uniquement à partir des classes dérivées de l'assembly . (Je pense que cela pourrait être très utile!)

Ooh, je n'ai pas remarqué ça à l'époque. (Si vous ajoutez la balise jon-skeet, c'est plus probable, mais je ne la vérifie pas souvent.)

Il semble que vous ayez déjà de très bonnes réponses. En outre:

• Vous ne pouvez pas obtenir une poignée sur la version encadrée d'un type valeur en C #. Vous pouvez en C ++ / CLI
• Vous ne pouvez pas faire un essai / défaut en C # ("fault" est comme un "attraper tout et relancer à la fin du bloc" ou "enfin mais seulement en cas d'échec")
• Il y a beaucoup de noms qui sont interdits par C # mais IL légal
• IL vous permet de définir vos propres constructeurs sans paramètre pour les types valeur .
• Vous ne pouvez pas définir d'événements avec un élément "rise" en C #. (Dans VB, vous devez le faire pour les événements personnalisés, mais les événements "par défaut" n'en incluent pas.)
• Certaines conversions sont autorisées par le CLR mais pas par C #. Si vous passez objecten C #, cela fonctionnera parfois. Voir une question SO uint [] / int [] pour un exemple.

J'ajouterai à cela si je pense à autre chose ...

Le CLR prend déjà en charge la co / contravariance générique, mais C # n'obtient pas cette fonctionnalité avant la version 4.0

• Fonctionnalités C # 4.0
• Co / Contravariance

En IL, vous pouvez lancer et attraper n'importe quel type, pas seulement les types dérivés de System.Exception.

IL fait la distinction entre callet callvirtpour les appels de méthode virtuelle. En utilisant le premier, vous pouvez forcer l'appel d'une méthode virtuelle du type de classe statique actuel au lieu de la fonction virtuelle dans le type de classe dynamique.

C # n'a aucun moyen de faire cela:

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, comme IL, peut émettre des appels non virtuels en utilisant la MyClass.Method()syntaxe. Dans ce qui précède, ce serait MyClass.ToString().

Dans un try / catch, vous pouvez ressaisir le bloc try à partir de son propre bloc catch. Donc, vous pouvez faire ceci:

.try {
    // ...

  MidTry:
    // ...

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

RestOfMethod:
    // ...

AFAIK vous ne pouvez pas faire cela en C # ou VB

Avec IL et VB.NET, vous pouvez ajouter des filtres lors de la capture d'exceptions, mais C # v3 ne prend pas en charge cette fonctionnalité.

Cet exemple VB.NET est tiré de http://blogs.msdn.com/clrteam/archive/2009/02/05/catch-rethrow-and-filters-why-you-should-care.aspx (notez le When ShouldCatch(ex) = Truedans le Clause de capture):

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

Autant que je sache, il n'y a aucun moyen de créer des initialiseurs de module (constructeurs statiques pour un module entier) directement en C #:

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

Native types
Vous pouvez travailler directement avec les types int natif et int natif non signé (en c #, vous ne pouvez travailler que sur un IntPtr qui n'est pas le même.

Transient Pointers
Vous pouvez jouer avec des pointeurs transitoires, qui sont des pointeurs vers des types gérés mais garantis de ne pas bouger en mémoire car ils ne sont pas dans le tas géré. Vous ne savez pas exactement comment vous pourriez l'utiliser utilement sans jouer avec du code non managé, mais il n'est pas exposé aux autres langages directement uniquement via des choses comme stackalloc.

<Module>
vous pouvez jouer avec la classe si vous le souhaitez (vous pouvez le faire par réflexion sans avoir besoin d'IL)

.emitbyte

15.4.1.1 La directive .emitbyte MethodBodyItem :: =… | .emitbyte Int32 Cette directive entraîne l'émission d'une valeur 8 bits non signée directement dans le flux CIL de la méthode, à l'endroit où la directive apparaît. [Remarque: la directive .emitbyte est utilisée pour générer des tests. Il n'est pas nécessaire pour générer des programmes réguliers. note de fin]

.entrypoint
Vous avez un peu plus de flexibilité là-dessus, vous pouvez l'appliquer à des méthodes non appelées Main par exemple.

avoir une lecture de la spécification, je suis sûr que vous en trouverez quelques autres.

Vous pouvez pirater le remplacement de méthode co / contra-variance, ce que C # n'autorise pas (ce n'est PAS la même chose que la variance générique!). J'ai plus d'informations sur la mise en œuvre de ceci ici , et les parties 1 et 2

Je pense que celui que je souhaitais (avec des raisons totalement erronées) était l'héritage dans Enums. Cela ne semble pas difficile à faire dans SMIL (puisque les Enums ne sont que des classes) mais ce n'est pas quelque chose que la syntaxe C # veut que vous fassiez.

En voici encore plus:

1. Vous pouvez avoir des méthodes d'instance supplémentaires dans les délégués.
2. Les délégués peuvent implémenter des interfaces.
3. Vous pouvez avoir des membres statiques dans les délégués et les interfaces.

20) Vous pouvez traiter un tableau d'octets comme un tableau (4x plus petit) d'entiers.

Je l'ai utilisé récemment pour faire une implémentation rapide de XOR, car la fonction CLR xor fonctionne sur ints et j'avais besoin de faire XOR sur un flux d'octets.

Le code résultant s'est avéré être ~ 10x plus rapide que l'équivalent fait en C # (faisant XOR sur chaque octet).

===

Je n'ai pas assez de credz de rue stackoverflow pour modifier la question et l'ajouter à la liste en tant que # 20, si quelqu'un d'autre le pouvait, ce serait bien ;-)

Quelque chose que les obfuscateurs utilisent - vous pouvez avoir un champ / une méthode / une propriété / un événement ayant tous le même nom.

L'héritage enum n'est pas vraiment possible:

Vous pouvez hériter d'une classe Enum. Mais le résultat ne se comporte pas comme un Enum en particulier. Il ne se comporte même pas comme un type valeur, mais comme une classe ordinaire. La chose srange est: IsEnum: True, IsValueType: True, IsClass: False

Mais ce n'est pas particulièrement utile (sauf si vous voulez confondre une personne ou le moteur d'exécution lui-même).

Vous pouvez également dériver une classe du délégué System.Multicast en IL, mais vous ne pouvez pas le faire en C #:

// La définition de classe suivante est illégale:

classe publique YourCustomDelegate: MulticastDelegate {}

Vous pouvez également définir des méthodes au niveau du module (aka globales) dans IL, et C #, en revanche, ne vous permet de définir des méthodes que tant qu'elles sont attachées à au moins un type.