Say I have a class foo with an object of class bar as a member
class foo
{
bar m_bar;
};
Now suppose bar needs to keep track of the foo
You need to move all of the member access out of the header, and into your source files.
This way, you can forward declare your classes in the header, and define them in foo:
// foo.h
class bar;
class foo {
bar * m_pbar;
}
// bar.h
class foo;
class bar {
foo * parent;
}
That will allow you to work - you just can't put definitions that require member information into your header - move it to the .cpp file. The .cpp files can include both foo.h and bar.h:
// Foo.cpp
#include "foo.h"
#Include "bar.h"
void foo::some_method() {
this->m_pbar->do_something(); // Legal, now, since both headers have been included
}
I suppose one way is to make abstract interface classes with no members. Then subclass foo and bar from those interface classes.
e.g.:
class FooInterface
{
// methods here
}
class BarInterface
{
// methods here
}
class Foo : public FooInterface
{
BarInterface *pBar;
}
class Bar : public BarInterface
{
FooInterface *pFoo;
}
This breaks the cycle of dependencies (unless the interfaces themselves depend on each other, and if that's the case then they should probably be declared in the same file)
As far as I know, the only real way of doing this is using pointers since they don't require class definition until the translation unit (.cpp) in which case both classes will have been defined properly.
In your example, foo
depends on bar
(because it contains an actual bar
object), but bar
does not depend on foo
(since it only contains a foo *
). Now bar
does depend on on foo
being a type name, so bar.h needs a forward declaration of the name: class foo;
. foo
depends on bar
, so foo.h should contain #include "bar.h"
You can't have classes that directly depend on each other in C++; it simply doesn't work. You need to decouple the classes such that one only depends on the other existing, like in your example. The only things that create a direct dependence are using a class as a base class or as a field; any other use just creates an indirect dependence, which is generally not a problem.