Why is there no syntax for nested class forward declaration?

Considere e.g.

class A
{
public:
  class AA {};
  void f(B::BB*);
};

class B
{
public:
  class BB {};
  void f(A::AA*);
};

How must this code be oredered so that it is accepted by the compiler?
It would work when I replace
A::f(B::BB*) by A::f(void*) and lose type safety.

Helmut

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Helmut Zeisel wrote:
>

> How must this code be oredered so that it is accepted by the compiler?
> It would work when I replace
> A::f(B::BB*) by A::f(void*) and lose type safety.
>
That's a sticky one.  I don't think it can be done.  The
best I can suggest is to move the internal classes out of
the other classes.

You can't forward declare types defined within a class (outside
the class).   To do this you need to get these classes out to
namespace scope.  If you want to segregate the naems from the
global namespace, you can do that by placing them (and possibly
the related class) in it's own namespace.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Ron Natalie wrote:
>
> Helmut Zeisel wrote:
>
>
>>How must this code be oredered so that it is accepted by the compiler?
>>It would work when I replace
>>A::f(B::BB*) by A::f(void*) and lose type safety.
>>
>
> That's a sticky one.  I don't think it can be done.  The
> best I can suggest is to move the internal classes out of
> the other classes.
>
> You can't forward declare types defined within a class (outside
> the class).   To do this you need to get these classes out to
> namespace scope.  If you want to segregate the naems from the
> global namespace, you can do that by placing them (and possibly
> the related class) in it's own namespace.

This is unlovely, but it works:

// SomeTypes.h
struct SomeTypes { typedef int Type };

// SomeClass.h
#include "SomeTypes.h"
struct SomeClass { SomeTypes::Type func(void); }

Now you can write client code like this:

#include "SomeTypes.h"
class SomeClass;

As long as SomeClass either uses the typedes straight out of SomeType
(as above) or uses them to make its own typedefs:

struct SomeClass { typedef SomeTypes::Type Type; };

it's not a bug factory.

If SomeClass typedefs them directly:

struct SomeClass { typedef int Type; };

then it is a bug factory--the typedefs get out of sync.

I use this technique in The UFO, which is a heavily templated library
for capturing the information on a static structure diagram (without
intruding on the Domain classes any more than std::map does on the
mapped_type.)

Managing #include coupling is very important--even central--to the
scalability of a solution to that problem. Given a A 1--n B 1--n C, it's
very easy to make it so that a change in any one of A, B, or C causes a
recompile of the world. In fact, it's very hard not to. But I digress.)

As a matter of practice, I don't do the redundant typedefs, and I do add
a couple things to SomeTypes:

class SomeClass;

struct SomeTypes
{
   typedef SomeTypes Types;
   typedef SomeClass Class;
   typedef int Type_A;
};

struct SomeClass
{
   typedef SomeType Types;
};

So that both SomeTypes and SomeClass have common names for SomeTypes and
SomeClass:

SomeTypes == SomeTypes::Types::Types == SomeClass::Types::Types;

SomeClass == SomeTypes::Types::Class == SomeClass::Types::Class;

which I have found to be useful from time to time. (Some contexts can be
made to work with either SomeTypes or SomeClass visible.)

The whole thing is a nuisance, though. Sure wish I knew a better way.

--
I <3 Comeau C++: http://www.comeaucomputing.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]