Boost logo

Boost :

Subject: Re: [boost] [Config] Multiple versions of Boost
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2008-09-14 03:13:31

Sohail Somani skrev:
> Steven Watanabe wrote:
>> Sohail Somani wrote:
>>> Sohail Somani wrote:
>>> [snip]
>>>> What if Boost.Config did something like:
>>>> #if !defined(BOOST)
>>>> # define BOOST boost
>>>> #endif
>>>> And we replace all uses of the boost namespace with BOOST?
>>>> Would such a patch against trunk be acceptable? What are the problems?
>> In order to make this work we need to make sure that
>> there is a namespace alias where appropriate:
>> #if !defined(BOOST_NAMESPACE)
>> #define BOOST_NAMESPACE boost
>> #endif
>> #define BOOST_NAMESPACE_boost 0
>> namespace BOOST_NAMESPACE {}
>> namespace boost = BOOST_NAMESPACE;
>> #endif
>> #undef BOOST_NAMESPACE_boost
> Indeed, you are right. Clever too :-)
> There is one obvious problem I see with the -DBOOST_NAMESPACE=foo
> approach: there is no way to include two versions of Boost within the
> same translation unit. Unfortunately, I don't think there would be any
> acceptable way to do this. Though I'm sure you will come back with a way
> to do it!

Even if you solve this for the namespace, you can not safely have
side-by-side headers from two boost versions in the same translation
unit. You still have the issues of include paths and all the other
BOOST_ preprocessor symbol definitions. There are probably other issues
as well that is off my radar screen. Namespace variations only solve
part of the issues, but if you don't mix boost versions in the same
translation units you may be Ok. However, if you need to use boost
types in interfaces used across boost versions -- then you need a
different solution. The types need adapters, or they need to be aliased
and binary compatible.

> By the way, I've received a message on IRC telling me that Xalan and
> Xerces do something very similar so it wouldn't be totally unprecedented

I was never pleased with the limitation of the Xerces method. So, some
years ago I did some testing with a different approach to solve this.
I used a patched version of the bcp tool to manipulate names of
preprocessor symbol names, include paths, and namespace names in a copy
boost (or of selected boost libriaries) copied with bcp. I did some
promising tests and posted a patch to the list. I think Eric Niebler
reported some success in using this approach.

Bjørn Roald

Boost list run by bdawes at, gregod at, cpdaniel at, john at