Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1a 12/4/83; site rlgvax.UUCP
Path: utzoo!watmath!clyde!floyd!harpo!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.lang.c
Subject: Re: What Can't C Do?
Message-ID: <1819@rlgvax.UUCP>
Date: Tue, 20-Mar-84 12:43:37 EST
Article-I.D.: rlgvax.1819
Posted: Tue Mar 20 12:43:37 1984
Date-Received: Wed, 21-Mar-84 02:48:31 EST
References: <6900@unc.UUCP> <178@harvard.UUCP>, <237@opus.UUCP> <237@unisoft.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 30

>> <>
>>  > While you're on the subject, what about == to compare two structures?
>>  > This is even more reasonable, in that structure assignment is supported...
>> Yet another bad idea.  This is much harder than it looks, for at least the
>> following reasons: ....

> However -- comparing two structure of identical names is useful. Tells the
> compiler to do byte-for-byte compare inline. Equality and inequality are
> obvious, but I wouldn't want to count on  < or >.

You missed his point; to correctly compare two structures a byte-for-byte
comparsion should *not* be done.  The bytes which are not part of structure
members, but which are just padding to put structure members on the right
boundary, *must* not be compared or two structures which "should" be equal
won't compare equal.

Yes, the comparison would be nice, but it's not trivial to implement and
won't compile into a simple comparison.  Also, < and > are flatly impossible;
what about

	struct complex {
		double	realpart;
		double	imagpart;
	};

Any result of < and > would be misleading as the complex numbers aren't an
ordered field.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy