/clr Ograniczenia

  • Artykuł

Zwróć uwagę na następujące ograniczenia dotyczące korzystania z programu /clr:

  • W programie obsługi wyjątków ustrukturyzowanych istnieją ograniczenia dotyczące używania _alloca podczas kompilowania za pomocą /clrpolecenia . W celu uzyskania więcej informacji, zobacz następujący temat: _alloca.

  • Użycie sprawdzania błędów w czasie wykonywania nie jest prawidłowe w przypadku /clrpolecenia . Aby uzyskać więcej informacji, zobacz How to: Use native run-time checks (Instrukcje: używanie natywnych testów w czasie wykonywania).

  • Gdy /clr program jest używany do kompilowania programu, który używa tylko standardowej składni języka C++, następujące wytyczne dotyczą korzystania z wbudowanego zestawu:

    • Wbudowany kod zestawu, który zakłada, że znajomość układu stosu natywnego, wywoływanie konwencji poza bieżącą funkcją lub inne informacje niskiego poziomu dotyczące komputera mogą zakończyć się niepowodzeniem, jeśli ta wiedza jest stosowana do ramki stosu dla funkcji zarządzanej. Funkcje zawierające wbudowany kod zestawu są generowane jako funkcje niezarządzane, tak jakby zostały umieszczone w osobnym module, który został skompilowany bez /clrelementu .

    • Wbudowany kod zestawu w funkcjach, które przekazują parametry funkcji skonstruowanych w trybie kopiowania, nie jest obsługiwany.

  • vprintf Nie można wywołać funkcji z programu skompilowanego za pomocą /clrpolecenia .

  • Modyfikator naked__declspec jest ignorowany w obszarze /clr.

  • Funkcja translator ustawiona przez _set_se_translator będzie mieć wpływ tylko na przechwyt w kodzie niezarządzanych. Aby uzyskać więcej informacji, zobacz Obsługa wyjątków.

  • Porównanie wskaźników funkcji nie jest dozwolone w obszarze /clr.

  • Korzystanie z funkcji, które nie są w pełni prototypowane, nie jest dozwolone w obszarze /clr.

  • Następujące opcje kompilatora nie są obsługiwane w programie /clr:

  • Kombinacja _STATIC_CPPLIB definicji preprocesora (/D_STATIC_CPPLIB) i /clr opcji kompilatora nie jest obsługiwana. Jest to spowodowane tym, że definicja spowoduje, że aplikacja będzie łączyć się ze statyczną, wielowątkową standardową biblioteką C++, która nie jest obsługiwana. Aby uzyskać więcej informacji, zobacz /MD, /LD/MT( Użyj biblioteki czasu wykonywania).

  • W przypadku używania z /clrprogramem /Zi istnieją konsekwencje dla wydajności. W celu uzyskania więcej informacji, zobacz następujący temat: /Zi.

  • Przekazywanie szerokiego znaku do procedury wyjściowej programu .NET Framework bez określania lub bez rzutowania /Zc:wchar_t znaku w taki _wchar_t sposób spowoduje, że dane wyjściowe będą wyświetlane jako unsigned short int. Przykład:

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

  • /GS Polecenie jest ignorowane podczas kompilowania z elementem /clr, chyba że funkcja jest w obszarze #pragma unmanaged lub jeśli funkcja musi być skompilowana jako kod natywny, w tym przypadku kompilator wygeneruje ostrzeżenie C4793, które jest domyślnie wyłączone.

  • Zobacz /ENTRY wymagania dotyczące podpisu funkcji aplikacji zarządzanej.

  • Aplikacje skompilowane za pomocą /openmp polecenia i /clr mogą być uruchamiane tylko w jednym procesie domeny aplikacji. Aby uzyskać więcej informacji, zobacz /openmp (Włączanie obsługi protokołu OpenMP 2.0).

  • Funkcje, które przyjmują zmienną liczbę argumentów (varargs), zostaną wygenerowane jako funkcje natywne. Wszystkie zarządzane typy danych w pozycji argumentu zmiennej będą marshalowane do typów natywnych. Wszystkie System.String typy są w rzeczywistości ciągami o szerokim znaku, ale są one marshalowane do ciągów znaków jednobajtowych. Dlatego jeśli printf specyfikator to %S (wchar_t*), zamiast tego będzie on marshalingiem %s do ciągu.

  • Podczas korzystania z makra va_arg podczas kompilowania /clr:pureza pomocą polecenia można uzyskać nieoczekiwane wyniki. Aby uzyskać więcej informacji, zobacz , , va_endva_copy, va_start.va_arg Opcje /clr:pure i /clr:safe kompilatora są przestarzałe w programie Visual Studio 2015 i nieobsługiwane w programie Visual Studio 2017 lub nowszym. Kod, który musi być "czysty" lub "bezpieczny", powinien być przekierowywany do języka C#.

  • Nie należy wywoływać żadnych funkcji, które przeprowadzą stos, aby uzyskać informacje o parametrach (argumenty funkcji) z kodu zarządzanego. Warstwa P/Invoke powoduje, że informacje są dalej w stosie. Na przykład nie kompiluj serwera proxy/wycinku za pomocą polecenia /clr.

  • Funkcje zostaną skompilowane do kodu zarządzanego zawsze, gdy jest to możliwe, ale nie wszystkie konstrukcje języka C++ można przetłumaczyć na zarządzany kod. To określenie jest wykonywane na podstawie funkcji po funkcji. Jeśli nie można przekonwertować żadnej części funkcji na kod zarządzany, zamiast tego cała funkcja zostanie przekonwertowana na kod natywny. Następujące przypadki uniemożliwiają kompilatorowi generowanie kodu zarządzanego.

    • Generowane przez kompilator funkcje thunks lub pomocnika. Natywne thunks są generowane dla dowolnego wywołania funkcji za pośrednictwem wskaźnika funkcji, w tym wywołań funkcji wirtualnych.

    • Funkcje wywołujące setjmp lub longjmp.

    • Funkcje, które używają pewnych procedur wewnętrznych do bezpośredniego manipulowania zasobami maszyny. Na przykład użycie funkcji __enable i __disable_ReturnAddress i _AddressOfReturnAddresslub elementów wewnętrznych multimediów spowoduje, że kod natywny będzie w kodzie natywnym.

    • Funkcje zgodne z dyrektywą #pragma unmanaged . (Odwrotność, #pragma managed, jest również obsługiwana).

    • Funkcja zawierająca odwołania do wyrównanych typów, czyli typów zadeklarowanych przy użyciu polecenia __declspec(align(...)).

Zobacz też