C ++ вызов параметров C #
https://stackoverflow.com/questions/1069674
-
21-08-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
У нас есть собственный код Win32 C ++ и набор сборок C #, которые мы хотим вызвать из кода C ++.Я резюмирую наши варианты следующим образом:
Используйте COM.Код C # необходимо было бы украсить дополнительными атрибутами (GUID, ComVisible).Сборки C # должны быть зарегистрированы regasm и затем будут доступны для собственного кода C ++ через COM.
Используйте класс-оболочку C ++ / CLI (ранее управляемый C ++).Класс C ++ может быть добавлен в собственный проект C ++.Этот класс был бы скомпилирован с помощью /clr.Собственный код C ++ вызвал бы класс C ++ / CLI, который затем вызвал бы код .Net.Никакой связи не было.Среда CLR запускается с помощью магии, как требуется, с маршалингом, обрабатываемым расширениями C ++ / CLI.
Разместите экземпляр CLR в собственном коде C ++.
Я собираюсь отказаться от варианта 3, поскольку я не вижу преимуществ по сравнению с вариантом 2, кроме того, что мы теряем потребность в классе-оболочке.Итак, вопрос в том, каковы плюсы / минусы варианта 1 по сравнению с вариантом 2?
Заранее благодарю.
Решение
Вариант 2 будет работать наилучшим образом и будет наиболее плавным и ремонтопригодным, IMO.
На самом деле у варианта 1, который я нашел, нет никаких преимуществ.Использование C ++ / CLI, кажется, функционирует намного лучше, работает быстрее и в целом намного проще.
Вы также можете, кстати, просто использовать сборку C # напрямую, не имея класса-оболочки.Это требует компиляции любых файлов, которые хотят использовать его с / CLR, но это работает довольно хорошо.
Другие советы
Для варианта 1 вашим главным плюсом было бы отсутствие необходимости писать класс-оболочку, который может усложниться в зависимости от вашего проекта.
Для варианта 2 вам не придется изменять свою управляемую библиотеку для облегчения неуправляемого использования, что иногда невозможно.
Для меня все сводится к тому, где вы хотите внести изменения в свой код.
С вариантом 2 у вас также есть довольно простой способ последующего преобразования всего вашего приложения в C ++ / CLI, чтобы избежать управляемых / неуправляемых переходов, которые вы получите.Переходы могут быть проблемой в зависимости от того, как вы используете свои сборки, на которые ссылаетесь, т.е.достижение успеха в исполнении.
До сих пор у меня был только положительный опыт работы с C ++ / CLI, и я могу порекомендовать пойти по этому пути.
