Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.std.c
Subject: Re: struct comparison
Message-ID: <2267@auspex.auspex.com>
Date: 21 Jul 89 18:38:46 GMT
References: <2874@solo3.cs.vu.nl> <1989Jul14.155312.2063@utzoo.uucp> <2878@kappl.cs.vu.nl> <1989Jul15.210821.7950@utzoo.uucp> <167@ssp1.idca.tds.philips.nl> <1989Jul18.020424.2392@utzoo.uucp> <2335@trantor.harris-atd.com> <2261@auspex.auspex.com> <171@ssp1.idca.tds.p
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 47

>1. unions, bit fields (and the related case of data padding)
>
>Agreed. But my argument above is that if I exclude these cases I've
>still got a very relevant operation.

I've seen no indication that it's sufficiently relevant *that it should
be added to the language*; any definition of structure comparison would
be peppered with caveats like "no unions" and "no arrays" and "it
compares pointer values, not what they point to" and the like.

Yes, there have been cases I've seen where it might have been
convenient, but I really *can* live with doing the member-by-member
comparison myself.  And, given that there's no prior art, I agree with
X3J11's decision to leave it out.  If somebody sticks it into their
compiler as an extension and we can really find out from experience
whether enough people actually *would* use it enough to justify its
existence, then it can be considered as an extension if it actually is
used enough and doesn't confuse people.

>3. polar complex example
>
>It took a while before I began to get the sneaky feeling that maybe 
>Henry Spencer had put one over me here.
>
>His argument was that because a certain _mathematical_ concept (complex
>comparison) couldn't be supported this was (one of the) grounds for 
>omitting a _language_ concept (struct comparison). 

I think Henry's point, like mine, is that the total number of cases
where somebody, in effect, defines an equality operator over some data
type seems likely to be much larger than the number of cases where this
operator is just a member-by-member comparison; complex numbers
represented in polar form are one example.  Given that, I'd like to see
some real-world experience with such a feature before seeing it blessed
in a standard.... 

The original poster *did*, in fact, effectively ask "why isn't structure
comparison in ANSI C"?  The question was answered, by Henry and others,
and I have yet to see a *single* response to that answer that, to me,
would justify the inclusion of such a feature *in the ANSI C standard*,
given the lack of prior art (and yes, there *was* prior art for function
prototypes, namely in C++; it may not have been in an otherwise "pure" C
implementation, but at least it existed).  I suspect *I* wouldn't use
structure comparison if it were available to me in C; I'm almost certain
I wouldn't use it if it were available to me in C++ - I'd define an "="
operator for the data type, instead, and not be forced to rely on
member-by-member comparison being the right answer.