structure and array and string comparisons

[Neal Weidenhofer]

**************************************************************************

>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 but it's no harder for the compiler than it is for the programmer
except for unions (see more below).

>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.

Granted that '<' and '>' would be misleading in certain cases, I suggest
lexicographic comparison.  It would still be useful in many cases, for
arrays as well as structures.  If a programmer insisted on using it where
it was meaningless (e.g., complex numbers) it would be no worse than many
features "C" and several other languages have (GIGO).

>I'm sorry I ever slipped and understated the situation!  When I said that
>comparing structures is "hard" I meant that it's hard enough to be
>impractical.  Unions are perhaps the worst aspect, and you CAN'T avoid
>unions if you are going to compare structures, because a structure can
>contain a union.  Filling in a little bit of the reasoning:  The elements
>of a union can be of differing size.  If you compare two instances of a
>struct-containing-union, you have to know how much of the union to compare,
>to avoid a spurious mismatch on the unused trailing part of a short field.
>To do that, you have to know which field of the union is the current one,
>which in turn would mean that code would be required at EVERY assignment to
>a field of the union (plus or minus some very messy optimization) to keep
>track of the current field.  This isn't even remotely practical with C's
>undiscriminated union.

Another solution would be to clear the unused parts of the union wherever
a store is done.  In many cases (admittedly not all) this would be very
cheap.

>[OK, at least 5% of you are ready to suggest allowing "comparisons of
>structures unless they contain unions".  Please don't.  First, this is
>pretty clearly a clunky special case we don't need - but it also makes a
>mess of a certain sort of data-hiding:
>	struct junk {
>		int a,b,c,d;
>		mystery xyzzy;
>	}
>where "mystery" is a typedef from elsewhere.  The "junk" type shouldn't
>have to care what's in type "mystery"; it just needs one.  (Data
>abstraction and all that apple pie...)  However, the semantics of objects
>of type "struct junk" - in particular, whether they can be compared - would
>depend on whether "mystery" was, or contained, a union.]

Your point is well taken but I wonder if you realize that you've also
made it IMPOSSIBLE for the programmer to compare two structures of type
"junk".  It's in just such cases that structure comparison would be the
most useful.

I agree that there are some very hard problems but I think we need to give
it more thought and conversation before we dismiss it as impractical.  The
point I see is that structures NEED to be compared sometimes, is it better
for the compiler to make it easy for the programmer or not?  Except for
the problem with unions, the compiler has as much information about the
structure as the programmer does--often more.

			Regards,
				Neal Weidenhofer
				Denelcor, Inc.
				<hao|csu-cs|brl-bmd>!denelcor!neal