Чистый и проверяемый код (C++/CLI)

Для программирования .NET Visual C++ поддерживает создание трех типов компонентов и приложений: смешанного, чистого и проверяемого.Все три типа можно определить с помощью параметра компилятора /clr (компиляция CLR).

Заметки

Дополнительные сведения о проверяемых сборках см. в следующих разделах:

• Сравнение смешанных, чистых и проверяемых компонентов (C++/CLI)

• Практическое руководство. Миграция в /clr:pure (C++/CLI)

• Практическое руководство. Создание проверяемых проектов на языке C++ (C++/CLI)

• Практическое руководство. Миграция в /clr:safe (C++/CLI)

• Использование проверяемых сборок вместе с SQL Server (C++/CLI)

• Рекомендации по безопасности для C++

• Преобразование проектов из смешанного режима в чистый промежуточный язык

Смешанный режим (/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 существуют внутри Application Domains, что влияет на их видимость и доступность.Чистые сборки осведомлены о домене (для каждого типа предусмотрена функция __declspec(appdomain)), поэтому доступ к типам и функциям из других компонентов .NET проще и безопаснее.В результате этого чистые сборки проще взаимодействуют с другими компонентами .NET, чем смешанные сборки.

• Внедисковая загрузка: чистые сборки могут загружаться в память или даже передаваться потоком.Это особенно важно при использовании сборок .NET как хранимых процедур.Этот аспект отличается от смешанных сборок, которые из-за зависимости от механизмов загрузки Windows, чтобы выполняться, должны существовать на диске.

• Отражение: невозможно отражать смешанные исполняемые файлы, но имеется полная поддержка отражения чистых сборок.Для получения дополнительной информации см. Отражение (C++/CLI).

• Управляемость ведущего приложения: поскольку чистые сборки содержат только MSIL, их поведение более предсказуемое и более гибкое, чем у смешанных сборок, когда они используются в приложениях, содержащих CLR и изменяющих поведение по умолчанию.

Ограничения /clr:pure

В этом разделе рассматриваются возможности, не поддерживаемые в настоящее время /clr:pure.

• Чистые сборки не могут быть вызваны неуправляемыми функциями.Поэтому чистые сборки не могут реализовывать интерфейсы COM или предоставлять собственные обратные вызовы.Чистые сборки не могут экспортировать функции посредством __declspec(dllexport) или DEF-файлов.Также, функции, объявленные с соглашением __clrcall, не могут быть импортированы посредством __declspec(dllimport).Функции в модуле машинного кода могут быть вызваны из чистой сборки, но чистые сборки не могут предоставлять функции, вызываемые неуправляемыми функциями, поэтому функции предоставления в чистых сборках должны быть обеспеченны посредством управляемых функций в смешанной сборке.Дополнительные сведения см. в разделе Практическое руководство. Миграция в /clr:pure (C++/CLI).

• Библиотеки ATL и MFC не поддерживаются при компиляции в режиме чистого промежуточного языка в Visual C++.

• Чистый .Файлы 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, будут компилироваться, но могут завершиться неудачей во время выполнения, если возникнет конфликт параметров безопасности.

Примечание
Существует один скрипт кодирования, который будет пропущен компилятором, но приведет к непроверяемой сборке: вызов виртуальной функции через экземпляр объекта с использованием оператора разрешения области действия.Например, MyObj -> A::VirtualFunction();.

См. также

Другие ресурсы

Программирование в Visual C++ .NET