[comp.std.c] struct comparison - reprise

maart@cs.vu.nl (Maarten Litmaath) (07/21/89)

It seems I'm not the only one in favor of (a limited form of) struct
comparison. On my `traditional struct complex' example

	struct	complex {
			int	Re;
			int	Im;
		} z, w;
	...
	if (z == w) ...

Henry Spencer wrote something like

	"Then how about struct addition, sonny?"

to which I say

	"Yes! Another useful struct operation!"

Of course the structure elements must be addable, i.e. no pointers etc..
(There we go again, Blair!)
Arrays would be added member-wise. Hmm, sounds interesting...
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.
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."
-- 
"Mom! Eric Newton broke the day! In 24   |Maarten Litmaath @ VU Amsterdam:
  parts!" (Mike Schmitt in misc.misc)    |maart@cs.vu.nl, mcvax!botter!maart

guy@auspex.auspex.com (Guy Harris) (07/23/89)

>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.

gwyn@smoke.BRL.MIL (Doug Gwyn) (07/23/89)

In article <2272@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes:
> 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.

That's also my general observation:  When I need composite objects, I
practically always find that I also need operations on them beyond any
simple model that could reasonably be supported directly via language
operators.  Complex multiplication is just one of the simplest examples.
Since I have to provide a set of explicitly programmed operations anyway,
it is not a lot of additional bother that the language doesn't directly
support a few of them.

peter@ficc.uu.net (Peter da Silva) (07/24/89)

In article <10593@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
> That's also my general observation:  When I need composite objects, I
> practically always find that I also need operations on them beyond any
> simple model that could reasonably be supported directly via language
> operators.  Complex multiplication is just one of the simplest examples.

This is a reasonable point, but do keep in mind that this is also true of
simple objects. For example, when dealing with !(char *)! objects, don't
you practically always find that you need operations on them beyond any
simple model that could reasonably be supported directly via language
operators? !strcmp()! is just one of the simplest examples.
-- 
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.
Business: peter@ficc.uu.net, +1 713 274 5180. | "...helping make the world
Personal: peter@sugar.hackercorp.com.   `-_-' |  a quote-free zone..."
Quote: Have you hugged your wolf today?  'U`  |    -- hjm@cernvax.cern.ch