$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] bcp update #2: namespace renaming
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2010-01-01 20:36:16
On Friday 01 January 2010 01:29:03 pm John Maddock wrote:
> >> > a) Does it rename macros as well? I mean if I have a library
> >> >   with defined BOOST_ASIO_ENABLE_FOO_BAR would it be renamed
> >> >   to NEWNAME_ASIO_ENABLE_FOO_BAR ?
> >>
> >> No not at present.  That's whay I said you can't #include two different
> >> Boost versions in the same TU.
> >>
> >> That's something I might look at later.
> >
> >This would be useful if full side-by-side header support is provided.  But
> >that is more involved than just renaming macros.  Also, I think what is in
> >now
> >is the more important feature.
> 
> I assume that for full side-by-side inclusioin in the same TU we would need
> to rename macros and also rename the boost/ directory (and hense all
> #includes).  Anything else?
I think that is what I did when I played with this, and that it will do the 
trick together with what you have in now.  I think what is also is a possible 
issue is:
#include SOME_MACRO
directives.  If these are all prefixed with BOOST_ they get a unique name, but 
they also need to expand to the correct include file path. 
The --namespace-alias option is great when not using boost in interfaces, but 
it is not useful in the side-by-side header case.  The method I had in mind to 
allow boost to be used as normally as possible was to allow replacing boost 
namespace with nested namespace mylib::boost.  In implementation files a "using 
mylib" directive would allow relatively normal use of boost and still have 
separate namespace protection for the interfaces. 
Supporting replacing boost with a nested namespace easily gets very tricky 
without enforcing stricter coding conventions with explicit end-namespace 
tagging in boost.  So I think allowing replacing boost with nested namespace 
is not worth it unless someone come up with a clever and simple way of making 
this work correctly. 
-- Bjørn