Subject: Re: [boost] Boost policy for putting headers in boost/ Was: #3541Support <boost/ptr_map.hpp>
From: David Abrahams (dave_at_[hidden])
Date: 2009-10-29 16:45:02
on Thu Oct 29 2009, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
>> So +1 for a mpl/type_traits style of organization from me too,
> For the record, I am not against this. It is in IMO the logical
> choice for most libraries. What I am saying is that for bigger
> libraries, it is logical to organize in modules.
As I've been saying, that practice doesn't have to be incompatible with
the mpl/type_traits style of organization
> When you have
> modules then that flat organization will start to break. E.g.
> if "x.hpp" is a header of module "foo" of library "lib", then,
> the logical structure is:
> Notice that the header for module has the correct header:
I don't even see x.hpp there.
> However, components of foo (a.hpp) cannot be hoisted outside
> its module. Thus, in this case, this is wrong:
> Your example is a prime symptom of the breakage:
> "That said there may be a case to be made for splitting
> into sub-libraries - we did that with Boost.Math to avoid
> confusion between a distribution called X and a special
> function called X.".
> When a library is modular, clashes are typical, e.g.:
> So, now you have two headers "a.hpp" under different modules,
> sharing the same name. It then becomes obvious why this is
There are several ways to deal with that. Aside from renaming one of
the submodules, you could also have boost/lib/a.hpp #include
boost/lib/foo/a.hpp and boost/lib/bar/a.hpp. It's not aesthetically
ideal, but it's consistent and easier for users. Those who want to be
more selective can still always reach for boost/lib/bar/a.hpp, for
Have you actually got a name clash situation like that one, BTW?
-- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk