structure (YES) and array and string (NO) comparisons
Guido van Rossum
guido at mcvax.UUCP
Sat Mar 31 16:09:33 AEST 1984
I would like to vote Yes for structure comparisons, even for < , > etc.
The arguments against struct compares are mostly of the kind "it usually
isn't what you want". So it is for pointer comparisons: I rarely use
pointer comparisons except with one NULL operand (did you ever use < or >
on pointers? Do you know for sure that they are defined ad all?). Still
they are there, and serve their purpose well.
The same would be true for structure comparisons. Ever tried to program
(a<=b) where a and are pairs of (y,x) coordinates on a terminal screen?
I came up with something like (a.y<b.y || a.y==b.y && a.x<=b.x). I would
have loved to use structure comparison here.
I frequently use a language (indeed the one to replace Basic) where ALL
values can be compared (to other values of the same type). Admittedly
the language doe not know pointers or unions. Given the fact that any
two values of a type can be compared, it is often possible to arrange
the fields of a structure in such a way that this comparison is meaningful.
In cases where it isn't (complex numbers, indeed, are THE example),
the comparison operators are simply not used (they're still used
internally for ordering in sorted lists and the like).
True, comparing structs with pointers in them with < or > would rarely
be what one wanted; but so is comparing the pointers themselves, and the
same solution (write and use a subroutine) applies; comparing structs
without pointers or unions can often be meaningful and handy.
Orthogonality (yes there is SOME of that in C; adding structure comparisons
would add some more) is certainly worth some effort in itself.
C should be freed from many silly restrictions.
Now about unions. I don't see how to compare struct with unions embedded,
or how to compare unions themselves, by the way. I think these always
always in the category where a subroutine should be written, so here
the restriction in the compiler is much less silly than for structs
in general. So this shouldn't be a counter-argument.
(BTW, unions aren't my favourite addition to C; neither were enumeration
identifiers in their current form. As for unions, I request anybody
to post an example of use of a union in real life without a struct around
it. I'll comment. I'd much more liked variant records like Pascal
has them -- which can also be compared more reasonable, though still
not as easy as plain records.)
Finally about arrays. I think the comparison of two arrays with known
bounds looks too much like pointer comparison to be added to the language
(one can declare a parameter to be an array with known bounds, but it's
still a pointer [I should try what sizeof says here?]). Structs with
arrays in them can be compared fine, and this should do the trick.
(Arrays in general cause problems with typedefs, as someone recently
pointed out. Note for instance that from the use and semantics of
"jmp_buf" (see <setjmp.h>) one can deduct that this type must be an
array: setjmp(buf) in all probability modifies its argument, and yet
does not need &buf to be passed. I guess this is a design bug.)
Of course zero terminators (or any other) are a no-no. Pity: I thought
the person who started this discussion mainly wanted to use == etc.
rather than strcmp (are you still listening?).
It's late now; let the flames come!
--
Guido van Rossum, "Stamp Out Basic" Committee, CWI, Amsterdam
guido @ mcvax
More information about the Comp.lang.c
mailing list