on Fri Sep 12 2008, Sohail Somani <sohail-AT-taggedtype.net> 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 http://www.boostpro.com