Question

I often find myself in a situation where I am facing multiple compilation/linker errors in a C++ project due to some bad design decisions (made by someone else 🙂 ) which lead to circular dependencies between C++ classes in different header files (can happen also in the same file). But fortunately(?) this doesn’t happen often enough for me to remember the solution to this problem for the next time it happens again.

So for the purposes of easy recall in the future I am going to post a representative problem and a solution along with it. Better solutions are of-course welcome.

---

• A.h

  class B; class A {     int _val;     B *_b; public:      A(int val)         :_val(val)     {     }      void SetB(B *b)     {         _b = b;         _b->Print(); // COMPILER ERROR: C2027: use of undefined type 'B'     }      void Print()     {         cout<<'Type:A val='<<_val<<endl;     } }; 

---

• B.h

  #include 'A.h' class B {     double _val;     A* _a; public:      B(double val)         :_val(val)     {     }      void SetA(A *a)     {         _a = a;         _a->Print();     }      void Print()     {         cout<<'Type:B val='<<_val<<endl;     } }; 

---

• main.cpp

  #include 'B.h' #include <iostream>  int main(int argc, char* argv[]) {     A a(10);     B b(3.14);     a.Print();     a.SetB(&b);     b.Print();     b.SetA(&a);     return 0; } 

Answer 1

The way to think about this is to ‘think like a compiler’.

Imagine you are writing a compiler. And you see code like this.

// file: A.h class A {   B _b; };  // file: B.h class B {   A _a; };  // file main.cc #include 'A.h' #include 'B.h' int main(...) {   A a; } 

When you are compiling the .cc file (remember that the .cc and not the .h is the unit of compilation), you need to allocate space for object A. So, well, how much space then? Enough to store B! What’s the size of B then? Enough to store A! Oops.

Clearly a circular reference that you must break.

You can break it by allowing the compiler to instead reserve as much space as it knows about upfront – pointers and references, for example, will always be 32 or 64 bits (depending on the architecture) and so if you replaced (either one) by a pointer or reference, things would be great. Let’s say we replace in A:

// file: A.h class A {   // both these are fine, so are various const versions of the same.   B& _b_ref;   B* _b_ptr; }; 

Now things are better. Somewhat. main() still says:

// file: main.cc #include 'A.h'  // <-- Houston, we have a problem 

#include, for all extents and purposes (if you take the preprocessor out) just copies the file into the .cc. So really, the .cc looks like:

// file: partially_pre_processed_main.cc class A {   B& _b_ref;   B* _b_ptr; }; #include 'B.h' int main (...) {   A a; } 

You can see why the compiler can’t deal with this – it has no idea what B is – it has never even seen the symbol before.

So let’s tell the compiler about B. This is known as a forward declaration, and is discussed further in this answer.

// main.cc class B; #include 'A.h' #include 'B.h' int main (...) {   A a; } 

This works. It is not great. But at this point you should have an understanding of the circular reference problem and what we did to ‘fix’ it, albeit the fix is bad.

The reason this fix is bad is because the next person to #include 'A.h' will have to declare B before they can use it and will get a terrible #include error. So let’s move the declaration into A.h itself.

// file: A.h class B; class A {   B* _b; // or any of the other variants. }; 

And in B.h, at this point, you can just #include 'A.h' directly.

// file: B.h #include 'A.h' class B {   // note that this is cool because the compiler knows by this time   // how much space A will need.   A _a;  } 

HTH.