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