----- Original Message ----- From: "Eric Niebler" <eric@boostpro.com> To: <boost@lists.boost.org> Sent: Friday, October 23, 2009 6:56 PM Subject: Re: [boost] Boost policy for putting headers in boost/ Was: #3541 Support <boost/ptr_map.hpp>
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.
I agree with you. boost/<libname>.hpp don't needs to include all the public files. In addition to * typeof registration * serialization * phyton support I will add every 'decoration' to existing types, either from STL or from Boost. In Boost.Synchro I have files defining traits for thread mutex (from Boost.Thread) and for process mutex (from Boost.Interprocess). I as a user don't expect that boost/synchro.hpp will include all the traits files. IMO, it is up to the user to include the specific file. In Boost.Conversion, boost/conversion.hpp includes all the core files, but don' include every specific STD or Boost conversion. If some one needs to use conversions from chrono::duration to posix::time_duration he needs to include explicitly <boost/conversion/boost/chrono_duration_to_posix_time_duration.hpp> Best, Vicente