Как стать автором
Обновить

Комментарии 14

Я может глупость скажу, но имея полный доступ к коду C++ почему не использовать COM?
COM — это лишний уровень коссвености. У вас будет ссылка со счётчиком ссылок на ссылку со счётчиком ссылок.

Плюс, COM тоже не кроссплатформенный(если не брать в рассчёт разные wine и прочее подобное ПО), поэтому c++ clr решение тут будет без всяких «если» разумней.
COM крайне криво работает в Mono. Например, GC собирает RCWшки вне зависимости от количества ссылок на них, да и вообще творятся разные непотребства.
Возник такой же вопрос, но уже пояснили, что причиной было требование кроссплатформенности. Однако интересно было бы сравнить производительность этого решения и реализации через COM. У меня сейчас есть C# приложение, которое гоняет огромные объемы данных, получая их через COM. И основное узкое место, судя по профайлеру — это именно маршалинг больших строк. Приложение переписать на C++ сложно, перевести COM-библиотеку на C# не менее сложно. Пока с этим живем, но хочется ускорить.
Проще приготовить assembly с нужными интерфейсами на managed c++. Единственное, что сиё не кроссплатформенно пока что, зато позволяет сгенерировать более производительный биндинг (а зачем ещё плюсы тащить в .Net?)

Вот я бы лучше послушал чей нить succsess story использования swig'a для сложного api.

А так, имхо получилась статья про то, как сделать C биндинг к .Net (притом в рантайме по факту) а потом как на C++ сделать C биндинг (с этой задачей тот же swig точно неплохо справляется, без сниппетов и алкоголя).
Есть проект CppSharp для генерации оберток вокруг C++ в C#
И он делает примерно тоже самое. Только сам.
Зачем писать велосипед? Возьмите SWIG http://www.swig.org/
Когда-то давно приходилось использовать C++/CLI для подобных целей, писал статью об этом:

habrahabr.ru/post/47732

Но это было аж в 2008, хз, актуально ли это сегодня :)

P.S. лол, с тех пор хабрахабр разучился поддерживать некоторую разметку, такшта статья нечитабельна
UPD: восстановил разметку, порядком помучавшись. Enjoy.
Я от таких решений полностью отказался в пользу IPC и отдельных процессов для managed и unmanaged кода. Если managed thread зависает или локается внутри unmanaged call, чтобы организовать ему interrupt или abort пришлось городить отдельную обертку отслеживающую thread native id и грохающую тред на «том конце». В результате еще и память подтекает после «ForcedNativeAbort». Вобщем не рекомендую, но это мое субъективное мнение конечно же.
Ну и да, тем где это действительно было нужно (отладка HLSL кода в WPF, тут код по процессам никак не получится раскидать) я пользовался все же C++/CLI, как выше уже неоднократно заметили это более подходящий инструмент.
Мусье, вы написали декоратор.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий