/clr Einschränkungen

  • Artikel

Beachten Sie die folgenden Einschränkungen bei der Verwendung von /clr:

  • In einem strukturierten Ausnahmehandler gibt es Einschränkungen bei der Verwendung _alloca beim Kompilieren mit /clr. Weitere Informationen finden Sie unter _alloca.

  • Die Verwendung von Laufzeitfehlerprüfungen ist ungültig mit /clr. Weitere Informationen finden Sie unter How to: Use native run-time checks.

  • Wenn /clr sie zum Kompilieren eines Programms verwendet wird, das nur die C++-Standardsyntax verwendet, gelten die folgenden Richtlinien für die Verwendung von Inlineassembly:

    • Bei Inlineassemblycode, der Kenntnis des nativen Stapellayouts unterstellt, Aufrufkonventionen außerhalb der aktuellen Funktion oder anderen spezifischen Informationen über den Computer kann es zu einem Fehler kommen, wenn diese Kenntnis auf den Stapelrahmen für eine verwaltete Funktion angewendet wird. Funktionen, die Inlineassemblycode enthalten, werden als nicht verwaltete Funktionen generiert, als ob sie in einem separaten Modul platziert wurden, das ohne /clrkompiliert wurde.

    • Inlineassemblycode in Funktionen, die kopierte Funktionsparameter übergeben, werden nicht unterstützt.

  • Die vprintf Funktionen können nicht aus einem Programm aufgerufen werden, das mit /clrkompiliert wurde.

  • Der naked__declspec Modifizierer wird unter /clrignoriert.

  • Die festgelegte _set_se_translator Übersetzerfunktion wirkt sich nur auf Fänge im nicht verwalteten Code aus. Weitere Informationen finden Sie unter "Ausnahmebehandlung".

  • Der Vergleich von Funktionszeigern ist nicht zulässig unter /clr.

  • Die Verwendung von Funktionen, die nicht vollständig prototypisch sind, ist nicht zulässig /clr.

  • Die folgenden Compileroptionen werden von /clr:

  • Die Kombination der _STATIC_CPPLIB Präprozessordefinition (/D_STATIC_CPPLIB) und der /clr Compileroption wird nicht unterstützt. Dies liegt daran, dass die Definition dazu führen würde, dass Ihre Anwendung mit der statischen, multithreadierten C++-Standardbibliothek verknüpft wird, die nicht unterstützt wird. Weitere Informationen finden Sie unter /MD, , /MT( /LD Laufzeitbibliothek verwenden).

  • Wenn Sie mit /clrdieser Anwendung arbeiten/Zi, gibt es Leistungsauswirkungen. Weitere Informationen finden Sie unter /Zi.

  • Durch das Übergeben eines breiten Zeichens an eine .NET Framework-Ausgaberoutine ohne Angabe /Zc:wchar_t oder Ohne Umwandlung des Zeichens _wchar_t wird die Ausgabe als ein unsigned short int. Beispiel:

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

  • /GS wird beim Kompilieren mit /clr, es sei denn, eine Funktion ist unter #pragma unmanaged oder wenn die Funktion als systemeigener Code kompiliert werden muss, in diesem Fall generiert der Compiler warnung C4793, die standardmäßig deaktiviert ist.

  • Informationen zu den Anforderungen an die Funktionssignatur einer verwalteten Anwendung finden Sie unter.See /ENTRY for function signature requirements of a managed application.

  • Anwendungen, die kompiliert wurden /openmp und /clr nur in einem einzigen Appdo Standard prozess ausgeführt werden können. Weitere Informationen finden Sie unter (Aktivieren des OpenMP 2.0-Supports).For more information, see /openmp (Enable OpenMP 2.0 Support).

  • Funktionen, die eine variable Anzahl von Argumenten (Varargs) akzeptieren, werden als native Funktionen generiert. Alle verwalteten Datentypen an der variablen Argumentposition werden in native Typen gemarshallt. Alle System.String Typen sind tatsächlich Zeichenfolgen mit breitem Zeichen, werden jedoch in Einzelne-Byte-Zeichenzeichenfolgen gemarstet. Wenn ein printf Bezeichner also (wchar_t*) lautet %S , wird er stattdessen zu einer %s Zeichenfolge gemarsiert.

  • Wenn Sie das va_arg Makro verwenden, erhalten Sie möglicherweise unerwartete Ergebnisse beim Kompilieren mit /clr:pure. Weitere Informationen finden Sie unter va_arg, , va_copy, . va_startva_end Die /clr:pure Optionen und /clr:safe Compileroptionen sind in Visual Studio 2015 veraltet und werden in Visual Studio 2017 und höher nicht unterstützt. Code, der "pure" oder "safe" sein muss, sollte nach C# portiert werden.

  • Sie sollten keine Funktionen aufrufen, die den Stapel durchlaufen, um Parameterinformationen (Funktionsargumente) aus verwaltetem Code abzurufen. Die P/Invoke-Ebene bewirkt, dass die Informationen weiter unten im Stapel angezeigt werden. Kompilieren Sie z. B. keinen Proxy/Stub mit /clr.

  • Funktionen werden wann immer möglich in verwalteten Code kompiliert, aber nicht alle C++-Konstrukte können in verwalteten Code übersetzt werden. Diese Bestimmung erfolgt Funktion für Funktion. Wenn ein Teil einer Funktion nicht in verwalteten Code konvertiert werden kann, wird stattdessen die gesamte Funktion in systemeigenen Code konvertiert. Die folgenden Fälle hindern den Compiler an der Generierung von verwaltetem Code.

    • Vom Compiler generierte Thunks oder Hilfsfunktionen. Für alle Funktionsaufrufe mithilfe eines Funktionszeigers, einschließlich virtueller Funktionsaufrufe, werden native Thunks generiert.

    • Funktionen, die setjmp oder longjmp aufrufen.

    • Funktionen, die bestimmte intrinsische Routinen verwenden, um Computerressourcen direkt zu bearbeiten. Beispielsweise führen die Verwendung von __enable und __disable, _ReturnAddress und _AddressOfReturnAddress oder von Multimedia-Intrinsics alle zu nativem Code.

    • Funktionen, die auf die Anweisung #pragma unmanaged folgen. (Umgekehrt, #pragma managedwird ebenfalls unterstützt.)

    • Eine Funktion, die Verweise auf ausgerichtete Typen enthält, d.h. Typen, die mithilfe von __declspec(align(...)) deklariert wurden.

Siehe auch