on Fri Oct 23 2009, Eric Niebler <eric-AT-boostpro.com> wrote:
Scott McMurray wrote:
2009/10/23 Frank Mori Hess <frank.hess@nist.gov>:
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