Вызов неуправляемого кода из управляемого или порожденного процесса

Question

У меня есть неуправляемый exe-файл C ++, который я мог бы вызывать изнутри моего кода C # (иметь код C ++, который я мог бы сделать lib) или через процесс создания и получения данных из OutputStream. Каковы преимущества / недостатки вариантов?

Answer 1

Поскольку у вас есть исходный код библиотеки C ++, вы можете использовать C ++ / CLI для компиляции его в dll смешанного режима, чтобы его можно было легко использовать в приложении C #.

Преимущество этого будет наиболее гибким в потоке данных (ввод или вывод в этот модуль C ++).

Хотя запуск кода C ++ вне процесса имеет одно преимущество. Если ваш код C ++ не очень устойчив, это может сделать ваш основной процесс C # стабильным, чтобы код C ++ не падал.

Answer 2

Основным недостатком процесса является обеспечение правильной обработки управляемых / собственных взаимодействий.

1)

Код c ++, вероятно, будет зависеть от детерминированного уничтожения для очистки / освобождения ресурсов и т. Д. Я говорю, вероятно, потому что это распространенная и хорошая практика в c ++.

В управляемом коде это означает, что вы должны быть осторожны, чтобы правильно утилизировать код оболочки C ++ Cli. Если ваш код используется один раз, то для вас это сделает предложение using в c #. Если объект должен прожить какое-то время в качестве члена, вы обнаружите, что удаление должно быть приковано цепочкой на всем протяжении вашего приложения.

2)

Другая проблема зависит от того, насколько голодно ваше приложение. Управляемый сборщик мусора может быть ленивым. Гарантируется, что для управляемого распределения требуется больше места, чем доступно. Однако неуправляемый распределитель никак не связан. Поэтому вам необходимо вручную сообщить управляемому распределителю, что вы будете делать неуправляемые выделения и что он должен сохранять это пространство доступным. Это делается с помощью метода AddMemoryPressure.

Основными недостатками выхода из процесса являются:

1) Скорость.

2) Кодовые издержки для управления связью.

3) Издержки кода для наблюдения за тем или иным процессом, умирающим, когда это не ожидается.

Answer 3

Другим недостатком порождения процесса является то, что процесс инициализации в Windows является очень дорогой (медленной) операцией. Если вы собираетесь вызывать код на С ++ довольно часто, это стоит рассмотреть. Преимуществом может быть то, что вы автоматически более изолированы от сбоев в программе на С ++. Отказ от замены исполняемого файла c ++ также может быть преимуществом. Кроме того, написание кода взаимодействия может быть большой проблемой в C #. Если это сложное взаимодействие, и вы решили сделать взаимодействие, посмотрите на c ++ / cli для уровня взаимодействия.

Answer 4

Вам гораздо лучше взять подмножество функций исполняемого файла C ++ и встроить его в библиотеку. Вы сохраните безопасность типов и сможете лучше использовать обработку исключений (не говоря уже о более точном контроле зернистости того, как вы управляете вызовами функций в библиотеке).

Если вы начнете получать данные из OutputStream исполняемого файла, у вас не будет никакой видимости процессов исполняемого файла, никакой реальной обработки исключений, и вы потеряете любую информацию о типах, которая у вас может быть не было.

Answer 5

Большим недостатком очистки OutputStream является отсутствие типизации данных. Я бы предпочел сделать экспорт нескольких функций и повторно использовать существующую библиотеку; но это действительно просто предпочтение.