Boost logo

Boost :

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at