«

Hi,
I have what feels like a really stupid question and I'm sorry if it is
asked a lot.
Imagine I have two classes cShip and cPassenger. They each have a
definition in their own header cShip.h and cPassenger.h and their
implementation in cShip.cpp and cPassenger.cpp. Now here is the header
file for each:

#ifndef CSHIP_H
#define CSHIP_H

class cShip
{
...
cPassenger * owner;
...
};

#endif

------Next file

#ifndef CPASSENGER_H
#define CPASSENGER_H

class cPassenger
{
...
cShip * current_vehicle;
...
};

#endif

Now the problem I have is how to join these files together with includes
such that they compile. (The idea here is that a ship always has an
owner but that a passenger can be in a ship that they don't own).

Sorry if this is a really mundane question,
Connell

Connell Gauld wrote:
> I have what feels like a really stupid question and I'm sorry if it is
> asked a lot.
> [...circular dependency question snipped...]

Don't be sorry, just read the FAQ before posting.
You can find it here: http://www.parashift.com/c++-faq-lite/

V

An owner may not be a passenger, so it may make more sense to have a
separate cOwner and cPassenger class. But to get circular references to
compile, you can simply use a forward declaration:

#ifndef CSHIP_H
#define CSHIP_H

class cPassenger;

class cShip
{
...
cPassenger * owner;
...
};

#endif

#ifndef CPASSENGER_H
#define CPASSENGER_H

class cShip;

class cPassenger
{
...
cShip * current_vehicle;
...
};

#endif

This could cause you some problems though if any part of the class
declaration relies on deeper knowledge about the forward declared
class. A forward declaration only gives you the name of the class, not
any details about data members or member functions.

* Connell Gauld:
>
> I have what feels like a really stupid question and I'm sorry if it is
> asked a lot.

Not at all, it's a good question.

There are a host of very _similar_ questions that all involve
circular dependencies.

In your case the usual solution, forward declarations, is _not_
appropriate.


> Imagine I have two classes cShip and cPassenger. They each have a
> definition in their own header cShip.h and cPassenger.h and their
> implementation in cShip.cpp and cPassenger.cpp. Now here is the header
> file for each:
>
> #ifndef CSHIP_H
> #define CSHIP_H
>
> class cShip
> {
> ...
> cPassenger * owner;
> ...
> };
>
> #endif
>
> ------Next file
>
> #ifndef CPASSENGER_H
> #define CPASSENGER_H
>
> class cPassenger
> {
> ...
> cShip * current_vehicle;
> ...
> };
>
> #endif
>
> Now the problem I have is how to join these files together with includes
> such that they compile. (The idea here is that a ship always has an
> owner but that a passenger can be in a ship that they don't own).

What you have is a design problem, not (just) a technical circular
dependency problem.

Let the owner of a ship be a cPerson.

Let cPassenger be a class derived from cPerson, and voilà, problem solved;
you then have

cShip depends on CPerson
cPassenger depends on cShip and cPerson

Later on you might consider the case where the owner might be a person _or_
a corporation.

With that twist it gets more interesting...

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Connell Gauld wrote:
....
>
> Now the problem I have is how to join these files together with includes
> such that they compile. (The idea here is that a ship always has an
> owner but that a passenger can be in a ship that they don't own).

Ownership (no pun intended) is somthing you need to manage with the
code, not the declaration (if you were using smart pointers you could do
this otherwise).

As for the declaration issues - you need to forward declare the class
you're referring to - see below.

#ifndef CSHIP_H
#define CSHIP_H

class cPassenger; // declare a class cPassenger

class cShip
{
...
cPassenger * owner;
...
};

#endif

------Next file

#ifndef CPASSENGER_H
#define CPASSENGER_H

class cShip; // declare a class cShip

class cPassenger
{
...
cShip * current_vehicle;
...
};

Alf P. Steinbach wrote:
> * Connell Gauld:
>
>>I have what feels like a really stupid question and I'm sorry if it is
>>asked a lot.
>
>
> Not at all, it's a good question.
>
> There are a host of very _similar_ questions that all involve
> circular dependencies.
>
> In your case the usual solution, forward declarations, is _not_
> appropriate.

Huh?

> [...]

* Victor Bazarov:
> Alf P. Steinbach wrote:
> > * Connell Gauld:
> >
> >>I have what feels like a really stupid question and I'm sorry if it is
> >>asked a lot.
> >
> >
> > Not at all, it's a good question.
> >
> > There are a host of very _similar_ questions that all involve
> > circular dependencies.
> >
> > In your case the usual solution, forward declarations, is _not_
> > appropriate.
>
> Huh?

See the rest of that message, but, since you ask, some background:

It's generally not a good idea to solve design problems by applying
technical kludges to the _symptoms_, whether the kludges be forward
declarations, 'friend', 'void*', C-style casts, or whatever.

Such "solutions" come back to haunt you, and also they typically
yield more complex, non-maintainable code in the first place, because you
missed out on sensible abstraction opportunities (which simplify things).

Cheers,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Alf P. Steinbach wrote:
> * Victor Bazarov:
>
>>Alf P. Steinbach wrote:
>>
>>>* Connell Gauld:
>>>
>>>
>>>>I have what feels like a really stupid question and I'm sorry if it is
>>>>asked a lot.
>>>
>>>
>>>Not at all, it's a good question.
>>>
>>>There are a host of very _similar_ questions that all involve
>>>circular dependencies.
>>>
>>>In your case the usual solution, forward declarations, is _not_
>>>appropriate.
>>
>>Huh?
>
>
> See the rest of that message, but, since you ask, some background:
>
> It's generally not a good idea to solve design problems by applying
> technical kludges to the _symptoms_, whether the kludges be forward
> declarations, 'friend', 'void*', C-style casts, or whatever.

What makes you think there *is* a design problem there? The need to use
a "technical kludge" is *not* necessarily an indication of a design flaw.
Just like 'friend' and 'void*' and 'dynamic_cast', forward declarations
are there to be used to _accommodate_ certain design decisions, not to be
avoided at all costs.

> Such "solutions" come back to haunt you, and also they typically
> yield more complex, non-maintainable code in the first place, because you
> missed out on sensible abstraction opportunities (which simplify things).

No! What you did suggest was, in fact, a kludge. If two classes do
depend on each other, the model in question is _fine_, it is perfectly
OK to have a pointer to A in B and a pointer to B in A. And, yes, the
only clean way to resolve the reference "problems" is in the FAQ.

Introducing a non-existent design elements just to avoid using some
language features you might be finding "inappropriate" for whatever
reason, is definitely a mistake.

Design comes first, language-specific implementation comes second.

V

* Victor Bazarov:
>
> Design comes first, language-specific implementation comes second.

Right.

I gather all that about likes and dislikes that I snipped abvoe, a
completely unwarranted speculation about my thinking (I don't think that
way), was really about your earlier posting, posted almost at the same time
as mine, where you failed to notice it was a design problem...

Check the design again, then tell me it's reasonable that a boat's owner
must be a passenger.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

"Alf P. Steinbach" wrote:
>
[snip]
>
> Let the owner of a ship be a cPerson.

OK.
(Side note: Every cPerson owns a ship? I don't think so.
So I take it for granted that you wanted to have a cPerson class
and derive a COwner class from it)

>
> Let cPassenger be a class derived from cPerson, and voilà, problem solved;
> you then have
>
> cShip depends on CPerson
> cPassenger depends on cShip and cPerson
>
> Later on you might consider the case where the owner might be a person _or_
> a corporation.

Well. Eventually he will come to the point where his ships actually transport
cPassenger-s.

So this will end up in

cShip depends on COwner and cPassenger
cOwner depends on cShip
cPassenger depends on cShip

Same problem. The design is better, but the circular dependency stays
the same.

--
Karl Heinz Buchegger