Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucsd!sdcsvax!trantor.harris-atd.com!x102c!bbadger
From: bbadger@x102c.harris-atd.com (Badger BA 64810)
Newsgroups: comp.std.c
Subject: Re: struct comparison
Summary: The A-word strikes again
Message-ID: <2335@trantor.harris-atd.com>
Date: 18 Jul 89 13:58:26 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>
Sender: news@trantor.harris-atd.com
Reply-To: bbadger@x102c.harris-atd.com (Badger BA 64810)
Organization: Harris GISD, Melbourne, FL
Lines: 39

In article <1989Jul18.020424.2392@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <167@ssp1.idca.tds.philips.nl> roelof@idca.tds.PHILIPS.nl (R. Vuurboom) writes:
>>>It's also not a particularly good idea:  suppose I change to a polar 
>>>form, where the representation of a given
>>>complex number is not unique?  
>>
>>Henry, this is cheating :-). If somebody comes along and changes the 
>>representation of an int while I'm not looking nobody expects the
>>two values (old representation vs new representation) to compare equal.
>
>Not quite what I was getting at.  The point of polar representation is
>that member-by-member comparison does not dependably get the right answer!
>Equality comparison on polar representation requires range reduction on
>the angle first.  This leads again to the need for C++, where you can
>define the comparison operation to be arbitrarily complex.
>-- 
>$10 million equals 18 PM       |     Henry Spencer at U of Toronto Zoology
>(Pentagon-Minutes). -Tom Neff  | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

Sure, you _may_ run into special cases, but is this any reason to leave out 
a useful operation?  Other languages, such as Ada (Oh no! The A-word!), 
provide for comparison of composite objects (records in Ada correspond to 
structs in C).  Of course there should be caveats about padding data being 
compared.  Also unions should only be compared to another union or object
which is *actually using* the same representation.  (That is, given:
	union lf_t {long l; float f} lf_a, lf_b;
	lf_a.l = 10; 
	lf_b.f = 10.0;
we should probably not be testing (lf_a == lf_b), but rather 
(lf_a.l == (long) lf_b.f).)

However, the fact remains that either simple ``compare all bytes'' or 
an expansion to compare all struct members recursively, would be a simple
extension which could be quite useful.

Bernard A. Badger Jr.	407/984-6385          |``Use the Source, Luke!''
Secure Computer Products                      |``Get a LIFE!''  -- J.H. Conway
Harris GISD, Melbourne, FL  32902             |Buddy, can you paradigm?
Internet: bbadger%x102c@trantor.harris-atd.com|'s/./&&/g' Tom sed expansively.