David Abrahams wrote:
on Fri Oct 23 2009, "troy d. straszheim" <troy-AT-resophonic.com> wrote:
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.
Fusion is very clean, but I have a problem remembering where to find various files. For that reason, I prefer the MPL's organization, where component xxx can always be used after #include <boost/mpl/xxx.hpp>. There is lower-level modularization, but for the most part the public interfaces are in boost/mpl and subdirectories are reserved for implementation details.
FWIW, we've solved that by having a flat include directory. It's the include/ dir you see up there. The directory contains all forwarding headers. For instance, see http://tinyurl.com/yj86r8v. You have: #include <boost/fusion/include/deref.hpp> in addition to the modular: #include <boost/fusion/iterator/deref.hpp> Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net http://www.facebook.com/djowel Meet me at BoostCon http://www.boostcon.com/home http://www.facebook.com/boostcon