Boost logo

Boost :

Subject: Re: [boost] Boost policy for putting headers in boost/ Was: #3541 Support <boost/ptr_map.hpp>
From: David Abrahams (dave_at_[hidden])
Date: 2009-10-26 07:51:57

on Fri Oct 23 2009, Eric Niebler <> wrote:

> Scott McMurray wrote:
>> 2009/10/23 Frank Mori Hess <frank.hess_at_[hidden]>:
>>> How do these objections to boost/D/all.hpp not also apply when it is called
>>> boost/D.hpp?
>> Presumably the argument is that if "all" doesn't include every single
>> header in the library, then it's misleading, whereas D.hpp can be the
>> "author's cut" of functionality.
> Yes. That's the case for proto.hpp. It includes everything except
> debug utilities and typeof registrations. If I were to add
> serialization or python support, that would also be left out. A
> proto/all.hpp would either be inefficient and largely useless or else
> misleading. I imagine the same is true for most libraries.

It's not true for any of my libraries. I think boost/D/all.hpp is a
fine idea for those libraries where having a single #include pull in
100% of all headers makes sense. Other libraries shouldn't use it, IMO.
They can create their own appropriately-named aggregates with different
subsets. It'd be nice --- though not necessary --- to come up with a
standard name for the kind of aggregate you'd use for proto.hpp.

My intuition tells me that Boost's future health depends on improved
modularization, and that getting (non-deprecated) headers out of boost/,
so the _official_ interfaces live in library-specific subdirectories, is
key to that modularization.

Dave Abrahams           Meet me at BoostCon:
BoostPro Computing

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