Re: [boost] Boost policy for putting headers in boost/ Was: #3541 Support <boost/ptr_map.hpp>

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 <eric-AT-boostpro.com> 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: http://www.boostcon.com
BoostPro Computing
http://www.boostpro.com