OpCodes.Call Champ

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

Remarques

Le tableau suivant répertorie le format d'assembly MSIL (Hexadécimal et Microsoft Intermediate Language) de l'instruction, ainsi qu'un bref résumé de référence :

Le comportement transitionnel de la pile, dans l’ordre séquentiel, est :

1. Les arguments de arg1 méthode sont argN envoyés (push) sur 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é à la méthode référencée par le descripteur de méthode. Une fois 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 envoyée (push) sur 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 précédée immédiatement d’une tail instruction de préfixe (Tailcall) pour spécifier que l’état de la méthode actuelle doit être libéré avant de transférer le contrôle. Si l’appel transfère le contrôle à une méthode de confiance supérieure à la méthode d’origine, le frame de pile n’est pas libéré. Au lieu de cela, l’exécution continue silencieusement comme si celle-ci tail n’avait pas été fournie. Le jeton de métadonnées contient suffisamment d’informations pour déterminer si l’appel concerne une méthode statique, une méthode d’instance, une méthode virtuelle ou une fonction globale. Dans tous ces cas, l’adresse de destination est déterminée entièrement à partir du descripteur de méthode (contrairement à 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 d’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-dessus de la pile dans l’ordre décroissant. Il existe trois cas spéciaux importants :

1. Les appels à une méthode d’instance (ou virtuelle) doivent envoyer (push) cette référence d’instance avant l’un des arguments visibles par l’utilisateur. La référence d’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 des paramètres pour le pointeur ; à la this place, elle utilise un peu pour indiquer si la méthode nécessite de passer le this pointeur.

2. Il est valide d’appeler une méthode virtuelle à l’aide call (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 ou callvirt l’instructioncall.

SecurityException peut être levée si la sécurité système n’accorde pas à l’appelant l’accès à la méthode appelée. La vérification 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.

Les surcharges de méthode suivantes Emit peuvent utiliser le call code opcode :

• ILGenerator.Emit(OpCode, MethodInfo)

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

• ILGenerator.Emit(OpCode, ConstructorInfo)