[boost] Re: #ifndef paradigm

From: Leo Landa (leo_at_[hidden])
Date: 2002-08-29 12:04:19

Good day to everyone.

First, even if there are header files in a system that include each
other through any kind of circular dependency, if each of these
headers is properly wrapped, then there still is only one place where
the preprocessor pastes the actual body of each file. Doesn't it
mean that circular dependency is unachievable?

Imagine, for example, two files:

-------------------------
// a.hpp
//
#include "b.hpp"

// code that needs b.hpp
-------------------------
// b.hpp
//
#include "a.hpp"

// code that needs a.hpp
-------------------------

If the code in a.hpp and b.hpp actually _needs_ the included header,
then no matter how you include those two files in some translatable
module, it's still either A first, B second, or vice versa. In my
experience circular dependencies always have to be broken by
separating the interfaces that are sufficient to other code and have
less dependencies of their own, i.e. following some design pattern.

So, whatever the reasoning, I don't see how a circular-dependent
header file system can pass preprocessor and compile.

And, secondly, I do agree with the statement that if a circular
dependency is encountered, it is better to have a "symbol undefined"
than a preprocessor confusion, so the '#define' part has to be on top
of the file, guarding any self-inclusions a header may cause through
other headers. Even an example of an erroneous header including itself
should be sufficient, IMHO, to realize the need for pre-defining the
macro, as opposed to post-defining it, since a self-including header
would cause preprocessor problems if the guarding macro is defined at
the end of the file.

Leo.