Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > == operator on struct

Reply
Thread Tools

== operator on struct

 
 
Lawrence Kirby
Guest
Posts: n/a
 
      07-03-2005
On Sat, 02 Jul 2005 07:36:04 -0700, indigodfw wrote:

> 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 ??


Floating point calculations are in most cases inexact i.e. the results are
approximations. Comparing approximate results for equality (i.e.
exactness) is potentially a logical flaw. Doing this in a struct is
dangerous because strucure comparison effectively hides the fact that
floating point comparisons are involved. Besides there are lots of
different ways you coul compare the members of a struct and very often you
don't want to involve all structure members in such a comparison. For
example in a linked list you might want to compare the data held in a node
but it would be an error to include the link pointer in the comparison.

In short structure comparison isn't a trivial operation to implement to
give reqsonable results and even then typically doesn't implement what you
need in practice. It is better to code the comparison you need explicitly.

> The remaining points are do not make any logical point to me. It does
> not matter how useful this may be or some user from yahoo may ask
> something else etc.


Usefulness is important. A simple language is better than a complex
language in many ways, it is easier to learn, easier to read, easier to
implement. So unless a feature provides a real, significant benefit to a
language you are often better off leaving it out.

> Some others have mentioned about holes. Does it mean that compiler can
> just take sizeof struct and do a copy when doing =. I thought that the
> compiler may not touch the holes. Does the standard say it's ok to
> access holes? The compiler still knows holes when it extracts members so
> why is it hard for the compiler to compare the members it extracted?


The compiler can copy padding bytes if it wants to since they don't
contribute to the value of the struct.

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


We're not saying that it can't be done, just that supporting this would
add little if any utility to the language, but it would create a whole
can of worms.

Lawrence

 
Reply With Quote
 
 
 
 
websnarf@gmail.com
Guest
Posts: n/a
 
      07-04-2005
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> 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 ??


Yes, 0 and -0 are the same number but can be represented in two
different ways in the IEEE-754 standard.

But there are worse problems -- NaN != x is true for *every* value of x
*including* NaN. Furthermore there are multiple representations of NaN
which are all assumed to normalize to the canonical NaN value. So even
if you wanted to subvert the IEEE-754 mechanics, and say that NaNs are
equal to each other you are screwed.

The real problem with struct comparing has, IMHO, not been addressed.
The C Rationale has been quoted here and it underscores just how short
sighted and bad the C committee's thinking is. Fortunately they seem
to have made the correct choice even if for the wrong reason.

The *REAL* reason why you can't sanely do struct comparison is because
a struct may contain a char array[] entry:

struct test1 {
char name[256];
} x, y;

Ok, so if you "struct compared" the variables x and y, what do you
expect to happen? If the name[] entry is supposed to be a
256-character array buffer, then memcmp() semantics is just fine. If
you intend that entry to be a '\0' terminated string (which you've
provided "more than adequate" space for) then what you want is strcmp()
semantics.

Worse yet, it doesn't follow the semantics when you remove the wrapping
struct declaration, if you just declare two such arrays:

char name1[256], name2[256];

Then comparing name1 and name2 compares the *pointers* and is going to
always be false, BTW.

If you were to change it to pointer comparison for the structs, then
that would just be equivalent to comparing the struct base pointers,
which you can already do today (but comparing the & of the struct
variables.)

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

 
Reply With Quote
 
 
 
 
indigodfw@yahoo.com
Guest
Posts: n/a
 
      07-04-2005
Keith, Lawrence and Paul

That was quite useful piece of information.

Thank you,
CLC rocks! This is a great mailing list.

-Sushil

 
Reply With Quote
 
Coos Haak
Guest
Posts: n/a
 
      07-04-2005
Op 4 Jul 2005 09:30:52 -0700 schreef (E-Mail Removed):

> Keith, Lawrence and Paul
>
> That was quite useful piece of information.
>
> Thank you,
> CLC rocks! This is a great mailing list.
>
> -Sushil


This isn't a mailing list. It's a newsgroup
--
Coos
 
Reply With Quote
 
Kenneth Brody
Guest
Posts: n/a
 
      07-06-2005
Anonymous 7843 wrote:
>
> In article <(E-Mail Removed). com>,
> <(E-Mail Removed)> wrote:
> >
> > I would like to know the rationale on allowing structs to be assigned
> > (using = operator) and not allowing equality operator ( == operator) on
> > them.
> >
> > The compiler when it assigns using = is aware of holes etc and the same
> > compiler then should be able to generate code to compare the individual
> > struct fields.
> >
> > When a new field is added to the struct, all such instances where the
> > == using individual field is compared need to be modified and is a real
> > pain.

>
> Such a feature isn't as useful as it might seem.
>
> - structs containing floating point numbers cannot be guaranteed
> to ever compare as equal, except in trivial cases.
>
> - the larger the struct, the more likely there are members which
> are uninteresting for comparison purposes.
>
> - if there was a struct-equality operator, then eventually some
> gmail or yahoo user would come along and ask why there are
> no struct-inequality operators, and if those existed, why
> can't they be passed to bsearch() and qsort(), and if they
> could why can't they be parameterized to give different
> weight and ordering to different struct members...
>
> - a complicated equality operator works against the basic C principle
> that the basic operation of the language map to very short
> (and fast) sequences of cpu instructions.


To take it a step further, someone would then ask "why does the
equality fail when the char* entry points to separate, yet identical,
strings?" Should this new equality operator require that pointers
point to the same object, or is it okay to point to two distinct
objects, as long as those objects themselves will compare equal?

And so on...

If the OP is many places he needs to compare structs, and is afraid
of modifying all of these places when the struct is modified in the
future, then simply write a function to do the comparison. (Not to
mention that this allows the user to define "less than" and "greater
than", which is something that the compiler can't do anything useful
with even on a simple "int month,day,year;" struct.)

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <(E-Mail Removed)>


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Can *common* struct-members of 2 different struct-types, that are thesame for the first common members, be accessed via pointer cast to either struct-type? John Reye C Programming 28 05-08-2012 12:24 AM
Typedef A references struct B which references struct A which... DanielEKFA C++ 8 05-16-2005 10:26 AM
struct in struct Gunnar G C++ 14 06-02-2004 06:43 PM
struct my_struct *p = (struct my_struct *)malloc(sizeof(struct my_struct)); Chris Fogelklou C Programming 36 04-20-2004 08:27 AM
implementing a templated struct within a templated struct RA Scheltema C++ 3 01-06-2004 11:25 AM



Advertisments