Re: [boost] Coding guidelines - comments

From: Toon Knapen (toon_at_[hidden])
Date: 2001-07-04 17:05:32

> In my experience, #include<> is best reserved for system headers, which are
> nothing like boost headers because they tend to be stable (not upgraded once
> or twice a month) and common-place (at least, installed by default for a
> given platform).
> 
> I prefer to keep a version of boost that I know works with my code within a
> project's source tree. I'd very much like to be able to refer to that
> location with relative paths, using #include "../libs/boost/etc.hpp".
> Instead, I have to mess around with my project or compiler's environment
> variables and command line options.
> 
> Since the locations used with #include <> are a subset of those matched by
> #include "" (for a more-conforming compiler), it's not clear that using the
> bracket notation has any advantage for Boost.
> 

In big projects one needs to control the dependencies inbetween
components very strictly. Whenever you allow everyone to use any method
to get to any other component's include file you end up with spagetti in
no time. Therefor I prefer programmers to use an include like
#include <modulename/classname.hpp>
(The directory name is there because I can guarantee that module-names
are unique). So in the makefiles (sorry Jamfile's ;-) of the components
that want to perform the above include the path to this component needs
to be specified. This makes the programmer think twice about if he's
allowed to do the include. Next you can easily develop some system to
visualise the dependencies between the different components based on
parsing the makefiles. This is the only way (to me) to do and sustain
real Component Based Development.
Allowing whatever include makes you end up with typical fortran
situations. And believe me ...

t