🚀 go-pugleaf

In article 950729200137683@wem.org, henry.baker@wem.org (Henry Baker) writes:
>
>Suppose I have the following nested class:
>
>struct pair
>{struct pair_rep
> {pair car,cdr;};    // inner class has member of outer class.
> pair_rep *rep;};
>
>I understand the rule saying that a class cannot be a member of itself
>[Stroustrup#2, page 545] (Bertrand Russell is now spinning in his grave ;-),
>but I'm having trouble understanding why a _nested_ class cannot have a
>member
>of the outer class being defined.  This is especially irritating, since the
>above is capable of being rewritten as [Stroustrup#2, page 645]:
>
>struct pair
>{struct pair_rep;
> pair_rep *rep;};
>
>struct pair::pair_rep
>{pair car,cdr;};
>
>Are compiler writers just being lazy, or what??

It isn't a compiler issue specifically. The language rule is that you
can't define a class member having an incomplete type. At the point
where struct pair_rep is defined, type 'pair' is an incomplete type,
yet its definition is required as part of the definition of type pair_rep.

When you split the definition from the declaration as in the second
example, you no longer have the problem.

To better understand the rule, suppose that the first version were legal
but we modified the definition slightly (and reformat to make it readable):

struct pair { // 3rd version
	struct pair_rep {
		pair car, cdr;
	};
	pair_rep pr;
};

Clearly version 3 isn't valid, yet up to the end of the inner struct
definition it is identical to the original. How much re-parsing and
re-defining on the fly should a compiler be required to do? The actual
rule of requiring complete types where a complete type is needed allows
early determination of errors, instead of arbitrary amounts of re-checking.

---
Steve Clamage, stephen.clamage@eng.sun.com