comparing two structures

[junky_fellow]

Guys,

Is it a good way to compare two structures for equality by using
"memcmp" ?

If not, what could be the problems associated with this ? And what is
the correct
method of doing this ?

thanks for any help.

[Richard Heathfield]

ju**********@yahoo.co.in said:

Guys,

Is it a good way to compare two structures for equality by using
"memcmp" ?

No.

If not, what could be the problems associated with this ?

Padding bytes, and dynamically allocated memory pointed to by struct
members.

And what is the correct method of doing this ?

int cmp(const struct T *a, const struct T *b);

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Joachim Schmitz]

<ju**********@yahoo.co.inschrieb im Newsbeitrag
news:11*********************@w3g2000hsg.googlegrou ps.com...

Guys,

Is it a good way to compare two structures for equality by using
"memcmp" ?

If not, what could be the problems associated with this ? And what is
the correct
method of doing this ?

thanks for any help.

http://c-faq.com/struct/compare.html

[CBFalconer]

Richard Heathfield wrote:

ju**********@yahoo.co.in said:

>Is it a good way to compare two structures for equality by using
"memcmp" ?

No.

>If not, what could be the problems associated with this ?

Padding bytes, and dynamically allocated memory pointed to by
struct members.

>And what is the correct method of doing this ?

int cmp(const struct T *a, const struct T *b);

Which should resolve to (very roughly}:

for (c = eachcomponentof a) {
if ((a->c) != (b->c)) return 0; /* unequal */
}
return 1; /* i.e. structures equal */

Which means you have to write a cmp() each structure type. You may
have to resolve embedded pointers.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com

[Richard Heathfield]

CBFalconer said:

Richard Heathfield wrote:

<snip>

>>
int cmp(const struct T *a, const struct T *b);

Which should resolve to (very roughly}:

for (c = eachcomponentof a) {
if ((a->c) != (b->c)) return 0; /* unequal */
}
return 1; /* i.e. structures equal */

Personally, I would find a relational comparison more generally useful.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[John Gordon]

In <11*********************@w3g2000hsg.googlegroups.c om"ju**********@yahoo.co.in" <ju**********@yahoo.co.inwrites:

Is it a good way to compare two structures for equality by using
"memcmp" ?

No.

If not, what could be the problems associated with this?

One such problem is comparison of strings. The contents of a string are
meaningless after the terminating null byte, but memcmp() wouldn't know
that.

--
John Gordon A is for Amy, who fell down the stairs
go****@panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

[Tor Rustad]

CBFalconer wrote:

[...]

Which should resolve to (very roughly}:

for (c = eachcomponentof a) {
if ((a->c) != (b->c)) return 0; /* unequal */
}
return 1; /* i.e. structures equal */

Which means you have to write a cmp() each structure type. You may
have to resolve embedded pointers.

Very confusing name choice, unless cmp() return 0 if equal.

--
Tor <torust [at] online [dot] no>

[CBFalconer]

Richard Heathfield wrote:

CBFalconer said:

>Richard Heathfield wrote:

<snip>

>>>
int cmp(const struct T *a, const struct T *b);

Which should resolve to (very roughly}:

for (c = eachcomponentof a) {
if ((a->c) != (b->c)) return 0; /* unequal */
}
return 1; /* i.e. structures equal */

Personally, I would find a relational comparison more generally
useful.

Granted, but generally impossible. For:

struct foobar {int foo; char bar);

please define a suitable cmp function that is relational, without
somehow defining the relative importance of foo and bar. :-) I'm
sure you know this, but the comment is for general consumption.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Tor Rustad wrote:

CBFalconer wrote:

[...]

>Which should resolve to (very roughly}:

for (c = eachcomponentof a) {
if ((a->c) != (b->c)) return 0; /* unequal */
}
return 1; /* i.e. structures equal */

Which means you have to write a cmp() each structure type. You
may have to resolve embedded pointers.

Very confusing name choice, unless cmp() return 0 if equal.

You have my full permission to interchange 0 and 1. :-)

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Tor Rustad]

CBFalconer wrote:

Tor Rustad wrote:

>CBFalconer wrote:

[...]

>>Which should resolve to (very roughly}:

for (c = eachcomponentof a) {
if ((a->c) != (b->c)) return 0; /* unequal */
}
return 1; /* i.e. structures equal */

Which means you have to write a cmp() each structure type. You
may have to resolve embedded pointers.

Very confusing name choice, unless cmp() return 0 if equal.

You have my full permission to interchange 0 and 1. :-)

The API is still broken to my mind. :)

If first argument is less, then cmp() should return negative (e.g. -1),
if first argument is greater, then cmp() should return positive (e.g. 1).
Furthermore, if writing a cmp() function, I rather prefer to use the
same interface and return value as qsort() and bsearch() expect:

int cmp_mystruct(const void *, const void *)

why compare "struct's", unless doing sorting and searching?

--
Tor <torust [at] online [dot] no>

[Richard Heathfield]

Tor Rustad said:

<snip>

Furthermore, if writing a cmp() function, I rather prefer to use the
same interface and return value as qsort() and bsearch() expect:

int cmp_mystruct(const void *, const void *)

why compare "struct's", unless doing sorting and searching?

