Создание библиотеки с обратно совместимым ABI, использующим Boost

По сути, просто убедитесь, что общедоступный интерфейс вашей библиотеки не предоставляет Boost. Вы всегда можете использовать его, сколько захотите, для внутреннего пользования. Как правило, наличие зависимости интерфейса библиотеки от другой библиотеки - это плохо (если только это не зависит от стандартной библиотеки, такой как STL). Boost почти вписывается в категорию «стандартных» библиотек, но его ABI меняется настолько, что ваш интерфейс не должен его использовать.

Чтобы убедиться, что вы не показываете символы Boost, вы можете сделать несколько вещей:

A. скомпилировать с -fvisibility=hidden и пометить все общедоступные символы с помощью __attribute__((visibility("default"))). вы можете использовать макрос, чтобы упростить это:

#define ABI __attribute__((visibility("default")))

Б. сделать что-то вроде этого:

#pragma GCC visibility push(hidden)
#include <boost/whatever.hpp>
#pragma GCC visibility pop

Вы также должны обернуть это вокруг всех других внутренних символов, которые вы не хотите экспортировать, или объявите это с помощью __attribute__((visibility("hidden"))). Опять же, вы можете использовать макрос, чтобы упростить это:

#define INTERNAL __attribute__((visibility("hidden")))

Из этих вариантов мне больше нравится A, потому что он заставляет вас явно задуматься о том, какие символы экспортируются, чтобы случайно не экспортировать то, что вам не нужно.

Кстати, вы можете найти гораздо больше информации о создании DSO в Как писать общие библиотеки < / а>.

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

Я нашел эту отличную статью о шагах по превращению вашего API в стабильный ABI. Например, никогда не передавайте типы данных стандартной библиотеки C ++ (или Boost) через ваш интерфейс; он может выйти из строя даже при небольшом исправлении ошибки в библиотеке.

Вот несколько примеров проблем, на которые следует обратить внимание при публикации API-интерфейса, совместимого с ABI:

• Куча отладки Windows. Вы должны быть уверены, что все выделения и освобождения находятся на одной стороне «модуля» (то есть исполняемого файла или DLL).
• Проблема с хрупким двоичным интерфейсом. Даже если обе стороны вашей системы постоянно используют один и тот же компилятор и библиотеки, вы должны быть осторожны в C ++ в отношении того, что вы публикуете в своих .h файлах и где происходит распределение.

Если вы будете следовать связанной статье, вы найдете решения для этих и других проблем.

Изменить:

Я также нашел интересную статью, опубликованную Microsoft, в которой описывается, как работают интерфейсы COM. , взяв проект C ++ и превратив его в COM. Я считаю, что одной из основных причин, по которой Microsoft разработала COM, было решение проблемы хрупкого двоичного интерфейса, которая есть в C ++, чтобы они могли поставлять библиотеки DLL с публикуемыми объектно-ориентированными API.

Рассмотрите возможность использования инструмента abi-compliance-checker для поддержки стабильного интерфейса API / ABI.

У вас должно получиться что-то вроде этого:

namespace XYZ
{
#include <boost/my_library.hpp>
}

И он должен сбрасывать заголовки boost в пространство имен XYZ. Обратите внимание, однако, что это будет работать только с библиотеками только для заголовков.