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

From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-08-27 15:27:02

I wasn't talking about pre-declarations, I was talking about the fact that
the pure interface

class IFoo {
    virtual void bar () = 0;
};

hides implementation dependencies of class Foo : public IFoo {}; (to use
your Foo/bar example), as any interface to a "major concept" in a system
would. I also noted that in a lowlevel system, one full a minor concepts,
this may not be possible, so yes, there could (rarely) be co-dependent
headers.

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

Eric,

I told you: a quite contrived example. But to think that you can
*always* get away with hierarchical declaration dependencies might be a
bit too optimistic.

You cannot "class Foo;"-away out of everything ;-)

Regards,

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

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