Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site opus.UUCP
Path: utzoo!watmath!clyde!floyd!harpo!seismo!hao!cires!nbires!opus!rcd
From: rcd@opus.UUCP
Newsgroups: net.lang.c
Subject: Re: structure and array and string comparisons
Message-ID: <266@opus.UUCP>
Date: Fri, 30-Mar-84 01:16:44 EST
Article-I.D.: opus.266
Posted: Fri Mar 30 01:16:44 1984
Date-Received: Sun, 25-Mar-84 19:29:47 EST
References: <253@opus.UUCP> <365@denelcor.UUCP>
Organization: NBI, Boulder
Lines: 52

<>
Boy, this would-be feature doesn't want to die...
>>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...
Arrays might or might not be regarded as having an ordering property.
Structures, both philosophically and in general usage, are almost always
regarded as cartesian products of their components, hence inherently
unordered.  What's the point of defining ordering when the abstraction
modeled doesn't have the property?  Is it really so useful?

>>(incredibly verbose explanation (mine) of why comparison is very costly
>>if struct contains a union - see referenced article)
>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.
This is just not so.  It implies that any store into a field (or any
subfield) of a union requires clearing the unused tail for that field,
which can give you a 2:1 increase in the cost of a simple store for some
very common cases.  Moreover, I claim there's no implementation which is
reasonable and completely correct, because you can generate pointers to the
fields of the union (and this includes actual union-field parameters sent
with &) and store into the union indirectly.  (I'm beginning to wonder
whether this is a contest to see if I tire of constructing counterexamples
to proposals!)
>>(example in which a struct type "junk" may or may not be comparable
>>depending on whether it contains 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"...
Yes, I realize that completely.  I even like it.  I like language rules
that say things are either possible or impossible under all circumstances
much better than I like rules that say that some things are possible
sometimes.  Special cases make the language harder to learn and use, and
make compilers larger, slower, harder to write and harder to make correct.

>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?...
And the point that I see is that, given the desire to achieve a not-very-
large language, what should go in and what should stay out?  Even more
important, since the discussion started around changes to C, another
question is whether a change such as structure comparison is useful enough
(ignoring implementability for the moment) to justify changing the
language.  Remember that even for an upward-compatible change you must
change existing compilers.
-- 
{hao,ucbvax,allegra}!nbires!rcd