Boost logo

Boost :

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    

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk