на языках, которые могут ссылаться на С++

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

Связывание с C++ маловероятно, поскольку ABI не определен. Таким образом, имена символов могут меняться по желанию производителя компилятора. Например, GCC делает это иначе, чем компилятор MS. Даже с одним и тем же компилятором ABI могут различаться между версиями (как в случае с некоторыми версиями GCC).

Однако связывание с C++ возможно. Программы на C++ часто ссылаются на другие программы на C++, потому что обе компилируются одним и тем же компилятором (или, по крайней мере, компиляторами, использующими один и тот же ABI). Если известен ABI, приложения, отличные от C++, могут ссылаться на приложения C++.

Связать с C очень просто. Это связано с тем, что ABI C более стабилен, чем ABI C++ для большинства платформ. Это связано с простотой C по сравнению с C++. Поскольку C++ может экспортировать символы C, обходя проблему с ABI C++, вы иногда видите, что библиотеки C++ экспортируют символы C, которые позволяют взаимодействовать с базовыми объектами C++ без проблем с искажением имен, совместимостью ссылок и перспективой. Однако это не позволяет вам легко использовать библиотеку C++ через интерфейс C с интерфейсом C++.

Но вы можете использовать интерфейс C++, используя экспорт C. Библиотека может предоставить некоторые классы в файлах заголовков, которые обертывают для вас экспорт C. Это больше работы для авторов библиотек (и может вызвать некоторые проблемы, потому что DRY обычно не практикуется с этой техникой), но дает большую пользу пользователям библиотек (которые могут выбирать между обоими интерфейсами, не беспокоясь о проблемах с компоновкой!). Для других языков авторы библиотек могут предоставить интерфейсы, такие как файлы заголовков C++, которые сами имеют дело с экспортом C. (Тогда у вас есть преимущество использования нативных классов и тому подобного.)

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

Причина, по которой так много вещей может быть связано с C, заключается в том, что C имеет простую и непротиворечивую связь. Функция foo называется foo в объектном файле. Точно так же вещи могут быть достаточно хорошо связаны с Fortran, потому что foo является одним из foo, FOO, foo_ или foo__.

Вот почему существует так много генераторов оболочек для объектов C++ (SWIG, Boost.Python, SIP и т. д.). Они определяют интерфейс как набор вызовов C именно потому, что это упрощает компоновку.

Еще кое-что, о чем следует помнить, это то, хотите ли вы действительно связываться напрямую с библиотеками C++. Многие генераторы оболочек предоставляют множество параметров политики при создании оболочек. Помните, что вызовы C сводятся только к функциям, но вызовы C++ обычно имеют много объектно-ориентированной семантики, с которой вам нужно ориентироваться. Вам нужно указать, как ваши объекты C++ должны быть собраны мусором в основном языке, как вещи копируются, где находятся vptrs, как размещаются объекты, где объекты распределяются, а также все тонкие различия между объектной моделью основного языка и этой моделью. С++.

Я знаю, что это звучит идеально, просто связать библиотеку C++ и покончить с этим, но это не так просто, и вам в любом случае понадобится нечто большее, чем просто прямая связь.

Недавно просматривали SWIG?