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 everything."
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 generally useless.
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