RE: [boost] Re: Re: #ifndef paradigm

From: David Bergman (davidb_at_[hidden])
Date: 2002-08-27 15:26:24

A problem we have with C++ is that we cannot separate interface and
implementation as we would want, since a huge portion of the
implementation (i.e., the instance variables and general object layout)
is exposed through the declaration...

I am totally in favor of a hierarchical declaration structure, but the
mutually dependent structure (which I believe we all realize is needed
in some complex systems) along with the "inline" tendencies of modern
C++ programming in general, and Boost, in particular, does make that
goal quite hard to achieve.

If we would have access to the operations (i.e., the interface) without
including the object layout (i.e., the header file) then we could
achieve a pure hierarchical file inclusion graph, while retaining the
power of dynamic OO-oriented problem-solving.

/David 

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

In any example, so complex as that, certainly the interface of Location
would not expose the fact that its implementation depends on road
segments. Any pure OO concept generally has to have the separation
between interface and implementation.

Co-dependent headers means you have a bad design. Period. (I'm not
saying that there are NEVER situations where one might have codependent
in lowlevel headers of some framework, but it is rare, and a comment is
necessary to explain why that lowlevel header had to violate idealism.)

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

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

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

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