Is this now your "real" code, or is your "real" code something third again?
>
I don't think anyone in this group is real happy chasing phantoms when
trying to help someone.
If you want help then post real code, not made-up examples that you
think resemble real code.
I'm sorry about that, I do realise how annoying it is to offer solutions
and then discover the wrong question was asked, but it was an attempt to
offer clear, easy to read code to make it quicker for everyone to
comprehend - I'm sure everyone here is very busy, so I try to save them
time by making my example code concise.
In this case I accidentally over-simplified, so I apologise for that. I
am not an expert, after all.
This is of course not my "real" code, as the particular code in question
is over 600 lines and won't compile unless there are another dozen or so
files of similar length - I'm sure nobody here has the desire to read
through that!
The latest example code I posted is, to the best of my knowledge, an
accurate representation of the problem. A function template in two
non-template classes access each other's class. The only difference in
my "real" code is that the reference is in the form of a function call
on a parameter, rather than a return value, however as far as I'm aware
that doesn't make a difference in this particular case.
>struct A;
#include "b.hpp"
This is extremely bad. "b.hpp" should be self-contained. It should not
require client code to make any forward declarations before the #include.
"b.hpp" *is* self contained. You will notice that it pulls in a.hpp (to
declare struct A) if required, double-underscore macros aside. Client
code can include just one of either a.hpp or b.hpp (or both) and it will
work as expected. These two files are part of the same "library" if you
will, so I believe their interdependence is acceptable, especially
considering the client code does not need to treat them any differently.
If you have any suggestions for a better way of implementing this while
keeping the declaration of A and B separate, I'd be very keen to know!
Cheers,
Adam.