Boost logo

Boost :

Subject: Re: [boost] [Config] Multiple versions of Boost
From: David Abrahams (dave_at_[hidden])
Date: 2008-09-13 22:01:16

on Fri Sep 12 2008, Sohail Somani <> wrote:

> Anyway, I thought it might be a good idea to do the same on the larger
> code base so I attempted to do the same. Failed miserably. The problem
> is that some of the Boost code contains some variant of:
> #if defined(SOME_CONDITION)
> # define HEADER <boost/some/header.hpp>
> #else
> # define HEADER <boost/some/other/header.hpp>
> #endif
> #include HEADER
> Reading 16.2/4, it seems that the behaviour in this case is not defined.
> Specifically, an implementation may or may not replace the boost text
> with boost_133_1_provider. This is true whether or not you have
> <boost/some/header.hpp> or "boost/some/header.hpp". So on one compiler,
> you may end up with:
> #include <boost_133_1_provider/some/header.hpp>
> And on another:
> #include <boost/some/header.hpp>
> My immediate problem solved, I made do. However, the problem still bugs
> me. There should be /some/ way to do this. So...
> 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?
> I know it isn't aesthetically pleasing but it might have made this a bit
> easier.

This is a longstanding issue for C++ libraries in general, and for Boost
in particular. I know for a fact there are several companies out there
that struggle with it.

We already do something like the above for Boost.Signals because of
potential conflicts with Qt. I think it's worth taking a look at how
Boost.TR1 does its business, and we should probably also be thinking
about how to leverage namespace aliases.

I don't know if anyone at Boost has taken the time to solve the problem
in general, so I'm really glad to see the issue raised.

Dave Abrahams
BoostPro Computing

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