C++/CLI + Boost + моно

Общие сведения: у меня есть совместимый со стандартами C++ API, который использует библиотеки Boost, которые я хотел бы поддерживать как нативную, статически связываемую библиотеку в Windows, OS X и Linux, и которую я хотел бы обернуть для .NET в Windows и Mono. на OS X и Linux.

Особенности: В настоящее время он компилируется нативно для всех платформ - это следует из использования стандартного C++ и Boost. Я также получил его для компиляции и запуска для C++/CLI в Windows, но я был вынужден использовать Boost .DLL. Следующий шаг Я не знаю, с чего начать, так как я никогда не пытался использовать разделяемые библиотеки в системах *nix. Я знаю, что Boost предоставляет общие библиотеки для Linux (и я предполагаю, что то же самое верно и для OS X), но будут ли они работать автоматически с моим исполняемым файлом C++/CLI, скомпилированным в Visual Studio, или мне нужно выполнить некоторую работу? Для MonoDevelop нет компилятора C++/CLI, но, предположительно, CLI, скомпилированный в Visual Studio, будет работать нормально... Меня смущают динамически подключаемые библиотеки.


.net cross-platform c++-cli mono dynamic-linking
person Jonathan    schedule 02.11.2010    source источник
comment
В общем, это возможно, как указано в ответе Рида Копси. Однако из-за того, что Boost интенсивно использует шаблоны и классы, это может быть сложно или невозможно, и вам может потребоваться написать оболочку.   -  person ssube    schedule 02.11.2010

Ответы (4)


arrow_upward
7
arrow_downward

Сборки C++/CLI будут загружаться в Mono только в том случае, если они скомпилированы с /clr:pure. Сборка C++/CLI в смешанном режиме (любая сборка, использующая собственный код, т. е. Boost) не будет работать на платформах, отличных от Windows.

Лучше всего предоставить C API и использовать P/Invoke для вызова собственного кода. Это переносимо между платформами, если вы включаете один и тот же C API на обеих платформах.

person Reed Copsey    schedule 02.11.2010

arrow_upward
2
arrow_downward

Я уверен, что вы уже нашли другое решение, но я уверен, что этот вопрос все еще появляется в результатах поиска.

Mono недавно добился довольно больших успехов в совместимости с C++ в CXXI.

Из этого сообщения следует, что новая технология CXXI ​​позволяет C# /.NET-разработчикам:

  • Легко используйте существующие классы C++ из C# или любого другого языка .NET.
  • Создание экземпляров объектов C++ из C#
  • Вызов методов C++ в классах C++ из кода C#
  • Вызывать встроенные методы C++ из кода C# (при условии, что ваша библиотека скомпилирована с помощью -fkeep-inline-functions или вы предоставили суррогатную библиотеку)
  • Классы подкласса C++ из C#
  • Переопределить методы C++ методами C#
  • Предоставляйте экземпляры классов C++ или смешанных классов C++/C# как для кода C#, так и для C++, как если бы они были собственным кодом.

CXXI — это результат двухлетней работы Google Summer of Code над улучшением совместимости Mono с языком C++.

person Justin    schedule 17.02.2012

arrow_upward
1
arrow_downward

Вы не можете сделать это в C++/CLI, потому что C++/CLI — это не C++. Как говорит Рид, вам нужно будет компилировать с использованием /clr:pure, что заставит вас удалить замену каждого отдельного класса классом CLR, и что в первую очередь лишает смысла пытаться скомпилировать там.

Почему вы пытаетесь это сделать?

person Billy ONeal    schedule 02.11.2010
comment
Я надеялся, что если я сделаю это таким образом и мои управляемые оболочки будут в том же проекте, что и неуправляемый класс, то C++/CLI позаботится о деталях переносимости и закрепления за меня для передачи ссылок между родным и управляемым разделами. Меня беспокоит только то, что я пишу свои оболочки только на C++/CLI, что мне придется самому управлять этими деталями... Хотя, похоже, мне придется. - person Jonathan; 02.11.2010

arrow_upward
0
arrow_downward

Имейте в виду, что .net придерживается "Fusion" в качестве модели для поиск библиотек (которые в .net практически все динамически связаны). На платформе Windows собственный код не соответствует модели загрузки Fusion. Ознакомьтесь с документацией LoadLibraryEx, прочитав, откуда она говорит:

Функция LoadLibraryEx выполняет стандартный поиск модулей, если имя файла указано без пути и имя базового файла не совпадает с именем базового файла загруженного модуля, или указан путь, но не используется LOAD_WITH_ALTERED_SEARCH_PATH.

...и следующие абзацы. Способ, которым я построил C# для C++/CLI, состоит в том, чтобы мой загрузчик C# проверял, выполняется ли JIT-компиляция в настоящее время как x86 или x64, а затем я явно загружаю сборку C++/CLI, соответствующую этой архитектуре. Если вы этого не сделаете, вы не сможете скомпилировать как AnyCPU на стороне C#.

Как это работает вне Windows, я не знаю...

person Brent Arias    schedule 02.11.2010