C++ :: Circular Dependency In Template Arguments

Today I faced a problem where I had circular dependency in my template arguments. I was trying to make a class hierarchy similar to:

template<class BType>
class A_base {
public:
BType* getB();
};

[Code] .....

Basically I had objects that were of type A<B<A<B<...

Basically I have a tree like structure of heterogeneous types that must facilitate two-way interactions where A's can call B's and B's can call A's. This structure is useful in many contexts the difference is the methods A and B provide are different in each of these contexts. Instead of adding the getA and getB and all the other connectivity methods in every version of A and every version of B, I wanted to create a base class that managed this automatically.

Another piece of advice was break up your code so there is a forward-only and backwards-only dependent types. This is not a complete solution because the two cannot know about the other and this does not really facilitate arbitrary two-way communication (where A calls B then B calls A back). It also makes the code more complicated in that I have two sets of objects and interfaces.

So the solution was to make the template arguments specific to the things I wanted to be flexible. The connectivity interface of A_base and B_base should be constant. Hence that cannot be in the template parameter. It was merely the traits that I wanted to make flexible so... I came up with this solution:

#include <iostream>
template<class aTraitType,class bTraitType>
class A;
template<class aTraitType,class bTraitType>
class B;

[Code] ....

Now this compiles and works great. The problem is that aObj and bObj cannot call their opposite within a trait method because print() does not know anything about the connectivity. So the solution there was to make traits an abstract base class. Then magically everything works!

#include <iostream>
template<class aTraitType,class bTraitType>
class A_base;
template<class aTraitType,class bTraitType>
class B_base;

[Code] .....

So this outputs the following. Clearly there is two-way communication!

Class A is not connected to B
Class B is not connected to A
Class A at 0x7fff25d1aa10 reporting for duty
Class B at 0x7fff25d1aa00 reporting for duty
Class B at 0x7fff25d1aa00 reporting for duty
Class A at 0x7fff25d1aa10 reporting for duty
Class A at 0x7fff25d1aa10 reporting for duty
Class B at 0x7fff25d1aa00 reporting for duty