Re: Proposal for Structure Comparison

jacob navia <jacob@xxxxxxxxxx> writes:
lawrence.jones@xxxxxxxxxxx wrote:
Flash Gordon <smap@xxxxxxxxxxxxxxxxx> wrote:
There are many situations in which a simple structure comparison
makes sense in both embedded and hosted software.

Like it says in the C Standard Rationale:

The C89 Committee considered, on more than one occasion,
permitting comparison of structures for equality. Such proposals
foundered on the problem of holes in structures. A byte-wise
comparison of two structures would require that the holes
assuredly be set to zero so that all holes would compare equal,
a difficult task for automatic or dynamically allocated
variables. The possibility of union-type elements in a structure
raises insuperable problems with this approach. Without the
assurance that all holes were set to zero, the implementation
would have to be prepared to break a structure comparison into
an arbitrary number of member comparisons; a seemingly simple
expression could thus expand into a substantial stretch of code,
which is contrary to the spirit of C.


The "spirit of C".... justifies that instead of the compiler
generating those comparisons, the user is left alone to write

bool compareMyStruct(myStruct *a,myStruct *b)
{
if (a->field1 != b->field1)
return false;
if (a->field2 != b->field2)
return false;
if (a->field3 != b->field3)
return false;
if (a->field4 != b->field4)
return false;
if (a->field5 != b->field5)
return false;
/* ... */
return true;
}

It's not *quite* that bad. I'd write the above as:

bool compareMyStruct(struct myStruct *a, struct myStruct *b)
{
return a->field1 == b->field1 &&
a->field2 == b->field2 &&
a->field3 == b->field3 &&
a->field4 == b->field4 &&
a->field5 == b->field5;
}

And the user should never forget that at each modification of the
structure definition this function must be updated.

That's right. With each modification of the structure definition, the
programmer needs to consider whether a new member is relevant to an
equality comparison.

Certainly there are cases where the obvious member-by-member
comparison is just what you want. In those cases, having the
comparison supported directly by the language would be convenient.
The question is whether this convenience is worth the added complexity
of the standard and the additional burden on implementers.

My personal opinion is that the answer is no. But I'm willing to be
persuaded otherwise, and I'm glad to discuss it with the goal of
getting it right.

[...]

There are a number of questions that would have to be answered before
adding struct equality comparisons to the standard. All those
questions *can* be answered. In most cases, I personally think that
there's one obviously correct answer (though others will undoubtedly
think that there's a different obviously correct answer).

The one exception is Nate Eldredge's question about flexible array
members; I can't think of a good answer for that one, other than
making it a constraint violation to compare structures that contain a
flexible array member.

Here's another question that I don't think has been mentioned. A
structure cannot have a trap representation, but a member can. If a
member of a structure has a trap representation, does "==" invoke
undefined behavior? I think the obvious answer is yes. But note that
this:

struct foo a;
struct foo b;
/* some code */
a = b; /* this is ok */
if (a == b) { /* ... */ }

can invoke UB, which is a somewhat surprising result.

--
Keith Thompson (The_Other_Keith) kst@xxxxxxx <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
.

Relevant Pages

  • Re: A C++ Whishlist
    ... computer your member function can't throw an exception. ... members with a NULL pointer on almost all computers out there. ... Mine is already robust; if you want to make yours robust ... Doesn't matter if the standard is changed or not. ...
    (comp.lang.cpp)
  • Re: Youre appointed as Portability Advisor
    ... None of its behaviour is undefined by the Standard. ... to write to member A of a union and then read from member B, ... character type that treats the thing as an array of bytes. ... dereferencing a pointer to one ...
    (comp.lang.c)
  • Re: Screaming neighbors on the golf course
    ... forward, or your sleazy buddies. ... At my pvt club, a similar thing happened; but by a member that claimed ... he couldn't wait 3 holes. ...
    (rec.sport.golf)
  • Re: Undefined behaviour
    ... if a member of a union object is accessed after ... a common initial sequence if corresponding members have compatible ... The C99 standard says virtually the same thing. ...
    (comp.lang.cpp)
  • Re: Countable models of ZFC
    ... and THAT MODEL ALSO might be standard OR NONstandard. ... standard. ... You have to be able to make sense of "x is a member of y" all by ... relation to some submodel IS NOT going to guarantee that that submodel ...
    (sci.logic)
Loading