struct comparison

[R. Vuurboom]

In article <2261 at auspex.auspex.com> guy at auspex.auspex.com (Guy Harris) writes:
>
>Well, it depends on how useful it *really* is; given enough "special
>cases", it may be that the only cases where it *is* useful are special
>cases, in which case you can whip up a macro to do the comparison.

Whipping, as is well known, is unpleasant at best (but may depend on 
which side of the whip you're on :-)


>>However, the fact remains that either simple ``compare all bytes'' or 
>>an expansion to compare all struct members recursively, would be a simple
			      ^^^^^^
>>extension which could be quite useful.
>
>Simple "compare all bytes" is certainly simple; how useful it is is
>another question, given that comparing padding bytes is simply wrong,
>unless you *guarantee* that they're always going to have some "standard"
>value that gets in the way.  

Agree.

>You still haven't indicated how unions are
				 ^^^^^^
>to be compared, so an expansion to compare all struct members
>recursively would fail if any such members were unions.  

Don't we all love to point out the obvious: a struct is not a union and
a union is not a struct and never the twain shall meet.

To repeat a struct comparison definition I posted a few days back:

Now _if_ I were to define struct comparison it would _only_ be for
structs for which each member can be directly compared or
is a struct to which this requirement is recursively applied.

This (and the above) definition is strictly Thatcherite: _no_ unions.

With this definition we've got the corollary that two structs compare
equal if and only if their members compare equal. 

So I disallow struct comparisons with structs which have unions, 
arrays and bitfields as members and possibly some other cases which
I can't think of but others undoubtedly can. But my point is that 
I've still got an awful lot of structs *which occur in the real world* 
for which I can (and several times wished I could) do a sensible comparison. 

Looking at the arguments up to now that have been advanced against
struct comparison:

1. unions, bit fields (and the related case of data padding)

Agreed. But my argument above is that if I exclude these cases I've
still got a very relevant operation.


2. member arrays, strings.

Why demand direct language support for comparison of arrays/strings in
a struct if you don't do it directly? Again exclude this case: I've
still got a useful, relevant comparison operator.

3. polar complex example

It took a while before I began to get the sneaky feeling that maybe 
Henry Spencer had put one over me here.

His argument was that because a certain _mathematical_ concept (complex
comparison) couldn't be supported this was (one of the) grounds for 
omitting a _language_ concept (struct comparison). 

This argument holds in my opinion as much water as defining the 
concept angle as:

typedef int angle; 

Stating that angles modulo 360 are really equal and then stating that
since angle1 and angle2 don't compare equal (even when separated by 
360 degrees) somethings wrong with the (int) comparison operation 
(and perhaps should be omitted :-).

4. Language Extension

(I've changed my mind on this one). It extends the language but not (much)
more than say returning a struct does and less in my opinion than function
prototyping for example. 

5. The comparison is not simple.

Agreed if you want to be able to compare all possible structs. Disagree
if you restrict to the above definition. In that case, struct comparison
is relatively easily to implement, it certainly is easy to 
comprehend and it most certainly is a relevant, useful operation even
with the stated restrictions.

>If you want abstract data types, you know where to find them....

Sure but all I want is a simple struct comparison :-)


-- 
Its a thin red line (and spelling error) between boring and borish.

Roelof Vuurboom  SSP/V3   Philips TDS Apeldoorn, The Netherlands   +31 55 432226
domain: roelof at idca.tds.philips.nl             uucp:  ...!mcvax!philapd!roelof