Kod czysty i weryfikowalny (C++/CLI)
Podczas programowania .NET, Visual C++ obsługuje tworzenie trzy różne typy składników i aplikacji: mieszane, czystych i sprawdzalnych.Wszystkie trzy są dostępne za pośrednictwem /clr (Kompilacja środowiska uruchomieniowego języka wspólnego) opcję kompilatora.
Uwagi
Aby uzyskać więcej informacji na temat zestawów sprawdzalne zobacz:
Porównanie funkcji mieszanych, czystych i weryfikowalnych (C++/CLI)
Używanie zestawów weryfikowalnych z programem SQL Server (C++/CLI)
Konwertowanie projektów z trybu mieszanego na czysty język bezpośredni
Mieszane (/ clr)
Mieszane zestawy (skompilowane z /clr), zawierają zarówno niezarządzanych i zarządzanych części, umożliwiając w ten sposób korzystać z funkcji .NET, ale nadal zawierają kod niezarządzany.Dzięki temu aplikacje i składniki można zaktualizować korzystać z funkcji .NET bez konieczności przebudowywany całego projektu.Przy użyciu języka Visual C++ mieszać zarządzany i niezarządzany — kod w ten sposób nazywa się C ++ Interop.Aby uzyskać więcej informacji, zobacz Zestawy mieszane (natywne i zarządzane) i Współdziałanie natywne i .NET.
Czysty (/ clr: pure)
Czyste zestawy (skompilowane z /clr:pure) może zawierać obu typów danych macierzystego i zarządzanego, ale tylko zarządzane funkcji.Podobnie jak zestawy mieszane, czystych zestawów umożliwiają współdziałania z macierzystego dll za pomocą P i Invoke (zobacz Używanie jawnej funkcji PInvoke w języku C++ (atrybut DllImport)), ale nie są dostępne funkcje C++ Interop.Ponadto, czystych zestawów nie można wyeksportować funkcji, które są można wywoływać ze macierzystych funkcji, ponieważ używają punktów wejścia w zestawie czystego __clrcall konwencji wywoływania.
Zalety/CLR: pure
Lepszą wydajność: Ponieważ czystych zestawów zawierają tylko MSIL, nie ma żadnych funkcji macierzystego i dlatego żadnych zarządzanych/niezarządzanych przejść są niezbędne. (Wyjątek od tej reguły są wywołania funkcji za pośrednictwem P i Invoke.)
Świadomość elementu AppDomain: CLR typy danych i funkcje zarządzanych istnieje wewnątrz Application Domains, które wpływają na ich widoczność i dostępności.Czyste zestawy są świadomi domeny (__declspec (appdomain) jest domyślna dla każdego typu) więc dostęp do ich typy i funkcje z innych składników platformy .NET jest łatwiejsze i bezpieczniejsze.W rezultacie czystych zestawów łatwiej współdziałać z innymi składnikami systemu .NET niż mieszanych zestawów.
Ładowanie na dysk non: czysty zespoły mogą być ładowane w pamięci i nawet strumieniowo.Jest to istotne dla przy użyciu zestawów .NET jako procedur przechowywanych.To różni się od mieszanych zespołów, które ze względu na zależność od Windows ładowanie mechanizmy, musi istnieć na dysku w celu wykonania.
Odbicie: To nie jest możliwe odzwierciedlają nad mieszanych pliki wykonywalne, czystych zestawów przewiduje wsparcie Pełne odbicie.Aby uzyskać dodatkowe informacje, zobacz Odbicie (C++/CLI).
Możliwości kontroli host: Ponieważ czystych zestawów zawierają tylko MSIL, zachowują się bardziej przewidywalny i elastycznie niż mieszane zestawów używanych w aplikacjach obsługujących środowisko CLR i zmodyfikować jego domyślne zachowanie.
Ograniczenia/CLR: pure
W tej sekcji omówiono funkcje nie są obecnie obsługiwane przez /clr:pure.
Nie można wywołać czystych zestawów przez funkcje niezarządzanego.Dlatego czystych zestawów nie mogą implementować interfejsów COM lub narażać rodzimych wywołań zwrotnych.Czyste zestawy nie można wyeksportować funkcji za pomocą __declspec(dllexport) lub.Pliki DEF.Ponadto funkcje deklarowane z Konwencji __clrcall nie można importować za pośrednictwem __declspec(dllimport).Funkcje w module macierzystych mogą być wywoływane z czystego zestawu, ale czystych zestawów nie może ujawnić funkcje nieopłacona w trybie macierzystym, więc narażając funkcjonalność w czysty zebranie muszą być wykonywane przez zarządzanej funkcji w zestawie mieszanym.Aby uzyskać więcej informacji, zobacz Porady: migracja do /clr:pure (C++/CLI).
Biblioteki ATL i MFC nie są obsługiwane przez kompilacji w trybie wyłącznie w programie Visual C++.
Czysty .netmodules nie są akceptowane jako dane wejściowe do linker Visual C++.Jednak pliki .obj czystego są akceptowane przez program łączący i pliki .obj zawierają nadzbiór informacji zawartych w netmodules.Aby uzyskać więcej informacji, zobacz Pliki .netmodule — Wejście konsolidatora.
Obsługa kompilatora COM (#import) nie jest obsługiwana, jak to wprowadziłaby niezarządzanych instrukcje do czystego zespołu.
Zmiennoprzecinkowych, że opcje wyrównania i obsługi wyjątków nie są regulowane dla czystych zestawów.W rezultacie nie można użyć __declspec(align).To czyni niektóre pliki nagłówkowe, takich jak fpieee.h, niezgodne z/CLR: czysty.
Funkcja GetLastError w PSDK może dać niezdefiniowane zachowanie podczas kompilacji z /clr:pure.
Sprawdzalne (/ clr:safe)
/clr:safe Opcję kompilatora generuje zestawów sprawdzalne, podobnie jak makra napisane w języku Visual Basic i C#, zgodne z wymaganiami, które pozwalają common language runtime (CLR), aby zagwarantować, że kod nie narusza ustawienia zabezpieczeń.Na przykład jeśli ustawienia zabezpieczeń uniemożliwiają składnik od pisania na dysk, CLR można określić, czy składnik sprawdzalne spełnia to kryterium przed wykonaniem kodu.Nie ma nie CRT obsługę zestawów sprawdzalnych. (Obsługa CRT jest dostępna do czystych zestawów przy użyciu wersji czystego MSIL C Runtime Library).
Sprawdzalne zestawów oferują następujące zalety w porównaniu do czystego i mieszanych zestawów:
Zwiększone bezpieczeństwo.
Niektóre sytuacje wymagają go (na przykład składniki SQL).
Składniki i aplikacje, aby były weryfikowalne coraz bardziej wymaga przyszłych wersji systemu Windows.
Wadą jest funkcji współdziałania C++ nie są dostępne.Sprawdzalne zestawów nie może zawierać żadnych funkcji niezarządzanych lub macierzyste typy danych, nawet jeśli nie są one wywoływane przez kod zarządzany.
Pomimo użycia słowa "bezpieczne", kompilowania aplikacji za pomocą /clr:safe nie znaczy istnieją nie błędy; po prostu oznacza, że środowisko CLR można zweryfikować ustawienia zabezpieczeń w czasie wykonywania.
Niezależnie od typu zestawu połączeń z zestawów zarządzanych do macierzystych bibliotek DLL za pomocą P i Invoke zostanie skompilowany, ale może się nie powieść w czasie wykonywania, w zależności od ustawień zabezpieczeń.
[!UWAGA]
Istnieje jeden scenariusz kodowania, która przemija kompilator, a w efekcie w zespole niemożliwy: wywołanie funkcji wirtualnych za pośrednictwem instancji obiektu przy użyciu operatora zakres rozdzielczości. Na przykład: MyObj -> A::VirtualFunction();.