Subject: Re: [boost] Boost policy for putting headers in boost/ Was: #3541 Support <boost/ptr_map.hpp>
From: Eric Niebler (eric_at_[hidden])
Date: 2009-10-23 11:50:08
troy d. straszheim wrote:
> Stewart, Robert wrote:
>> Redundancy occurs with boost/ptr_container/ptr_container.hpp, not
>> boost/ptr_container/all.hpp. Using all.hpp means that all libraries
>> use the same header name and the library name isn't repeated.
>> "all.hpp" is as short as you can get and still mean "give me
I don't like the idea of a boost/<lib>/all.hpp header. Does that really
drag in everything? Debug utilities? Boost.Python integration?
Boost.Serialization support? Typeof registrations? Support for Zlib and
Bzip compression that will require downloading, configuring, building,
and linking to additional external libraries? I find all.hpp headers
> My inclination is to standardize on existing practice rather than
> inventing a standard. So I'd suggest that at any level of the
> directory tree,
> File D.hpp is either standalone (if no directory D exists) or includes
> all files in subdirectory D. This way your abstraction gets you more
> than just information on how to negotiate the toplevel boost/
> directories, and it matches current practice fairly well. Fusion has
> always struck me as quite clean:
> % ls boost/fusion
> adapted/ container.hpp iterator.hpp support/ view.hpp
> adapted.hpp functional/ mpl/ support.hpp
> algorithm/ functional.hpp mpl.hpp tuple/
> algorithm.hpp include/ sequence/ tuple.hpp
> container/ iterator/ sequence.hpp view/
> the files D.hpp could be automatically generated and/or checked. There
> are implications for 'modularization'... note that this supports
> single-header projects as well as projects with subdirectories.
+1. Thanks, Troy. I agree completely.
-- Eric Niebler BoostPro Computing http://www.boostpro.com