Создание Библиотеки с обратно совместимым ABI, который использует Повышение

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

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

а. скомпилируйте с -fvisibility = hidden и пометьте все общедоступные символы атрибутом __ __ ((видимость («по умолчанию»)))) . Вы можете использовать макрос, чтобы сделать это проще:

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

B. сделайте что-то вроде этого:

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

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

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

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

Между прочим, вы можете найти гораздо больше информации о создании DSO в Ульрихе Дреппере Как писать общие библиотеки .

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

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

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

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

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

Edit :

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

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

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

You should be able to do something like this:

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

And it should dump the boost headers into namespace XYZ. Note, however, that this will only work with the header-only libraries.

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