Stewart, Robert wrote:
Olaf van der Spek wrote:
On Fri, Oct 23, 2009 at 3:18 PM, Frank Mori Hess <frank.hess@nist.gov> 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