Несколько экземпляров Boost.Thread OK в приложении C ++? - PullRequest
Новая
       36

Несколько экземпляров Boost.Thread OK в приложении C ++?

2 голосов
/ 26 августа 2010

У меня есть приложение с подключаемой архитектурой, использующее Boost.Threads в качестве DLL (в частности, каркас Mac OS X). Я пытаюсь написать плагин, который также использует Boost.Threads и хотел бы статически ссылаться на библиотеку. Все строится нормально, но приложение быстро падает в моем плагине, глубоко внутри кода Boost.Threads. Связывание с версией DLL Boost.Threads, похоже, решает проблему, но я бы хотел, чтобы мой плагин был автономным.

Можно ли иметь два экземпляра Boost.Threads с такой настройкой (один как DLL, один статически связан в другой DLL)? Если так, что я мог бы пропустить, чтобы два экземпляра ладили?

1 Ответ

1 голос
/ 26 августа 2010

Однажды моя команда столкнулась с подобной проблемой. По причинам, которые я не буду упоминать в настоящее время, нам пришлось разработать систему, в которой использовались 2 разные версии Boost (потоки, система, файловая система).

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

Другими словами, мы заменили все ссылки на имя boost на пузыри внутри источников (или какое-то другое имя), а также внесли изменения в компиляцию, чтобы она строилась 1009 * libbubbles вместо libboost .

Эта процедура дала нам 2 набора библиотек, каждая из которых имела свои собственные двоичные файлы и заголовочные файлы.

Если вы посмотрите на исходный код нашего приложения, вы увидите что-то вроде: 

#include <bubbles/thread.hpp>
#include <boost/thread.hpp>

bubbles::thread* thread_1;
boost::thread* thread_2;

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

...