Article View: comp.std.c
Article #341Re: struct comparison
From: Badger BA 64810
Date: Tue, 18 Jul 1989 13:58
Date: Tue, 18 Jul 1989 13:58
39 lines
2924 bytes
2924 bytes
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.
Technical Details
Message-ID:
<2335@trantor.harris-atd.com>Path:
arc1-ca.pugleaf.net!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!bbadgerReferences:
<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>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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