Partager via

/clr Restrictions

Notez les restrictions suivantes sur l’utilisation de /clr:

  • Dans un gestionnaire d’exceptions structurées, il existe des restrictions sur l’utilisation _alloca lors de la compilation avec /clr. Pour plus d’informations, consultez _alloca.

  • L’utilisation des vérifications d’erreur au moment de l’exécution n’est pas valide avec /clr. Pour plus d’informations, consultez Guide pratique pour utiliser des vérifications d’exécution natives.

  • Lorsqu’il /clr est utilisé pour compiler un programme qui utilise uniquement la syntaxe C++ standard, les instructions suivantes s’appliquent à l’utilisation d’un assembly inline :

    • Le code de l’assembly inline qui suppose des connaissances de la disposition de pile native, des conventions d’appel en dehors de la fonction active ou d’autres informations de bas niveau sur l’ordinateur peut échouer si ces connaissances sont appliquées au frame de pile pour une fonction managée. Les fonctions contenant du code d’assembly inline sont générées en tant que fonctions non managées, comme si elles étaient placées dans un module distinct qui a été compilé sans /clr.

    • Le code d’assembly inline dans les fonctions qui passent les paramètres de fonction construits par copie n’est pas pris en charge.

  • Les vprintf fonctions ne peuvent pas être appelées à partir d’un programme compilé avec /clr.

  • Le naked __declspec modificateur est ignoré sous /clr.

  • La fonction translator définie par _set_se_translator affectera uniquement les captures dans du code non managé. Pour plus d’informations, consultez Gestion des exceptions.

  • La comparaison des pointeurs de fonction n’est pas autorisée sous /clr.

  • L’utilisation de fonctions qui ne sont pas entièrement prototypes n’est pas autorisée sous /clr.

  • Les options de compilateur suivantes ne sont pas prises en charge avec /clr:

  • La combinaison de la _STATIC_CPPLIB définition de préprocesseur (/D_STATIC_CPPLIB) et de l’option /clr du compilateur n’est pas prise en charge. Cela est dû au fait que la définition entraînerait la liaison de votre application avec la bibliothèque standard C++ statique multithread, qui n’est pas prise en charge. Pour plus d’informations, consultez /MD, /MT/LD (Utiliser la bibliothèque d’exécution).

  • Lorsque vous utilisez /Zi /clr, il existe des implications en matière de performances. Pour plus d’informations, consultez /Zi.

  • Le passage d’un caractère large à une routine de sortie .NET Framework sans spécifier /Zc:wchar_t ou sans caster le caractère entraîne _wchar_t l’affichage de la sortie sous la forme d’un unsigned short int. Par exemple :

    Console::WriteLine(L' ')              // Will output 32.
Console::WriteLine((__wchar_t)L' ')   // Will output a space.

  • /GS est ignoré lors de la compilation avec /clr, sauf si une fonction est sous #pragma unmanaged ou si la fonction doit être compilée en tant que code natif, auquel cas le compilateur génère l’avertissement C4793, qui est désactivé par défaut.

  • Consultez /ENTRY les exigences de signature de fonction d’une application managée.

  • Les applications compilées avec /openmp et /clr ne peuvent être exécutées que dans un seul processus appdomain. Pour plus d’informations, consultez /openmp (Activer la prise en charge d’OpenMP 2.0)..

  • Les fonctions qui prennent un nombre variable d’arguments (varargs) seront générées en tant que fonctions natives. Les types de données managés dans la position d’argument de variable seront marshalés en types natifs. Tous les System.String types sont des chaînes à caractères larges, mais ils sont marshalés en chaînes de caractères à un octet. Par conséquent, si un printf spécificateur est %S (wchar_t*), il est marshalé vers une %s chaîne à la place.

  • Lorsque vous utilisez la macro, vous pouvez obtenir des résultats inattendus lors de la va_arg compilation avec /clr:pure. Pour plus d’informations, consultez , , va_endva_copy, va_start.va_arg Les /clr:pure options du compilateur et /clr:safe des options sont déconseillées dans Visual Studio 2015 et non prises en charge dans Visual Studio 2017 et versions ultérieures. Le code qui doit être « pur » ou « sécurisé » doit être porté sur C#.

  • Vous ne devez pas appeler de fonctions qui guident la pile pour obtenir des informations sur les paramètres (arguments de fonction) à partir du code managé. La couche P/Invoke entraîne l’exécution de ces informations plus loin dans la pile. Par exemple, ne compilez pas le proxy/stub avec /clr.

  • Les fonctions seront compilées en code managé chaque fois que possible, mais les constructions C++ ne peuvent pas toutes être traduites en code managé. Cette détermination est effectuée fonction par fonction. Si une partie d’une fonction ne peut pas être convertie en code managé, la fonction entière est convertie en code natif à la place. Les cas suivants empêchent le compilateur de générer du code managé.

    • Fonctions d’assistance ou conversions de code (thunks) générées par le compilateur. Des thunks natifs sont générés pour tout appel de fonction via un pointeur de fonction, notamment les appels de fonction virtuels.

    • Fonctions qui appellent setjmp ou longjmp.

    • Fonctions qui utilisent certaines routines intrinsèques pour manipuler directement des ressources de l’ordinateur. Par exemple, l’utilisation de __enable et __disable, _ReturnAddress et _AddressOfReturnAddress, ou des intrinsèques multimédias aboutissent tous à du code natif.

    • Fonctions qui suivent la directive #pragma unmanaged. (L’inverse, est #pragma managedégalement pris en charge.)

    • Fonction qui contient des références à des types alignés, autrement dit des types déclarés à l’aide de __declspec(align(...)).

Voir aussi

  • Last updated on