Plusieurs instances Boost.Thread OK dans une application C++?

Question

J'ai une application avec une architecture de plug-in qui utilise Boost.Threads en tant que DLL (en particulier, un framework Mac OS X). J'essaye d'écrire un plug-in qui utilise Boost.Threads aussi, et qui voudrait lier statiquement dans la bibliothèque. Tout se construit bien mais l'application se bloque rapidement dans mon plug-in, profondément dans le code Boost.Threads. Lien vers la version DLL de Boost.Threads semble résoudre le problème, mais j'aimerais que mon plug-in soit autonome.

Est-il possible d'avoir deux instances de Boost.Threads avec une telle configuration (une en tant que DLL, une liée statiquement dans une autre DLL)? Si oui, que pourrais-je manquer pour que les deux instances s'entendent?

Answer 1

Une fois mon équipe confrontée à un problème similaire. Pour des raisons que je ne mentionnerai pas à ce moment, nous avons dû développer un système qui utilisait 2 versions différentes de Boost (threads, système, système de fichiers). L'idée que nous avons élaborée et exécutée était de saisir le code source des deux versions de Boost dont nous avions besoin, puis de modifier l'un d'entre eux pour changer les symboles et les noms de fonctions afin d'éviter les conflits de noms.

En d'autres termes, nous avons remplacé toutes les références au nom boost pour bulles à l'intérieur des sources (ou un autre nom) et aussi apporté des modifications à la compilation de sorte qu'il construirait libbubbles au lieu de libboost .

Cette procédure nous a donné 2 ensembles de bibliothèques, chacune avec ses propres fichiers binaires et en-têtes.

Si vous avez regardé le code source de notre application, vous verrez quelque chose comme:

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

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

J'imagine ici déjà fait face à quelques-uns des gars une situation similaire. Il y a probablement de meilleures alternatives à celle que j'ai suggérée ci-dessus.