Преобразование проекта c ++ в безопасный проект clr

Question

Мне нужно поработать над преобразованием очень большого проекта c ++ в clr safe. В текущем проекте c ++ есть много вещей из c ++, таких как шаблоны, шаблоны, указатели, хранилище / поток, ole apis, zlib apis сжатия, inline и т. Д. Где я могу найти документ с датами для этого типа преобразования? Можете ли вы предложить какую-нибудь хорошую книгу для ссылки? Если кто-то из вас сделал такое обращение, могу ли я получить от вас анализ?

Answer 1

Я просто напишу статью MSDN Library под названием «Как: перейти на / clr: safe

Visual C ++ может генерировать проверяемые компоненты с помощью / clr: safe, что заставляет компилятор генерировать ошибкидля каждой не проверяемой конструкции кода.

Следующие проблемы приводят к ошибкам проверяемости:

• Собственные типы. Даже если он не используется, объявление собственных классов, структур, указателей, или массивы будут препятствовать компиляции.
• Глобальные переменные
• Вызовы функций в любую неуправляемую библиотеку, включая вызовы функций времени выполнения общего языка
• Проверяемая функция не может содержать оператор static_cast для down-casting. Оператор static_cast может использоваться для приведения между примитивными типами, но для приведения вниз необходимо использовать safe_cast или приведение в стиле C (которое реализовано как safe_cast).
• Проверяемая функция не можетсодержит оператор reinterpret_cast (или любой эквивалент в стиле C).
• A veriфункция fiable не может выполнять арифметику для interior_ptr.Он может только присваивать ему и разыменовывать его.
• Проверяемая функция может только бросать или перехватывать указатели на ссылочные типы, поэтому типы значений должны быть помещены в квадрат перед броском.
• Проверяемая функция может вызывать только проверяемые функции (например, запрещены вызовы общеязыковой среды выполнения, включая AtEntry / AtExit и поэтому глобальные конструкторы запрещены).
• Проверяемый класс не может использовать Explicit.
• При сборке EXE главная функция не может объявлять какие-либо параметры, поэтому для получения аргументов командной строки необходимо использовать GetCommandLineArgs.
• Выполнение не виртуального вызова виртуальной функции.

Кроме того, в проверяемом коде нельзя использовать следующие ключевые слова:

• неуправляемый и пакетpragmas
• голый и выравнивающий __declspec модификаторы
• __ asm
• __ на основе
• __ try и __except

Я считаю, что вы будете держатькакое-то время занятНет волшебной палочки, чтобы помахать родным C ++ в проверяемый код.Вы уверены, что это стоит вложений?

Answer 2

Перезапись собственного C ++ в safe C ++ / CLI приведет к синтаксически другому коду, но семантически такому же, как C #. Если это так, почему бы не переписать непосредственно в C #?

Если вы хотите избежать того, что по сути является полным переписыванием, рассмотрите следующие альтернативы:

• P / Invoke . К сожалению, я не знаю, будет ли это изолировать безопасный от небезопасного кода. Даже если он может выполнять изоляцию, вам нужно обернуть существующий код C ++ в процедурный, C-подобный API, чтобы он мог использоваться P / Invoke. С другой стороны, если ваш API не слишком болтлив, вы можете сохранить (большую часть) исходную производительность.
• Оборачивание вашего C ++ в внепроцессный COM-сервер и использование COM Interop для использования его из управляемого кода. Таким образом, ваш управляемый код полностью защищен от любого повреждения, которое может произойти в конце C ++, и может оставаться «безопасным». Недостатком является снижение производительности, которое вы получите за маршалинг вне процесса и усилия по внедрению, которые вам придется потратить, чтобы правильно реализовать COM.

Answer 3

Подавляющее большинство нативного C ++ является полностью допустимым C ++ / CLI, включая шаблоны, встроенные строки и т. Д., За исключением того, что CLR STL довольно медленный по сравнению с BCL. Кроме того, нативный C ++ не имеет обобщений, только шаблоны.

Реальность компиляции как C ++ / CLI заключается в проверке переключателя и принудительной компиляции, а также в ожидании появления ошибок.