[net.lang.c] Shared initial struct elements... history provides an answer?

kpmartin@watmath.UUCP (Kevin Martin) (01/14/85)

The problem:
	struct shared {
		int discriminant;
		type1 shared1;
		type2 shared2;
	};

	struct version1 {
		struct shared _x_;
		type3 unshared1;
		type4 unshared2;
	};

	/* etc. */
The problem is this funny _x_ that must be introduced in the names of the
shared parts.

The history:
Early C compilers were somewhat lax about structures, and you could say
something like
	struct version1 {
		struct {
			int discriminant;
			type1 shared1;
			type2 shared2;
		};		/* note: no _x_ */
		type3 unshared1;
		type3 unshared2;
	};
And everything worked.
This disappeared about the same time typed struture pointers appeared.

The solution:
	In a structure or union declaration, if an element declaration of
	type struct or union is given *with no declarators*, the elements
	of the inner struct or union are re-declared (additionally declared?)
	as elements of the outer struct or union, with their offsets being the
	offset of the start of the inner struct/union plus their offset within
	that struct or union. (phew!).
	Note that the inner elements would have to be unique in the outer struct/
	union.

The solved example:
	struct shared {
		int discriminant;
		type1 shared1;
		type2 shared2;
	};

	struct version1 {
		struct shared;
		type3 unshared1;
		type4 unshared2;
	};

	/* etc. */
This change doesn't break existing code, and reduces the need for the
programmer to create extra names for those funny nested structs.

No, Henry, we haven't implemented it. We're waiting for the standard before
we make any more compiler changes. But I wanted to mention this hare-brained
scheme before someone decides to use another hare-brained scheme...
              Kevin Martin, UofW Software Development Group

guido@boring.UUCP (01/15/85)

(Re: allowing 'partially qualified references' when a structure element
is unnamed and is itself a structure.)

This proposal doesn't solve any problem.
If we agree that the compiler may not reorder struct elements (i.e., we accept
the status quo), we can just use shared initial struct elements as we have
always done.  You can use the preprocessor to ensure that you indeed use
the same set of initial fields in all cases, instead of having to change
the language (slightly).
If the compiler is allowed to reorder elements, we can't even guarantee that
the unnamed substructure ends up in the same place in all structures where
it's used (without another special rule, that is), so it's still unsafe
to inspect the discriminant field.

The idea of parially qualified references in itself is nice, though, and
if introduced generally (using the Cobol or PL/1 rules, for instance),
might also be used for shared portions of larger structures as in the
original proposal.
But I will happily live without it (Ada doesn't have it, if that's an
argument :-).

	Guido van Rossum, "Stamp Out BASIC" Committee, CWI, Amsterdam
	guido@mcvax.UUCP

kpmartin@watmath.UUCP (Kevin Martin) (01/18/85)

In article <6284@boring.UUCP> guido@mcvax.UUCP (Guido van Rossum) writes:
>(Re: allowing 'partially qualified references' when a structure element
>is unnamed and is itself a structure.)
>
>This proposal doesn't solve any problem.
Actually, it does solve a problem. It is just that there is some confusion
as to what problem is to be solved. I suspect I am the person who has
deviated from the original problem, into one of my own pet peeves.

My proposal makes it easier to use complex nestings of structures within
unions within structures within..., which improves *one* of the solutions
for the several-types-of-structures-with-common-elements problem, namely
the solution "declare one structure containing the shared elements, and a
union of all the different variations". The only *other* problem with this
solution is that the combined structure is at least as big as the largest
of its variants. The user can only 'trim' the structure if the compiler
actually generates the fields in the declared order (note that this is
a necessary but not sufficient condition).

>The idea of parially qualified references in itself is nice, though, and
>if introduced generally (using the Cobol or PL/1 rules, for instance),
>might also be used for shared portions of larger structures as in the
>original proposal.
I was only thinking of allowing the 'partially qualified references' in cases
where the declarator was actually omitted from the original element
declaration, e.g., in:
    struct {
        union {
            int x;
            char *y;
            float z;
        } onion;
        char foo;
    } var;
var.onion.x is legal, but var.x isn't, and in
    struct {
        union {
            int x;
            char *y;
            float z;
        };
        char foo;
    } var;
var.x is legal, but var.onion.x (obviously!) isn't.

            Kevin Martin, UofW Software Development Group