Standard for union initialization
Kevin Martin
kpmartin at watmath.UUCP
Sat Feb 9 06:26:43 AEST 1985
In article <6301 at boring.UUCP> guido at boring.UUCP (Guido van Rossum) writes:
>In article <11143 at watmath.UUCP> kpmartin at watmath.UUCP (Kevin Martin) writes:
>>This looks ok for a nice short example like this, but frequently, the
>>union's definition and initialization are far apart (and maybe in different
>>source files). This makes it easy to add another union element, and
>>inadvertantly screw up the initializers royally without as much as a
>>peep from the compiler.
>
>Why is this proposal attacked so vehemently?
At our site, one of our observations is that people can't count
past three, especially when the things being counted
are all identical (e.g. the leading commas in your scheme). At least
for a structure, there is stuff between the commas to keep you from
going cross-eyed reading it.
>All arguments I hear
>against it (and it is really the same argument all the time) can be
>used against structure initialization as well: the meaning of the
>initialization depends on the order of the elements in the struct/union
>declaration.
There is no reason why a name-the-element selective initialization
(such as my suggestion) can't also apply to structures.
Actually, with structures, there is a much better chance that, in adding
an extra element, you end up with a type mismatch, such as initializing
a pointer to 42.
>Since the order of initializations is
>unimportant *except for the proposed initialization feature* (this is
>true even for the first member rule!), new elements should be added to
>the end of the union.
New elements should be added in a position which gives the greatest
self-documenting properties.
Kevin Martin, UofW Software Development Group
More information about the Comp.lang.c
mailing list