Utilizando concurrentemente 2 versiones de boost

Question

Estoy usando RHEL 5.3, que se incluye con gcc 4.1.2 y boost 1.33. Hay algunas características que quiero, que faltan en el impulso 1.33. Por lo tanto, la idea era actualizar a la versión de impulso fresca 1.43.

1. ¿Es posible utilizar al mismo tiempo algunas bibliotecas de solo cabecera del impulso 1.43 y el resto de 1.33? Por ejemplo, quiero usar unorded_map, que falta en boost 1.33.

2. ¿Es posible utilizar simultáneamente bibliotecas de impulso binario de diferentes versiones?

Answer 1

Con un poco de suerte (y mucho cuidado) se puede probablemente salir con el uso completamente nuevas cabeceras. Para casi cualquier otra cosa, podría ponerse feo a toda prisa, porque algunas partes de Boost se refieren a otras partes, y si algún código v. 1.33 carga accidentalmente un encabezado v. 1.43 para su dependencia, hay una gran probabilidad de que vayas para obtener algunos problemas como resultado, lo mejor que puede esperar es una muerte rápida y limpia (bloqueo) en ese momento, pero puede empeorar fácilmente (por ejemplo, corrupción de datos silenciosos).

Answer 2

NO - nunca hagas esto!

Es imposible, es probable que tenga accidentes accidentales.

La única manera de lograr que se haga correctamente está usando el cambio de nombre de espacio de nombres: es decir, crear alternativas versión impulso colocado en diferentes espacio de nombres.

La última versión de BCP proporciona esta opción. Entonces usarás algo como boost_1_43 en lugar de boost. Pero será bastante transparente para ti. Pero aún debe saber que no puede usar dos versiones de boost en el mismo archivo cpp.

también echar un vistazo en esta discusión: Creating Library with backward compatible ABI that uses Boost

El guión gustado cambia el nombre de espacio de nombres, define e incluye lo que puede incluir en realidad dos versiones de impulso como

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

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

Boost BCP no lo permite .

Pero aún así hay que tener cuidado ya que algunas bibliotecas de símbolos exportar extern "C" sin impulso prefijo, impulsar :: hilo y boost :: API C de expresiones regulares (regexec, regcomp)

Editar

Como ejemplo de dicha emisión crear archivos siguientes:

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; 
} 

compilarlas:

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

que se puede esperar:

30 -10 

Pero obtendrá

30 30 

o

-10 -10 

Según el orden de enlace.

Así, utilizando dos versiones impulsar accidentalmente usted puede tomar símbolos de otros impulso y chocar mismo que en el programa de este símbolo int add<int>(int,int) se resolvió mismo símbolo, incluso si se coloca en diferentes unidades de compilación.

Answer 3

actualización

creo que mi respuesta original hace demasiadas suposiciones acerca de las capacidades del enlazador y las opciones utilizadas, y bien puede estar completamente equivocado. Normalmente lo eliminaría, pero hay algunos puntos en la discusión que no están incluidos en las otras respuestas.

Encuentro las implicaciones de lo que se necesita para construir una biblioteca de código cerrado de buen comportamiento simplemente increíble.

respuesta original

Como siempre y cuando utilice una versión por paso de compilación, entonces debería estar bien porque el código se genera en tiempo de compilación y los símbolos generados debe limitarse al ámbito del paso de compilación.

Supongo que Boost sigue siendo una biblioteca de plantillas sin bibliotecas enlazables. Si no es así, entonces todavía está bien, siempre y cuando no enlace con más de una versión de la biblioteca.

Podría estar equivocado en esto, pero la implicación sería que no se puede usar una biblioteca de terceros creada con una versión diferente de Boost a partir de la versión definida para su aplicación. Nada de lo que he leído o escuchado, incluso insinúa que esta limitación se aplica.

Si está creando su propia aplicación, me quedaré con una versión de Boost para todo su código. No tiene que ser la misma versión que proporciona RHEL.

actualización

En comparación con el ejemplo de Artyom, el escenario que estoy hablando es de la misma familia:

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 

... y ahora entiendo el punto de Artyom, porque depende de si el enlazador prefiere símbolos en el mismo archivo de biblioteca o no.