How can I wrap BOOST in a separate namespace?
-
02-07-2019 - |
Question
I'm looking to have two versions of BOOST compiled into a project at the same time. Ideally they should be usable along these lines:
boost_1_36_0::boost::shared_ptr<SomeClass> someClass = new SomeClass();
boost_1_35_0::boost::regex expression("[0-9]", boost_1_35_0::boost::regex_constants::basic);
Solution
I read (well scanned) through the development list discussion. There's no easy solution. To sum up:
Wrapping header files in a namespace declaration
namespace boost_1_36_0 { #include <boost_1_36_0/boost/regex.hpp> } namespace boost_1_35_0 { #include <boost_1_35_0/boost/shared_ptr.hpp> }
- Requires modifying source files
- Doesn't allow for both versions to be included in the same translation unit, due to the fact that macros do not respect namespaces.
Defining boost before including headers
#define boost boost_1_36_0 #include <boost_1_36_0/boost/regex.hpp> #undef boost #define boost boost_1_35_0 #include <boost_1_35_0/boost/shared_ptr.hpp> #undef boost
- Source files can simply be compiled with
-Dboost=boost_1_36_0
- Still doesn't address macro conflicts in a single translation unit.
Some internal header file inclusions may be messed up, since this sort of thing does happen.
#if defined(SOME_CONDITION) # define HEADER <boost/some/header.hpp> #else # define HEADER <boost/some/other/header.hpp> #endif
But it may be easy enough to work around those cases.
- Source files can simply be compiled with
- Modifying the entire boost library to replace
namespace boost {..}
withnamespace boost_1_36_0 {...}
and then providing a namespace alias. Replace allBOOST_XYZ
macros and their uses withBOOST_1_36_0_XYZ
macros.- This would likely work if you were willing to put into the effort.
OTHER TIPS
Using bcp can install boost library to a specific location and can replace all 'namespace boost' in their code to a custom alias. Assuming our alias is 'boost_1_36_0' all 'namespace boost' code blocks will start with 'boost_1_36_0'. Something like
bcp --namespace=boost_1_36_0 --namespace-alias shared_ptr regex /path/to/install
, but check the documentation in the link yourself because I'm not sure if it is legal syntaxis.
@Josh:
While I agree with the shivering, I still believe this is the better course of action. Otherwise, linking troubles are a certainty. I've had the situation before where I had to hack the compiled libraries using objcopy
to avoid definition conflicts. It was a nightmare for platform interoperability reasons because the name mangling works very differently even in different versions of the same compilers (in my case, GCC).
You'll have a world of trouble linking because the mangled names will be different. And yes, I see you knew that, but it seems like it will be trouble all around.