Several people have replied. Thanks to all.
However I remain unconvinced. (I should have mentioned I'm relatively
new to C).
"- structs containing floating point numbers cannot be guaranteed
to ever compare as equal, except in trivial cases."
Does it mean that two floating point numbers may not compare equal (
even if they are equal and they are not part of a struct) - what has
this to do with being a member of struct ??
Nothing directly, except it means that floating-point equality
comparisons would be hidden behind a struct comparison. If you
compare floating-point numbers directly, it's more obvious (or it
should be) that you're doing something questionable.
Another issue is struct members that happen to be unions. There's no
way to determine which member of the union should be compared. If
struct comparison were added to the language, this would have to be
resolved, either by making an arbitrary choice (compare the first
declared union member), making it undefined behavior (something the
language doesn't need any more of), or disallowing struct comparison
for structs that contain unions.
[...]
Some others have mentioned about holes.
Does it mean that compiler can just take sizeof struct and do a copy
when doing =.
Yes.
I thought that the compiler may not touch the holes. Does the standard
say it's ok to access holes?
It doesn't say it isn't ok, so as long as it doesn't affect the
visible behavior of the program there's nothing wrong with it.
The compiler still knows holes when it
extracts members so why is it hard for the compiler to compare the
members it extracted?
To extract a member, the compiler has to know the offset and size of
the member. It doesn't have to worry about any gaps between the
member and any adjacent members. It doesn't matter whether the byte
following a member is a gap or another member (the compiler *might*
use this information for optimization in some cases, but it doesn't
have to).
For an equality comparison, the compiler would have to analyze the
entire layout of the structure, including where the gaps are and, on
many systems, the types of the members -- and this would have to be
done recursively for any nested structures.
I'm really curious why == can not be done by compiler. May be some
compiler writer have some insight or I'm not understanding the reasons
well. :-(
It *could* be done by the compiler. It's just not considered to be
worth the trouble. Most operations in C map more or less directly to
machine-level operations (part of what's known as the "spirit of C").
Struct equality comparison would be an exception to this general
principle.
And, in my experience, structure equality comparison just isn't used
that often. It's more common to want to know whether two structures
represent the same *logical* value. For example, if I have a
structure type that represents a dynamic string, I'll want to know
whether two objects represent the same string value. A
member-by-member comparison of the structures is unlikely to tell me
this; I need to write a separate function.
That's not to say that it wouldn't sometimes be uesful, but there's
always a tradeoff between complexity and usefulness. In this case,
you seem to be on the losing end of that tradeoff. Sorry, but it
happens to all of us.
Note that this was a design choice made by the authors of the
standard. The decision could have gone the other way. You're
obviously one of those who wish it had. No language is perfect; there
are plenty of things in C that I disagree with (though this isn't one
of them).
