Чистый и проверяемый код
Обновлен: Ноябрь 2007
Для программирования .NET Visual C++ поддерживает создание трех типов компонентов и приложений: смешанного, чистого и проверяемого. Все три типа можно определить с помощью параметра компилятора /clr (компиляция CLR).
Заметки
Дополнительные сведения о проверяемых сборках см. в следующих разделах:
Смешанный тип (/clr)
Смешанные сборки (скомпилированные с помощью параметра /clr) содержат как неуправляемые, так и управляемые части, что позволяет им использовать функции .NET и при этом содержать неуправляемый код. Это дает возможность приложениям и компонентам обновляться для использования функций .NET без необходимости полного переписывания всего проекта. Использование Visual C++ для смешивания управляемого и неуправляемого кодов таким образом называется "взаимодействием C++". Дополнительные сведения см. в разделах Смешанные (собственные и управляемые) сборки и Взаимодействие исходного кода и платформы.NET.
Чистый тип (/clr:pure)
Чистые сборки (скомпилированные с помощью параметра /clr:pure) могут содержать как неуправляемые, так и управляемые типы данных, но только управляемые функции. Подобно смешанном сборкам, чистые сборки обеспечивают взаимодействие со неуправляемыми библиотеками DLL посредством вызова P/Invoke (см. Использование явного вызова Pinvoke в C++ (атрибут DllImport)), но функции взаимодействия C++ недоступны. Более того, чистые сборки не могут экспортировать функции, которые вызываются из функций машинного кода, поскольку точки входа в чистых сборках используют соглашение о вызове __clrcall.
Преимущества /clr:pure
Более высокая производительность: поскольку чистые сборки содержат только MSIL, в них нет встроенных функций и, следовательно, отсутствует потребность в управляемых/неуправляемых переходах. (Вызовы функций посредством P/Invoke являются исключением из этого правила.)
Информированность о домене приложения: управляемые функции и типы данных CLR существуют внутри Домены приложений, что влияет на их видимость и доступность. Чистые сборки осведомлены о домене (для каждого типа предусмотрена функция __declspec(appdomain)), поэтому доступ к типам и функциям из других компонентов .NET проще и безопаснее. В результате этого чистые сборки проще взаимодействуют с другими компонентами .NET, чем смешанные сборки.
Внедисковая загрузка: чистые сборки могут загружаться в память или даже передаваться потоком. Это особенно важно при использовании сборок .NET как хранимых процедур. Этот аспект отличается от смешанных сборок, которые из-за зависимости от механизмов загрузки Windows, чтобы выполняться, должны существовать на диске.
Отражение: невозможно отражать смешанные исполняемые файлы, но имеется полная поддержка отражения чистых сборок. Дополнительные сведения см. в разделе Отражение в C++.
Управляемость ведущего приложения: поскольку чистые сборки содержат только MSIL, их поведение более предсказуемое и более гибкое, чем у смешанных сборок, когда они используются в приложениях, содержащих CLR и изменяющих поведение по умолчанию.
Ограничения /clr:pure
В этом разделе рассматриваются возможности, не поддерживаемые в настоящее время /clr:pure.
Чистые сборки не могут быть вызваны неуправляемыми функциями. Поэтому чистые сборки не могут реализовывать интерфейсы COM или предоставлять собственные обратные вызовы. Чистые сборки не могут экспортировать функции посредством __declspec(dllexport) или DEF-файлов. Также, функции, объявленные с соглашением __clrcall, не могут быть импортированы посредством __declspec(dllimport). Функции в модуле машинного кода могут быть вызваны из чистой сборки, но чистые сборки не могут предоставлять функции, вызываемые неуправляемыми функциями, поэтому функции предоставления в чистых сборках должны быть обеспеченны посредством управляемых функций в смешанной сборке. Дополнительные сведения см. в разделе Практическое руководство. Миграция в /clr:pure.
Библиотеки ATL и MFC не поддерживаются компилированием в чистом режиме в Visual C++ 2005.
Чистые файлы NETMODULE не могут использоваться в качестве входных файлов компоновщика Visual C++. Однако, чистые OBJ-файлы принимаются компоновщиком и содержат надмножество сведений, содержащихся в файлах NETMODULE. Дополнительные сведения см. в разделе .NETMODULE-файлы в качестве входных файлов компоновщика.
COM-поддержка компилятора (#import) не поддерживается, поскольку это может ввести в чистую сборку неуправляемые инструкции.
Параметры с плавающей запятой для выравнивания и обработки исключений для чистых сборок не являются регулируемыми. В результате этого невозможно использовать __declspec(align). В результате создаются некоторые файлы заголовка, такие как fpieee.h, которые несовместимы с /clr:pure.
Функция GetLastError из пакета PSDK может вести себя непредсказуемым образом при компилировании с помощью /clr:pure.
Проверяемый (/clr:safe)
При использовании параметра компилятора /clr:safe создаются проверяемые сборки, подобные тем, которые пишутся на языках Visual Basic и C#. Эти сборки отвечают требованиям, которые позволяют среде CLR обеспечивать выполнение кода с соблюдением текущих параметров безопасности. Например, если параметры безопасности запрещают какому-либо компоненту запись на диск, среда CLR перед выполнением какого-либо кода может определить, отвечает ли проверяемый компонент критериям безопасности. Поддержка CRT для проверяемых сборок отсутствует. (Поддержка CRT доступна для чистых сборок посредством версии Pure MSIL библиотеки среды выполнения C.)
Проверяемые сборки, в отличие от чистых и смешанных, предоставляют следующие преимущества.
Повышенный уровень защиты.
В некоторых ситуациях это необходимо (например, в случае использования компонентов SQL).
Последующие версии Windows все чаще будут требовать, чтобы определенные компоненты и приложения были проверяемыми.
Одним из недостатков является то, что функции взаимодействия C++ недоступны. Проверяемые сборки не могут содержать неуправляемые функции или собственные типы данных, даже если на них нет ссылок в управляемом коде.
Несмотря на применение слова "safe", компилирующееся приложение с /clr:safe не означает, что в нем нет ошибок; это означает лишь то, что среда CLR может проверить параметры безопасности во время выполнения.
Независимо от типа сборки, вызовы, выполненные из управляемых сборок к неуправляемым библиотекам DLL посредством P/Invoke, будут компилироваться, но могут завершиться неудачей во время выполнения, если возникнет конфликт параметров безопасности.
.gif "Примечание") Примечание. |
|---|
Существует один сценарий кодирования, который будет пропущен компилятором, но приведет к непроверяемой сборке: вызов виртуальной функции через экземпляр объекта с использованием оператора разрешения области действия. Например, MyObj -> A::VirtualFunction();. |