guido@mcvax.UUCP (Guido van Rossum) (03/31/84)
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
guido@mcvax.UUCP (Guido van Rossum) (04/08/84)
Followups and mail I receive tell me that I made a mistake about suggesting that < and > for pointers are little-known or little-used. The generic example looks something like: for (pointer = array; pointer < &array[arraylength]; ++pointer) ...; (This makes little difference for my reasoning, but that isn't widely supported either.) On unions: the examples posted and mailed didn't convince me of the usability of unions outside structs. They looked like poor hacks. But I'll stop argueing and translate my programs to Algol 68. :-) -- Guido van Rossum, "Stamp Out Basic" Committee, CWI, Amsterdam guido @ mcvax