struct element orderin vs. align

[Kevin Martin]

In article <133 at ISM780B.UUCP> jim at ISM780B.UUCP writes:
>>        until you give me a subclass mechanism that ensures that the
>>representation of two data types share a common prefix, I'll rely on this
>>compiler hack.
>
>You already have it:
>
>struct {
>	common part;
>	union {
>		distinct part1;
>		distinct part2;
>		...
>	};
>};
>-- Jim Balter, INTERACTIVE Systems (ima!jim)


Unfortunately, that isn't true. I submitted a somewhat poorly-worded
solution which would allow your suggestion. Haven't read any flaming
replies yet, but then I don't read my news in order :-)

The problem with this:
	struct {
		common part;
		union {
			distinct part1;
			distinct part2;
			...
		} /* Insert declarator here */ ;
	};
is that most current compilers require that the programmer invent a name,
and insert it in place of the comment in the above source code. This is a
twofold problem: The programmer shouldn't have to invent names merely due
to a restriction in the compiler (this is a general principle). And, having
invented this extra name, the programmer must use it every time one of the
'distinct' parts is used; this detracts from concepts of data structure
hiding, since the programmer must know if the element to be accessed is
common or in one of the distinct forms. In fact, two extra funny names are
needed if the distinct types are structures, e.g.
	x.name_of_union.part1.element_of_part1
My argument is effectively that, if 'element_of_part1' is unique within
all of 'x', why does one need 'name_of_union.part1.'? In such a case,
these extra names shouldn't even be needed in the declaration of the
struct type!
                   Kevin Martin, UofW Software Development Group