OpCodes.Call Champ

Définition

Espace de noms:

System.Reflection.Emit

Assembly:

System.Reflection.Primitives.dll

Source:

OpCodes.cs

Appelle la méthode indiquée par le descripteur de méthode passé.

public: static initonly System::Reflection::Emit::OpCode Call;

public static readonly System.Reflection.Emit.OpCode Call;

 staticval mutable Call : System.Reflection.Emit.OpCode

Public Shared ReadOnly Call As OpCode 

Valeur de champ

OpCode

Remarques

Le tableau suivant répertorie le format d’assembly MSIL et hexadécimal de l’instruction, ainsi qu’un bref résumé des références :

Format	Format d’assembly	Description
28 <T>	appeler le methodDesc	Appelez la méthode décrite par methodDesc.

Le comportement transitoire de la pile, dans l’ordre séquentiel, est le suivant :

1. Les arguments de arg1 méthode sont argN envoyés à la pile.

2. Les arguments de méthode sont argN extraits arg1 de la pile ; l’appel de méthode est effectué avec ces arguments et le contrôle est transféré vers la méthode référencée par le descripteur de méthode. Une fois l’opération terminée, une valeur de retour est générée par la méthode appelée et envoyée à l’appelant.

3. La valeur de retour est poussée vers la pile.

L’instruction call appelle la méthode indiquée par le descripteur de méthode passé avec l’instruction. Le descripteur de méthode est un jeton de métadonnées qui indique la méthode à appeler et le nombre, le type et l’ordre des arguments qui ont été placés sur la pile à passer à cette méthode, ainsi que la convention d’appel à utiliser. L’instruction call peut être immédiatement précédée d’une tail instruction de préfixe (Tailcall) pour spécifier que l’état actuel de la méthode doit être libéré avant le transfert du contrôle. Si l’appel transfère le contrôle vers une méthode d’approbation supérieure à la méthode d’origine, la trame de pile n’est pas libérée. Au lieu de cela, l’exécution se poursuit silencieusement comme si le n’avait tail pas été fourni. Le jeton de métadonnées contient suffisamment d’informations pour déterminer si l’appel concerne une méthode statique, une méthode instance, une méthode virtuelle ou une fonction globale. Dans tous ces cas, l’adresse de destination est entièrement déterminée à partir du descripteur de méthode (contrastez avec l’instruction Callvirt d’appel de méthodes virtuelles, où l’adresse de destination dépend également du type d’exécution de la référence instance envoyée avant le Callvirt).

Les arguments sont placés sur la pile dans l’ordre de gauche à droite. Autrement dit, le premier argument est calculé et placé sur la pile, puis le deuxième argument, puis le troisième, jusqu’à ce que tous les arguments nécessaires soient au sommet de la pile dans l’ordre décroissant. Il existe trois cas particuliers importants :

1. Les appels à une méthode instance (ou virtuelle) doivent envoyer cette instance référence avant l’un des arguments visibles par l’utilisateur. La référence instance ne doit pas être une référence null. La signature portée dans les métadonnées ne contient pas d’entrée dans la liste de paramètres du this pointeur ; au lieu de cela, elle utilise un bit pour indiquer si la méthode nécessite le passage du this pointeur.

2. Il est valide d’appeler une méthode virtuelle à l’aide call de (plutôt que callvirt) cela indique que la méthode doit être résolue à l’aide de la classe spécifiée par la méthode plutôt que comme spécifié dynamiquement à partir de l’objet appelé.

3. Notez que la méthode d’un Invoke délégué peut être appelée avec l’instruction call ou callvirt .

SecurityException peut être levée si la sécurité système n’accorde pas à l’appelant l’accès à la méthode appelée. Le case activée de sécurité peut se produire lorsque les instructions MSIL (Microsoft Intermediate Language) sont converties en code natif plutôt qu’au moment de l’exécution.

Notes

Lorsque vous appelez des méthodes de System.Object sur des types valeur, envisagez d’utiliser le constrained préfixe avec l’instruction callvirt au lieu d’émettre une call instruction. Cela supprime la nécessité d’émettre un il différent selon que le type de valeur remplace ou non la méthode, ce qui évite un problème potentiel de contrôle de version. Envisagez d’utiliser le constrained préfixe lors de l’appel de méthodes d’interface sur des types valeur, car la méthode de type valeur implémentant la méthode d’interface peut être modifiée à l’aide d’un MethodImpl. Ces problèmes sont décrits plus en détail dans l’opcode Constrained .

Les surcharges de méthode suivantes Emit peuvent utiliser l’opcode call :

• ILGenerator.Emit(OpCode, MethodInfo)

• ILGenerator.EmitCall(OpCode, MethodInfo, Type[])

• ILGenerator.Emit(OpCode, ConstructorInfo)

Notes

La EmitCall méthode est fournie pour les varargs appels. Utilisez la méthode pour les Emit appels normaux.