struct comparison

[Badger BA 64810]

In article <2267 at auspex.auspex.com> guy at auspex.auspex.com (Guy Harris) writes:
[..stuff deleted...]
>I've seen no indication that it's sufficiently relevant *that it should
>be added to the language*; any definition of structure comparison would
>be peppered with caveats like "no unions" and "no arrays" and "it
>compares pointer values, not what they point to" and the like.

When I entered this discussion, it was centering on whether struct comparison
was a well-defined and useful operation.  I think that has been established
for structs not containing unions.  Whether to add it to the language --
in particular whether to include it in ANSI C -- is another, more 
(mostly?) political question.  

>
>Yes, there have been cases I've seen where it might have been
>convenient, but I really *can* live with doing the member-by-member
>comparison myself.  And, given that there's no prior art, I agree with
>X3J11's decision to leave it out.  If somebody sticks it into their
>compiler as an extension and we can really find out from experience
>whether enough people actually *would* use it enough to justify its
>existence, then it can be considered as an extension if it actually is
>used enough and doesn't confuse people.

There may be ``no prior art'' with standard C, but let's not ignore
prior art from other programming languages.  Struct comparison is less
confusing than unions and bit fields.  Anyway, Real Programmers (TM)
like Guy probably aren't using struct assignment and function return
values either (:-).


>>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). 
>
>I think Henry's point, like mine, is that the total number of cases
>where somebody, in effect, defines an equality operator over some data
>type seems likely to be much larger than the number of cases where this
>operator is just a member-by-member comparison; complex numbers
>represented in polar form are one example.  Given that, I'd like to see
>some real-world experience with such a feature before seeing it blessed
>in a standard.... 
>
>The original poster *did*, in fact, effectively ask "why isn't structure
>comparison in ANSI C"?  The question was answered, by Henry and others,
>and I have yet to see a *single* response to that answer that, to me,
>would justify the inclusion of such a feature *in the ANSI C standard*,
>given the lack of prior art (and yes, there *was* prior art for function
>prototypes, namely in C++; it may not have been in an otherwise "pure" C
>implementation, but at least it existed).  I suspect *I* wouldn't use
>structure comparison if it were available to me in C; I'm almost certain
>I wouldn't use it if it were available to me in C++ - I'd define an "="
>operator for the data type, instead, and not be forced to rely on
>member-by-member comparison being the right answer.

Of course, you wouldn't be *forced* to rely on member-by-member comparison!
You could still write your own function, or more likely macro.  Careful 
programmers would probably do that anyway, to maintain the abstraction.
However, wouldn't it be nice if you *could* write

#define COMPLEX_EQUAL(a,b)	((a) == (b))

instead of 

#define COMPLEX_EQUAL(a,b)	((a).real == (b).real && (a).imag == (b).imag)

(Whew!  That was a really tough one!)


What if we define:

typedef struct _vector_t {int	x,y,z;} vector_t;
typedef struct _matrix_t {vector_t	x,y,z;} matrix_t;

static const matrix_t identity_matrix = {{1,0,0},{0,1,0},{0,0,1}};
static matrix_t m1 = {{1,0,0},{0,0,1},{0,1,0}};

It may be convenient to inquire:
{	int flag = m1 == identity_matrix; ....}

Isn't it good?


I'll quote from ``C: A Reference Manual'' by Harbison and Steele, 

    p 106:
    5.7.1 Operations on Structures
    ...
     It is not permitted to compare two structures for equality. An
    object of a structure type is a sequence of components of other
    types.  Because certain data objects may be constraind by the
    target computer to lie on certain addressing boundaries, a
    structure object may contain ``holes,'' storage units that do not
    belong to any component of the structure.  The holes would make
    equality tests implemented as a wholesale bit-by-bit comparison
    unreliable, and component-by-component equality tests would be too
    expensive.  (Of course, the programmer may write
    component-by-component equality functions.)

I don't find this persuasive.  If an equality test is required, the 
programmer is going program it anyway.  The problems performing the test
don't go away just because the compiler has passed the responsibility to 
the programmer.  Perhaps the compiler will be able to produce better code
than the average programmer.  If not, (and I'm repeating myself here,) 
a programmer can usually avoid any language feature he doesn't like and 
do it the old-fashioned way.  

I don't know much about the politics and practicalities of introducing 
concepts to the current ANSI C.  I've heard that the purpose is more to 
standardize existing practice than to correct deficiencies that aren't 
outright faults.  So be it.  

I'm posting more in the hope of rescuing this simple idea from the 
criticisms by Guy and others that struct comparison is complex, 
ill-defined or not useful.

Bernard A. Badger Jr.	407/984-6385          |``Use the Source, Luke!''
Secure Computer Products                      |``Get a LIFE!''  -- J.H. Conway
Harris GISD, Melbourne, FL  32902             |Buddy, can you paradigm?
Internet: bbadger%x102c at trantor.harris-atd.com|'s/./&&/g' Tom sed expansively.