Einschränkungen für "/clr"
Aktualisiert: November 2007
Beachten Sie die folgenden Einschränkungen der Verwendung von /clr:
In einem strukturierte Ausnahmehandler liegen beim Kompilieren mit /clr Einschränkungen für die Verwendung von _alloca vor. Weitere Informationen finden Sie unter _alloca.
Die Verwendung von Laufzeitüberprüfungen mit /clr ist nicht zulässig. Weitere Informationen finden Sie unter Laufzeitfehlerüberprüfungen.
Wenn /clr zum Kompilieren eines Programms verwendet wird, dass ausschließlich Standard-C++-Syntax verwendet, gelten folgende Richtlinien für die Verwendung der Inlineassembly:
Bei Inlineassemblycode, der von einem bekannten systemeigenen Stapellayout ausgeht und der dazu Konventionen außerhalb der aktuellen Funktion oder andere Informationen über den Computer auf niedriger Ebene abruft, können Fehler auftreten, wenn das Layout für eine verwaltete Funktion auf den Stapelrahmen angewendet wird. Funktionen, die Inlineassemblycode enthalten, werden als unverwaltete Funktionen generiert, so als wären sie in einem separaten Modul abgelegt, das ohne /clr kompiliert wurde.
Inlineassemblycode wird in Funktionen, die kopierkonstruierte Funktionsparameter übergeben, nicht unterstützt.
Die vprintf-Funktionen können nicht aus einem Programm aufgerufen werden, das mit /clr kompiliert wurde.
Der __declspec-Modifizierer mit naked-Attribut wird unter /clr ignoriert.
Die translator-Funktion, die durch _set_se_translator eingestellt wird, wirkt sich nur auf abgefangene Elemente im nicht verwalteten Code aus. Weitere Informationen finden Sie unter Exception Handling under /clr.
Der Vergleich von Funktionszeigern ist unter /clr nicht zulässig.
Der Gebrauch von Funktionen ohne vollständige Prototypen ist unter /clr nicht zulässig.
Die folgenden Compileroptionen werden mit /clr nicht unterstützt:
/EHsc und /EHs (/clr impliziert /EHa, siehe /EH (Ausnahmebehandlungsmodell))
/fp:strict und /fp:except (siehe /fp (Festlegen des Gleitkommaverhaltens))
/ZI
Die Kombination aus der _STATIC_CPPLIB-Präprozessordefinition (/D_STATIC_CPPLIB) und der Compileroption /clr oder /clr:pure wird nicht unterstützt. Der Grund dafür ist, dass die Definition die Anwendung zu einer Verknüpfung mit der statischen Multithread-Standard-C++-Bibliothek veranlassen würde, was nicht unterstützt wird. Weitere Informationen finden Sie unter dem Thema /MD, /MT, /LD (Laufzeitbibliothek verwenden).
/J wird mit /clr:safe oder /clr:pure nicht unterstützt.
In Visual C++ 2005 werden die ATL- und MFC-Bibliotheken von der Kompilierung im pure-Modus (/clr:pure) nicht unterstützt. Sie können /clr:pure mit der Standard-C++-Bibliothek und CRT verwenden, wenn Sie auch mit /MD oder /MDd kompilieren.
Die Verwendung von /Zi mit /clr wirkt sich auf die Leistung aus. Weitere Informationen finden Sie unter /Zi.
Das Übergeben eines Breitzeichens an eine .NET Framework-Ausgaberoutine ohne gleichzeitige Festlegung von /Zc:wchar_t oder ohne Umwandlung des Zeichens in __wchar_t führt zur Darstellung der Ausgabe als 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 ignoriert, wenn keine Funktion unter #pragma unmanaged ist oder die Funktion in systemeigenen Code kompiliert werden muss. In diesem Fall gibt der Compiler die Warnung C4793 aus, die standardmäßig deaktiviert ist.
Informationen über die Anforderungen in Bezug auf Funktionssignaturen einer verwalteten Anwendung finden Sie unter /ENTRY.
Mit /openmp und /clr kompilierte Anwendungen können nur in einem einzelnen appdomain-Prozess ausgeführt werden. Weitere Informationen finden Sie unter /openmp (Aktivieren der OpenMP 2.0-Unterstützung).
Funktionen, die eine variable Anzahl von Argumenten (varargs) aufnehmen, werden als systemeigene Funktionen generiert. Alle verwalteten Datentypen in der variablen Argumentposition werden in systemeigene Typen gemarshallt. Beachten Sie, dass System.String-Typen in Einzelbyte-Zeichenfolgen gemarshallt werden, obwohl es sich dabei tatsächlich um breite Zeichenfolgen handelt. Wenn ein printf-Spezifizierer also %S (wchar_t*) lautet, wird er stattdessen in eine %s-Zeichenfolge gemarshallt.
Wenn Sie das Makro va_arg verwenden, erhalten Sie beim Kompilieren mit /clr:pure möglicherweise unerwartete Ergebnisse. Weitere Informationen finden Sie unter va_arg, va_end, va_start.
Aus verwaltetem Code sollten keine Funktionen aufgerufen werden, die den Stapel durchlaufen, um Parameterinformationen (Funktionsargumente) abzurufen. Die P/Invoke-Ebene bewirkt, dass Informationen sich weiter unten im Stapel befinden. Kompilieren Sie z. B. proxy/stub nicht mit /clr.
Funktionen werden nach Möglichkeit zu verwaltetem Code kompiliert, doch nicht alle C++-Konstrukte können in verwalteten Code übersetzt werden. Dies wird auf Funktionsbasis ermittelt. Wenn ein Teil der Funktion nicht in verwalteten Code konvertiert werden kann, wird die gesamte Funktion stattdessen in systemeigenen Code konvertiert. In den folgenden Fällen wird das Generieren von verwaltetem Code im Compiler verhindert.
Vom Compiler generierte Thunks oder Hilfsfunktionen. Systemeigene Thunks werden für jeden Funktionsaufruf durch einen Funktionszeiger generiert, einschließlich virtueller Funktionsaufrufe.
Funktionen, die setjmp oder longjmp aufrufen.
Funktionen, die bestimmte systeminterne Routinen verwenden, um Computerressourcen direkt zu bearbeiten. Beispielsweise führt die Verwendung von __enable und __disable, _ReturnAddress und _AddressOfReturnAddress oder systeminternen Multimediafunktionen zur Erzeugung von systeminternem Code.
Funktionen, die der #pragma unmanaged-Direktive folgen. (Beachten Sie, dass umgekehrt #pragma managed ebenfalls unterstützt wird.)
Funktionen, die Verweise auf ausgerichtete Typen, d. h. mit __declspec(align(...)) deklarierte Typen, enthalten.
Die Compiler COM Support-Klassen können nicht mit /clr:pure oder /clr:safe verwendet werden.