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: troy d. straszheim (troy_at_[hidden])
Date: 2009-10-23 10:18:45

Stewart, Robert wrote:
> Olaf van der Spek wrote:
>> On Fri, Oct 23, 2009 at 3:18 PM, Frank Mori Hess 
>> <frank.hess_at_[hidden]> wrote:
>>>> Would a boost/ptr_container.hpp that includes all containers
>>>> make sense? I don't think every container needs it's own header
>>>> file.
>>> One suggestion I liked that came up earlier was using all.hpp,
>>> for example boost/ptr_container/all.hpp.
>> All seems a bit redundant, the standard is just <lib>.hpp AFAIK.
> 
> 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
> everything."
> 

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.

-t