Well said, although I think I'd like to add an extra void * to that, so
that the comparison function can use (or provide) additional
information about the comparison without resorting to global data.
This, of course, requires ISO to change the spec for qsort and bsearch,
or provide sensibly-designed versions thereof.

Jump to it, lads...

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[pete]

Tor Rustad wrote:

Furthermore, if writing a cmp() function, I rather prefer to use the
same interface and return value as qsort() and bsearch() expect:

int cmp_mystruct(const void *, const void *)

why compare "struct's", unless doing sorting and searching?

If you had a linked list of structures
and if you had a list sorting function that
took a compar function pointer as an argument,
then it would make more sense to have pointers to the list node type.

--
pete

[CBFalconer]

Tor Rustad wrote:

CBFalconer wrote:

>Tor Rustad wrote:

>>CBFalconer wrote:

[...]

Which should resolve to (very roughly}:

for (c = eachcomponentof a) {
if ((a->c) != (b->c)) return 0; /* unequal */
}
return 1; /* i.e. structures equal */

Which means you have to write a cmp() each structure type.
You may have to resolve embedded pointers.

Very confusing name choice, unless cmp() return 0 if equal.

You have my full permission to interchange 0 and 1. :-)

The API is still broken to my mind. :)

If first argument is less, then cmp() should return negative
(e.g. -1), if first argument is greater, then cmp() should
return positive (e.g. 1).

But you are dealing with a struct. How do you define 'less' when
there are multiple components, with no less/greater definition.

>
Furthermore, if writing a cmp() function, I rather prefer to use
the same interface and return value as qsort() and bsearch()
expect:

int cmp_mystruct(const void *, const void *)

why compare "struct's", unless doing sorting and searching?

No, you can compare some fields of structs, but not complete
structs, for relative magnitude. The problem handled by void* is
not within the cmp function, but within the caller, who may not
need to know anything more than the cmp result about the struct.
The definition of cmp is up to you.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Richard Heathfield]

CBFalconer said:

<snip>

But you are dealing with a struct. How do you define 'less' when
there are multiple components, with no less/greater definition.

It depends on the domain. You are right that there is no general
solution, but that does not mean that there are no domain-specific
solutions. Nor does it mean that you cannot have multiple comparison
functions for the same type.

<snip>

The definition of cmp is up to you.

Precisely.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Tor Rustad]

CBFalconer wrote:

Tor Rustad wrote:

>CBFalconer wrote:

>>Tor Rustad wrote:
CBFalconer wrote:

[...]

Which should resolve to (very roughly}:
>
for (c = eachcomponentof a) {
if ((a->c) != (b->c)) return 0; /* unequal */
}
return 1; /* i.e. structures equal */
>
Which means you have to write a cmp() each structure type.
You may have to resolve embedded pointers.
Very confusing name choice, unless cmp() return 0 if equal.
You have my full permission to interchange 0 and 1. :-)

The API is still broken to my mind. :)

If first argument is less, then cmp() should return negative
(e.g. -1), if first argument is greater, then cmp() should
return positive (e.g. 1).

But you are dealing with a struct. How do you define 'less' when
there are multiple components, with no less/greater definition.

Hmmm.. what does this "comparing struct" mean?

Normally, when comparing ADT, the ADT has a key defined, e.g. like this:

struct node
{
KEY_T id;
DATA_T data;
};

and you only compare the key, not *all* the members of the struct.

When a programmer name a function cmp(), I expect a compare operation to
be defined. If only testing for equality, a far better name choice would
be e.g. 'is_equal()'.

See return value of memcmp, strcmp, ... it's <0, 0 or >0.

--
Tor <torust [at] online [dot] no>

[Tor Rustad]

pete wrote:

Tor Rustad wrote:

>Furthermore, if writing a cmp() function, I rather prefer to use the
same interface and return value as qsort() and bsearch() expect:

int cmp_mystruct(const void *, const void *)

why compare "struct's", unless doing sorting and searching?

If you had a linked list of structures
and if you had a list sorting function that
took a compar function pointer as an argument,
then it would make more sense to have pointers to the list node type.

Agreed, in this case, I wouldn't use void*, but rather

int is_equal(KEY_T, KEY_T );
int is_less (KEY_T, KEY_T );

--
Tor <torust [at] online [dot] no>

[Tor Rustad]

Richard Heathfield wrote:

CBFalconer said:

[...]

>The definition of cmp is up to you.

Precisely.

The compiler doesn't mind bad identifiers, but humans do...

The point is that the standard C library, the *is* functions return
differently, than the *cmp* functions do.
So, if you are consistent, you can't object to code with:

int is_zero(int c)
{
return ('0' != c);
}

either.

--
Tor <torust [at] online [dot] no>

[Richard Heathfield]

Tor Rustad said:

Richard Heathfield wrote:

>CBFalconer said:

[...]

>>The definition of cmp is up to you.

Precisely.

The compiler doesn't mind bad identifiers, but humans do...

The point is that the standard C library, the *is* functions return
differently, than the *cmp* functions do.
So, if you are consistent, you can't object to code with:

int is_zero(int c)
{
return ('0' != c);
}

either.

You lost me. Remember that my preference is for relational comparison, a
la strcmp and memcmp, rather than for equality-only comparison.

If you realised this and still think you have a point, I'd be curious to
know what that point is.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999