struct comparison - reprise

[Guy Harris]

>Henry Spencer wrote something like
>
>	"Then how about struct addition, sonny?"
>
>to which I say
>
>	"Yes! Another useful struct operation!"

Fine.  Now what about complex *multiplication*?  Doesn't sound like any
generally-useful structure multiplication operation would do the trick. 
And what about division?

Sorry, but if you want complex numbers as a data type in C that uses C
operators, you can't get that just by pasting on new general "struct"
operators; you either have to add it to the language, or go the C++
route.

 >Another point raised by Henry
 >
 >	"How about polar representation of complex numbers and
 >	non-uniqueness?"
 >
 >was nicely dealt with by Roelof Vuurboom. Mathematical problems caused by
 >(inadequate) representation of mathematical quantities, and language
 >definitions are two different things. Here's another example:
 >
 >	prod = z * w;
 >
 >would be equivalent to
 >
 >	prod.Re = z.Re * w.Re;
 >	prod.Im = z.Im * w.Im;
 >
 >which is NOT the representation of the product of the complex numbers
 >represented by `z' and `w'. So what? YOUR fault, not the language's.

Yes, but as far as I can tell the *ONLY* benefit of structure comparison
as a "native" C operation is that it applies a bit of syntactic sugar
frosting to the operation.  Said frosting appears to have spoiled, in
both the cases of polar representation and in the case of complex
multiplication - so it appears that the "struct complex" example doesn't
cut it as an argument for adding new structure operators.

 >To Henry's remark
 >
 >	"You want C++, not C."
 >I say
 >	"For the `struct complex' example? Maybe. But does this mean
 >	any innovation should be swept off the table?"
 >
 >As Bernard A. Badger Jr. says, "you throw out the useful comparisons with 
 >the ill-defined ones.  It is perfectly well-defined and quite handy 
 >to define a simple member-by-member comparison on structs and arrays.
 >The only thing you give up are the unions.  Comparison of pointers is 
 >defined to be comparison of the pointers themselves, just as always."
 >
 >Roelof Vuurboom again:
 >"I've still got an awful lot of structs *which occur in the real world* 
 >for which I can (and several times wished I could) do a sensible comparison."

OK, let's *see* the examples.  I've only had any need for something
looking like structure comparison once or twice, and the inconvenience
of not having it was trivial.  Somebody earlier said Ada had structure
comparsion; OK, how often is it *really* used?  Not all features of a
given language are *ipso facto* useful.

And as for "does this mean any innovation should be swept off the
table", well, in a sense, yes.  Innovation should be kept to a minimum
in language standards; some amount of successful "prior art" - or
unsuccessful "prior art" - should weigh a *lot* more in the decision to
put something into a standard than should theoretical arguments for or
against some feature.  If you want structure comparison, put it into
*your* compiler (or GCC, or whatever), and report back on its success or
failure.  Just because some feature seems nice does NOT mean it belongs
in the current C standard.