Используя одновременно 2 версии повышения

Если немного повезет (и проявит большую осторожность), вы , вероятно, сможете обойтись без использования совершенно новых заголовков. Практически для всего остального это может стать уродливым в спешке, потому что некоторые части Boost ссылаются на другие части, и если какой-то код v. 1.33 случайно загружает заголовок v. 1.43 для своей зависимости, есть довольно хороший шанс, что вы собираетесь чтобы получить в результате некоторые проблемы - лучшее, на что вы можете надеяться, - это быстрая, чистая смерть (сбой) в этот момент, но вы можете легко стать намного хуже (например, незаметное повреждение данных).

НЕТ, никогда не делайте этого!

Это невозможно, скорее всего, вы попадете в аварию.

Единственный способ сделать это правильно - использовать переименование пространства имен: т.е. создать альтернативу версия boost помещена в другое пространство имен .

Последняя версия BCP предоставляет эту возможность. Таким образом, вы будете использовать что-то вроде boost_1_43 вместо boost. Но для вас это будет достаточно прозрачно. Но вы все равно должны знать из этого вы не можете использовать две версии повышения в одном файле cpp.

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

Любимый скрипт переименовывает пространство имен, определяет и включает, так что вы можете фактически включить два версии Boost, такие как

#include <boost/foo.hpp>
#include <myboost/bar.hpp>

boost::foo f;
myboost::bar b;

Boost BCP, не позволяют этого.

Но все же будьте осторожны, так как некоторые библиотеки экспортируют внешние символы "C" без префикс boost, boost :: thread и boost :: regex API C (regexec, regcomp)

Edit

В качестве примера такой проблемы создайте следующие файлы:

a.cpp:

template<typename Foo>
Foo add(Foo a, Foo b)
{
        return a+b;
}


int foo(int x,int y)
{
        return add(x,y);
}

b.cpp:

template<typename Foo>
Foo add(Foo a, Foo b)
{
        return a-b;
}


int bar(int x,int y)
{
        return add(x,y);
}

test.cpp:

#include <iostream>

int foo(int,int);
int bar(int,int);

int main()
{
        std::cout<< foo(10,20) <<" " <<bar(10,20) << std::endl;
}

Скомпилируйте их:

g++ a.cpp b.cpp test.cpp

Вы ожидаете:

30 -10

Но вы получите

30 30

или

-10 -10

В зависимости от порядка связывания.

Таким образом, используя две версии ускорения, вы можете случайно использовать символы из другого ускорения и сбоя. то же, что и в этой программе, символ int add (int, int) разрешается в тот же символ, даже если он размещен в разных единицах компиляции.

Обновление

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

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

Оригинальный ответ

Пока вы используете одну версию для каждого шага компиляции, все должно быть в порядке, потому что код генерируется во время компиляции, и генерируемые символы должны быть ограничены рамками шага компиляции.

Я предполагаю, что Boost все еще является библиотекой шаблонов без подключаемых библиотек. Если это не так, то все в порядке, пока вы не скомпонуете более одной версии библиотеки.

Я могу ошибаться, но из этого следует, что вы не можете использовать сторонние библиотеки, созданные на основе версии Boost, отличной от версии, определенной для вашего приложения. Ничто из того, что я читал или слышал, даже не намекает на то, что это ограничение применимо.

Если вы создаете собственное приложение, то я бы придерживался одной версии Boost для всего вашего кода. Это не обязательно должна быть та же версия, которая поставляется с RHEL.

Update

По сравнению с примером Артёма, сценарий, о котором я говорю, больше похож на следующий:

g++ -c -I/usr/include/boost_1.31 a.cpp
g++ -c -I/usr/include/boost_1.39 b.cpp
ar rcs liba.a a.o
ar rcs libb.a b.o
g++ -I/usr/include/boost_1.41 test.cpp liba.a libb.a -o test

... и теперь я понимаю суть Артёма, потому что это зависит от того, предпочитает ли компоновщик символы в одном библиотечном файле или нет.