Question

Here is my code & requirements:

I have 2 classes A & B, they don’t have any inheritance. I used one method of class A to call one method of Class B. Then the class B’s method should callback one of the class A’s method to execute a callback.

Part of code:

classA.h:

#include "classB.h"

class classA
{
  public:
  classA();
  classB *pClassB;
  void callClassB();
  void callBack();
};

classA.cpp:

#include "classA.h"
classA::classA()
{
  pClassB = new classB();
}

void classA::callBack()
{
  return;
}

void classA::callClassB()
{
  pClassB->callFunction();
}

classB.h:

class classB
{
  public:
  classB();
  void callFunction();
}

classB.cpp:

#include "classB.h"
classB::classB()
{
}

void classB::callFunction()
{
   // I should call classA's callback here!
}

The problem is, I can’t include classA.h in classB.h because it will cause some compile issue elsewhere(I can’t solve that). I can’t make classB as classA’s subclass(if I can, I just have to do classA::callBack() instead). So is there a solution to this situation?

UPDATE：that’s what I’ve modified:

class classB
{
  public:
  classB(classA& pCallBack);
  void callFunction();
  void (classA::*m_callback)(void);
};

classA::classA()
{
  pClassB = new classB(*this);
}

classB::classB(classA& pCallBack)
{
  m_callback = pCallBack;
}

I tried to save the pointer, but also failed. It says “assigning from incompatible type”… what’s wrong with it??

Answer 1

Indeed, reciprocally including both headers in each other is a circular dependency, which the compiler can’t resolve. There are different ways to solve this, three of which I describe below.

Using forward declarations

The most straightforward way to break the circular dependency is to use forward declarations. A forward declaration only tells the compiler that a given name denotes a class. That is enough if you only use pointers/references to that type, because in these cases the compiler doesn’t need the full definition of that type. So you can change classA.h like this:

class classB;

class classA
{
  public:
  classA();
  classB *pClassB;
  void callClassB();
  void callBack();
};

This way the header is not dependent on classB.h anymore. Of course, you need now to #include that header in classA.cpp:

#include "classA.h"
#include "classB.h"
...

Introducing an interface

Another way is to introduce a super interface (or in C++, an abstract superclass) to classA, and let classB see only that:

callback.h:

class callback
{
  public:
  virtual void callBack() = 0;
};

classA.h:

#include "callback.h"

class classB;

class classA : public callback
{
  public:
  classA();
  classB *pClassB;
  void callClassB();
  void callBack();
};

classB.h:

#include "callback.h"

class classB
{
  callback& m_a;
public:
  classB(callback& a);
  void callFunction();
};

classB.cpp:

#include "classB.h"

classB::classB(callback& a) : m_a(a) {}

classB::callFunction()
{
  m_a.callBack();
}

As you see, this way classB does not depend on classA in any way. This in fact allows you to later replace classA with any other implementation of callback, without touching classB‘s definition.

Introducing a function pointer

Yet another possibility would be to define / use a function pointer type matching that of classA::callBack(), and pass only the pointer to the callback function to classB, rather than the whole classA object. Although, this only works seamlessly with static methods – for nonstatic functions you still need a classA object for the call.

Update

You are mixing two approaches (passing an object of classA or passing only a function pointer) in your modified code. Better stick with one at a time. The first approach is simpler, this is how it would look like:

class classA;

class classB
{
  classA& m_a;
public:
  classB(classA& a);
  void callFunction();
};

classB::classB(classA& a) : m_a(a) {}

classB::callFunction()
{
  m_a.callBack();
}

The function pointer approach would be more complex for nonstatic member functions, because you needed both the function pointer and an object on which to invoke it. An alternative take on it is shown in @Tadeusz’s answer.