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
>> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk