«

Is it legal to compare the contents of two multi-field variables (of the
same struct) using "==" and "!="?

struct
{
int a;
int b;
} x,y;

...

if (x==y) // ?


Or is there a chance that the compiler may, for whatever reason, use
different layouts/paddings for the two variables even though they are of the
same struct?

"barcaroller" <> writes:
> Is it legal to compare the contents of two multi-field variables (of the
> same struct) using "==" and "!="?
>
> struct
> {
> int a;
> int b;
> } x,y;
>
> ...
>
> if (x==y) // ?

No, the "==" and "!=" operators are not defined for structs.
(Assignment is, though.)

> Or is there a chance that the compiler may, for whatever reason, use
> different layouts/paddings for the two variables even though they are of the
> same struct?

The layout is determined by the type, so that's guaranteed to be the
same. Specifically, the size and offset of a and b, and the size of
the entire struct, is the same for x as it is for y. This would be
a bit clearer if you gave the struct type a name:

struct foo {
int a;
int b;
};

struct foo x, y;

You can use memcmp() to determine whether two objects have the same
representation (this examines all the bits), but the compiler is free
to insert padding between members or after the last one, and the
contents of the padding can be garbage.

The only real way to compare x and y is to compare each member
explicitly:

x.a == y.a && x.b == y.b

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

On Wed, 29 Mar 2006 01:30:55 +0000, Keith Thompson wrote:

>
> No, the "==" and "!=" operators are not defined for structs.
> (Assignment is, though.)
>

Just curious: why? (Is assignment defined but not == an !=.)

It would think that if you are capable of copying one object to an other
you should also be capable of comparing them?

Regards,
Mark.

Mark <> wrote in newsan.2006.03.29.05.43.47.997972
@tiscali.nl:

> On Wed, 29 Mar 2006 01:30:55 +0000, Keith Thompson wrote:
>
>>
>> No, the "==" and "!=" operators are not defined for structs.
>> (Assignment is, though.)
>>
>
> Just curious: why? (Is assignment defined but not == an !=.)
>
> It would think that if you are capable of copying one object to an other
> you should also be capable of comparing them?

I don't claim to know what the actual rationale is but the following
argument for not specifiying how structs should be compared makes sense to
me.

Comparison is not well defined. For example, if the struct has pointer
members, does equality mean equality of pointers, or equality of values
pointed to by those pointers.

Or, are all fields relevant for the comparison?

Sinan

--
A. Sinan Unur <>
(remove .invalid and reverse each component for email address)

>On Wed, 29 Mar 2006 01:30:55 +0000, Keith Thompson wrote:
>> No, the "==" and "!=" operators are not defined for structs.
>> (Assignment is, though.)

In article <>
Mark <> wrote:
>Just curious: why? (Is assignment defined but not == an !=.)

It would, I think, have been reasonable[%] for Standard C to have
defined both equality and relational operators for "struct"s,
using the "obvious" definition that:

s1 comparison_op s2

would "mean":

s1.field1 comparison_op s2.field1 &&
s1.field2 comparison_op s2.field2 &&
...
s1.fieldN comparison_op s2.fieldN

Note, however, that in the general case -- using relational operators,
or using equality operators on structures that contain padding --
this would compile to many instructions on most machines. On most
systems today, the ordinary assignment operators compile to just
a few instructions: either an inlined memcpy(), or an actual call
to memcpy(), in most cases.

For a concrete example:

struct big { int n; char c; unsigned short j; double v[1000]; };

struct big v1, v2;
...
v1 = v2;

generally compiles to the equivalent of "memcpy(&v1, &v2, sizeof v1)",
while under this proposal, even:

v1 == v2

would compile to at least two separate comparisons, and probably
at least four: one for v1.n vs v2.n, one for v1.c vs v2.c, and for
v1.j vs v2.j, and perhaps one call to a support library loop for
v1.v vs v2.v. (Note that NaN != NaN but +0.0 == -0.0, so simple
bitwise comparisons will fail for "double"s. So while the first
three comparisons might actually be doable with memcmp(), provided
there is no padding between "c" and "j", the last one cannot.)

[% Or at least not totally *un*reasonable.]
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

"A. Sinan Unur" <> writes:
> Mark <> wrote in newsan.2006.03.29.05.43.47.997972
> @tiscali.nl:
>> On Wed, 29 Mar 2006 01:30:55 +0000, Keith Thompson wrote:
>>> No, the "==" and "!=" operators are not defined for structs.
>>> (Assignment is, though.)
>>
>> Just curious: why? (Is assignment defined but not == an !=.)
>>
>> It would think that if you are capable of copying one object to an other
>> you should also be capable of comparing them?
>
> I don't claim to know what the actual rationale is but the following
> argument for not specifiying how structs should be compared makes sense to
> me.
>
> Comparison is not well defined. For example, if the struct has pointer
> members, does equality mean equality of pointers, or equality of values
> pointed to by those pointers.
>
> Or, are all fields relevant for the comparison?

I don't think it would make sense to follow pointer members, any more
than "==" on pointers should compare the objects they point to.

There are two plausible ways to define structure comparison. One
would be equivalent to memcmp(), but that would cause problems with
padding bytes. Defining it apply "==" to each member (and each
recursively to members of members) makes sense (<OT>Ada does
this</OT>), but it requires the compiler to generate considerable code
for (x == y), which is generally considered to be against the "spirit
of C".

If you want to compare structures, you can write a function to do the
comparison (though it might be more convenient if the compiler did it
for you). And if you write it yourself, you can allow for cases where
you *don't* want to compare all the members:

struct my_string {
size_t len;
char str[MAX];
};

or where you want to follow pointers:

struct my_string {
size_t len;
char *str;
};

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

but the compiler is freeto insert padding between members or after the
last one..

Then How we can prevent the padding from compiler...

"code break" <> writes:
> but the compiler is freeto insert padding between members or after the
> last one..

I wrote that. Learn to quote. Read <http://cfaj.freeshell.org/google/>.

> Then How we can prevent the padding from compiler...

<http://www.c-faq.com/struct/padding.html>

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

A. Sinan Unur wrote:
> Mark <> wrote in newsan.2006.03.29.05.43.47.997972
> @tiscali.nl:
>
>
>>On Wed, 29 Mar 2006 01:30:55 +0000, Keith Thompson wrote:
>>
>>
>>>No, the "==" and "!=" operators are not defined for structs.
>>>(Assignment is, though.)
>>>
>>
>>Just curious: why? (Is assignment defined but not == an !=.)
>>
>>It would think that if you are capable of copying one object to an other
>>you should also be capable of comparing them?
>
>
> I don't claim to know what the actual rationale is [...]

Fortunately, the committee that wrote the Standard also
wrote (... wait for it ...) the Rationale! 6.5.9:

"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."

--
Eric Sosman
lid

On Wed, 29 Mar 2006 07:33:52 -0500, Eric Sosman wrote:

> A. Sinan Unur wrote:
>> Mark <> wrote in newsan.2006.03.29.05.43.47.997972
>> @tiscali.nl:
>>
>>
>>>On Wed, 29 Mar 2006 01:30:55 +0000, Keith Thompson wrote:
>>>
>>>
>>>>No, the "==" and "!=" operators are not defined for structs.
>>>>(Assignment is, though.)
>>>>
>>>
>>>Just curious: why? (Is assignment defined but not == an !=.)
>>>
>>>It would think that if you are capable of copying one object to an other
>>>you should also be capable of comparing them?
>>
>>
>> I don't claim to know what the actual rationale is [...]
>
> Fortunately, the committee that wrote the Standard also
> wrote (... wait for it ...) the Rationale! 6.5.9:
>
> "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."

But ofcource!! the padding, why didn't I think of that?!

Thanks, everyone, for the answer.

Regards,
Mark,