&array, evolved to struct compare

[Gregory Smith]

In article <2375 at brl-smoke.ARPA> rbj%icst-cmr at smoke.UUCP writes:
[ to compare structures ]
s/x/ct/
>Secondly, struxures could be created with the padding bytes set to
>all zero bits. Then, any garbage appearing in them could only be
>creating by sloppy coding practices which even *I* abhor, even
>considering my widely known nonportable tendencys.
>
>	(Root Boy) Jim Cottrell		<rbj at cmr>

Garbage could also be created by correct and portable use of unions.
A structure with holes could share a union with another hole-less
structure, and filling in the hole-less one could stuff data into
the holes of the holey one. Later stuffing of data into the holey
struct would not clean the holes.
Anyway, you are also saying that if I want an array of structs at run-time
I must calloc() it rather than malloc()ing it, or my code *might* not
work. If the struct is only, say, 4% holes ( not unreasonable ) this
could be expensive ( admittedly the time might easily be made up by faster
compares ).

Two equivalent structs could also have different contents if they
contained strings stored in char arrays: char a[30], say, and one
contains "abcd\0\0\0..." and the other (re-used ) contains
"abcd\0dribble\123foo_bar.." - of course, this can be avoided with
strncpy, again at increased time cost.

I don't think struct comparisons need be implemented. These are my
reasons:
	(1) The above problems - you have to go through too much
	     trouble to make it workable
	(2) Only compare for equality ( as opposed to ordering ) is
	    possible. It is rare that you need to compare entire
	    many-membered structs for equality.
	(3) Even if you do, the comparison is best done such that the
	    first member to be compared is the one most likely to be
	    different, and so forth. Only the programmer knows what
	    this order is. The members could, of course, be ordered such
	    that the first member is the 'best discriminator', etc,
	    but this could force unnatural orderings. Also, in the
	    string example above, if two strings were "foo\0\0....",
	    they would be compared in their entirety, even though only
	    the first 4 bytes are significant.
	(4) If you really need to do this, `struct foo's *a and *b can
	    be compared by cmpmem( a, b, sizeof( struct foo )), where
	    cmpmem is a memory-compare function. I agree it's not as nice
	    as a simple *a==*b. There is the argument that something which
	    is expensive should *look* expensive, which I feel applies
	    to cars but not to programming languages.
	(5) A good argument for allowing compares is "Well, sure they're
	    not often a good idea, but you don't *have* to use them."
	    The only problem I have with this, is that you need a fairly
	    deep understanding of what goes on in a machine before you can
	    use them safely. And they *look* 'clean and simple' so that
	    novices might have trouble. Also, modifications to a program
	    containing struct compares might break the code in very obscure
	    ways.

In summary: I certainly don't consider the above a proof that struct
compares shouldn't be implemented. However in my opinion, they aren't
worth the trouble and the risk.
-- 
"If you aren't making any mistakes, you aren't doing anything".
----------------------------------------------------------------------
Greg Smith     University of Toronto      UUCP: ..utzoo!utcsri!greg