RE: [boost] Re: #ifndef paradigm

From: David Bergman (davidb_at_[hidden])
Date: 2002-08-27 14:46:41

Eric,

It does happen, especially in more complex ("complex" as in "the problem
domain being complex", not as in "an overly complicated solution to a
simple problem") systems, that two (or more) concepts rely on eachother
(in a non-hierarchical way).

Since (the declaration of, at least) most advanced concepts usually
reside in their own header file, there will be what you call
co-dependent headers...

Note that it might not actually be co-dependencies in the binary sense,
but it could be a more intricate recursive system, where  A includes B,
B includes C, and C, in turn, includes A...

As a standard example, consider a system implementing a map, with roads,
cities and such.

You would probably have the following important classes (or templates,
since we are in Boost-land ;-) : Location, RoadSegment, Road

It is likely that those concepts are important enough to grant them
individual header files, so we would have location.hpp,
road_segment.hpp, road.hpp and path.hpp. It is also likely that a Road
connects two Locations (even though they might not be cities or
towns..), and each Location have a lot of RoadSegments leading in and
out from it, and each RoadSegment belong to one Road.

Thus, we would have "location.hpp" including "road_segment.hpp" and
"road.hpp" including "location.hpp", and "road_segment.hpp" including
"road.hpp".

A bit contrived example, admittedly. And, not all such problems need to
deal with graphs.

What is important to understand is that

1. Complex systems and their solutions consist of various concepts
depending on eachother
2. It is not certain that the dependency graph induced by (1) is
hierarchical
3. It is beneficial to place "powerful" concepts in its own header file,
to improve cohesion

These three statements together lead to systems with "co-dependent"
headers.

/David

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Eric Woodruff
Sent: Tuesday, August 27, 2002 3:26 PM
To: boost_at_[hidden]
Subject: [boost] Re: #ifndef paradigm

True, but I fail to see how co-dependent headers is ever the correct way
to implement something.

----- Original Message -----
From: David Bergman
Newsgroups: gmane.comp.lib.boost.devel
Sent: Tuesday, 2002:August:27 15:15
Subject: RE: #ifndef paradigm

Eric,

What about a mutually recursive system, w.r.t. prepocessor file
inclusion? I.e, what about

code1.hpp:

#include "code2.hpp"

class code1 {
public:
code1(code2* other) {}
private:
int var;
};

code2.hpp:

#include "code1.hpp"

class code2 {
public:
code2() { };
private:
int var;
};

???

You need to #define the token before entering this mutually recursive
system...

/David

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Eric Woodruff
Sent: Tuesday, August 27, 2002 2:59 PM
To: boost
Subject: [boost] #ifndef paradigm

Often, when one wants to make sure a header is included only once, s/he
uses the paradigm:

#ifndef HEADER_NAME_H__
#define HEADER_NAME_H__

// code here...

#endif // HEADER_NAME_H__ -- this comment is to make it clear what the
endif is for

It is better to remove the duality of the comment at the end, by
switching to this paradigm:

#ifndef HEADER_NAME_H__

// code here...

#define HEADER_NAME_H__
#endif

When maintiaining a file -- renaming it -- with the comment, one has to
make sure the comment is also updated. This alternative removes the
comment because it is superfluous, and the compiler will help you if you
forget to change the #define at the end.

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost