compare two structs via ==

[Mark Wilden]

Re: compare two structs via ==

"Peter Duniho" <NpOeStPeAdM@nn owslpianmk.comw rote in message
news:op.ttgwxqm 58jd0ej@petes-computer.local. ..
On Tue, 05 Jun 2007 13:43:09 -0700, Mark Wilden <mwilden@commun itymtm.com>
wrote:

>>Memberwise comparison worked pretty well in C++. An object is equal to
>>another object if all its members are equal to the other object's
>>members (using the same criterion for member equality).

>>
>Usually, but not always.

>
No - always. That was the definition of equality.
As long as the == operator wasn't overloaded, you mean.

We're not talking about overloading ==, since that would imply comparing an
object to a different kind of object. We're talking about comparing an
object to an object of the same class - no overloading.

The behavior of operator== could be overridden, but that I would maintain
that that didn't change the definition of object equality. Someone could
overload == to format your hard drive, but that doesn't change C++'s
definition of equality, which is that two objects are equal iff. all their
members are equal.

But if someone's idea of equality was different from the language's, then
you're right - they could certainly use == to implement that idea. And that
was sometimes done, of course, for legitimate reasons.

It's hard for me to imagine, however, that two objects whose members were
equal to each other would not be equal... But I could be wrong.

And of course "equal" is not the same thing as "identical. "

///ark

[Peter Duniho]

Re: compare two structs via ==

On Wed, 06 Jun 2007 16:08:47 -0700, Mark Wilden <mwilden@commun itymtm.com
wrote:

We're not talking about overloading ==, since that would imply comparing
an
object to a different kind of object.

Why would it imply that?

Overloading the == operator is perfectly fine for the purpose of modifying
the default memberwise-compare behavior. For example, when you want two
instances to compare as equal as long as they contain strings that are
identical, even if the strings themselves are different instances.

We're talking about comparing an
object to an object of the same class - no overloading.

I don't see why comparing an object to an object of the same class implies
no overloading.

The behavior of operator== could be overridden, but that I would maintain
that that didn't change the definition of object equality. Someone could
overload == to format your hard drive, but that doesn't change C++'s
definition of equality, which is that two objects are equal iff. all
their
members are equal.

I disagree that that's the only valid definition of equality in C++.
Specifically because of operator overloading.

But if someone's idea of equality was different from the language's, then
you're right - they could certainly use == to implement that idea.And
that
was sometimes done, of course, for legitimate reasons.
>
It's hard for me to imagine, however, that two objects whose members were
equal to each other would not be equal... But I could be wrong.

In C# that happens all the time. By default if you compare two
references, then even if the members are equal to each other, if the
actual references are not equal the objects are not equal.

And of course "equal" is not the same thing as "identical. "

Well, that's my point. "equal" is whatever it has been defined to be ina
particular context. Because of operator overloading, this varies. There
is no one "equals" that is defined.

Pete

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Re: compare two structs via ==

Mark Wilden wrote:

It's hard for me to imagine, however, that two objects whose members were
equal to each other would not be equal... But I could be wrong.

It's the inequality that is the problem. Just because some of the fields
in two objects are not equal doesn't mean that the obejcts are not
equal. One field in an object may determine if another field should be
included or not when deciding equality.

And also of course if you define two separate instances to be unequal,
as Peter mentioned.

--
Göran Andersson
_____

http://www.guffa.com

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Re: compare two structs via ==

Mark Wilden wrote:

"Göran Andersson" <guffa@guffa.co mwrote in message
news:eIEKCSBqHH A.1148@TK2MSFTN GP06.phx.gbl...

>Mark Wilden wrote:

>>"Göran Andersson" <guffa@guffa.co mwrote in message
>>news:%23Ci4dG 2pHHA.1144@TK2M SFTNGP02.phx.gb l...
>>>
>>>>Memberwis e comparison worked pretty well in C++. An object is equal to
>>>>another object if all its members are equal to the other object's
>>>>members (using the same criterion for member equality).
>>>>>
>>>Usually, but not always.
>>No - always. That was the definition of equality.

>Ok, but then the definition of equality didn't always make sense.

>
Do you have an example? Like I said, it seemed to work well for us.
>
///ark
>

Easily:

public struct ValidDouble {
private bool _valid;
private double _value;
...
}

If two values have _valid set to false, you might want to consider them
equal, regardless of the value of _value;

--
Göran Andersson
_____

http://www.guffa.com

[Mark Wilden]

Re: compare two structs via ==

"Peter Duniho" <NpOeStPeAdM@nn owslpianmk.comw rote in message
news:op.ttiyro2 k8jd0ej@petes-computer.local. ..
On Wed, 06 Jun 2007 16:08:47 -0700, Mark Wilden <mwilden@commun itymtm.com>
wrote:

>We're not talking about overloading ==, since that would imply comparing
>an object to a different kind of object.

>Why would it imply that?

Overloading means adding another method with the same name but a different
signature. It's easy to confuse overloading with overriding, as my own post
proved. :)

The non-overloaded operator== that C++ automatically generates takes as its
argument a member of the same class or a base class of the same class
(IIRC). Overloading means to leave that method alone and add another method
that takes, for example, an int as the argument. I believe you're talking
about overriding, where a child class overrides a parent class method (with
the same signature) to do something different than the parent.

>Overloading the == operator is perfectly fine for the purpose of modifying
>the default memberwise-compare behavior. For example, when you want two
>instances to compare as equal as long as they contain strings that are
>identical, even if the strings themselves are different instances.

Actually, that would be encompassed by a plain ol' memberwise compare.
Strings with identical contents are indeed equal. To just compare the
addresses would be the old bitwise comparison.

>In C# that happens all the time. By default if you compare two
>references, then even if the members are equal to each other, if the
>actual references are not equal the objects are not equal.

I think that would be confusing, since equality is different from
identicality (?).

>And of course "equal" is not the same thing as "identical. "

>Well, that's my point. "equal" is whatever it has been defined to be in a
>particular context. Because of operator overloading, this varies. There
>is no one "equals" that is defined.

"Equals" has indeed been defined in C++ as I explained. This is proven by
the fact that it used to be different in earlier versions of the language.
You're right that one can change the behavior of an operator with two sets
of two lines to mean anything one wants (including global thermonuclear
war). But I maintain that the language itself is clear on the concept.

But this is a semantic difference. I think we each know what the other is
talking about (pace the overloading/overriding business).

///ark

[Mark Wilden]

Re: compare two structs via ==

"Göran Andersson" <guffa@guffa.co mwrote in message
news:O8ncKOPqHH A.3296@TK2MSFTN GP03.phx.gbl...

>
public struct ValidDouble {
private bool _valid;
private double _value;
...
}
>
If two values have _valid set to false, you might want to consider them
equal, regardless of the value of _value;

Good example. I stand corrected.

So I'll restate :). Memberwise comparison makes sense in the vast majority
of structures and classes that I've defined or seen defined.

///ark

[Peter Duniho]

Re: compare two structs via ==

On Thu, 07 Jun 2007 10:41:17 -0700, Mark Wilden <mwilden@commun itymtm.com
wrote:

Overloading means adding another method with the same name but a
different
signature. It's easy to confuse overloading with overriding, as my own
post
proved. :)

I get your gist, but for better or worse (you may argue "worse" :) ),
redefining the behavior of an operator in C++ (and I think C# too) is
always called "overloadin g". That's why, for example, there are document
pages for "Operator Overloading" but none for "Operator Overriding".

The non-overloaded operator== that C++ automatically generates takes as
its
argument a member of the same class or a base class of the same class
(IIRC). Overloading means to leave that method alone and add another
method
that takes, for example, an int as the argument. I believe you're talking
about overriding, where a child class overrides a parent class method
(with
the same signature) to do something different than the parent.

How is the syntax for what you call an "operator override" different from
the syntax described in the documentation for "Operator Overloading"
(http://msdn2.microsoft.com/en-us/library/5tk49fh2.aspx, for example)?
And why does the C# documentation use the terms "override" and "overload"
interchangeably in this page:

http://msdn2.microsoft.com/en-us/library/ms173147.aspx

Again, I understand where you're coming from, but the real world does not
use such black & white distinctions between "overload" and "override", and
so if that's the only complaint you've got about my comment about
overloading the == operator, I think you're making too much hay overit.

>Overloading the == operator is perfectly fine for the purpose of
>modifying
>the default memberwise-compare behavior. For example, when you want two
>instances to compare as equal as long as they contain strings that are
>identical, even if the strings themselves are different instances.

>
Actually, that would be encompassed by a plain ol' memberwise compare.
Strings with identical contents are indeed equal. To just compare the
addresses would be the old bitwise comparison.

Actually, it would not. I'm talking about a class that contains
*references* to strings, and a member-wise compare will not detect the
equality case when the strings contain identical data but are different
references.

>In C# that happens all the time. By default if you compare two
>references, then even if the members are equal to each other, if the
>actual references are not equal the objects are not equal.

>
I think that would be confusing, since equality is different from
identicality (?).

I'm not sure what you mean here. You wrote "It's hard for me to imagine,
however, that two objects whose members were
equal to each other would not be equal... But I could be wrong." I
replied by pointing out that with the default reference-equality behavior,
even when members are the same, the objects are not equal.

Whether you think it would be confusing isn't relevant as far as I can
tell. The fact is, that's how it works. I gave an example of a situation
in which two objects are considered not equal even though they have
members that are equal.

"Equals" has indeed been defined in C++ as I explained.

And as I explained, what's "equal" depends on how you've defined the ==
operator. It's not an absolute.

Pete

[Jon Skeet [C# MVP]]

Re: =?ISO-8859-1?Q?compare_two _structs_via_=3 D=3D?=

Peter Duniho <NpOeStPeAdM@nn owslpianmk.comw rote:

<snip>

And why does the C# documentation use the terms "override" and "overload"
interchangeably in this page:
http://msdn2.microsoft.com/en-us/library/ms173147.aspx

It doesn't - you *override* the single method signature

bool Equals(object other)

but you *overload* the == operator by providing different signatures,
eg
bool operator ==(string x, string y)
bool operator ==(DateTime x, DateTime y)

Is there anything in the article which goes against that? I could see
anything in a brief skim, but I'm happy to look at any particular bits
more closely.

Again, I understand where you're coming from, but the real world does not
use such black & white distinctions between "overload" and "override", and
so if that's the only complaint you've got about my comment about
overloading the == operator, I think you're making too much hay over it.

I haven't been following the conversation closely enough, but overload
and override are pretty well defined in the C# and .NET world.

--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Peter Duniho]

Re: compare two structs via ==

On Thu, 07 Jun 2007 11:37:47 -0700, Jon Skeet [C# MVP] <skeet@pobox.co m>
wrote:

but you *overload* the == operator by providing different signatures,
eg
bool operator ==(string x, string y)
bool operator ==(DateTime x, DateTime y)

You seem to be in agreement with me. Mark's claim was that it's only
"overloadin g" when the types are different. However, both of your
examples show using the == operator on identical types. This is theway
I'm using the phrase "overload" as well.

Is there anything in the article which goes against that? I could see
anything in a brief skim, but I'm happy to look at any particular bits
more closely.

Look at the text in the section named "Overriding Operator ==":

By default, the operator == tests for reference equality by determining
if two references indicate the same object, so reference types do not
need to implement operator == in order to gain this functionality. When
a type is immutable, meaning the data contained in the instance cannot
be
changed, overloading operator == to compare value equality instead of
reference equality can be useful because, as immutable objects, they
can
be considered the same as long as they have the same value. Overriding
operator == in non-immutable types is not recommended.

Overloaded operator == implementations should not throw exceptions. Any
type that overloads operator == should also overload operator !=. For
example:

I do not read that text as talking about anything other than changing the
behavior of the == operator in a specific case. But within two
paragraphs, the word "override" is used only once (twice, if you count the
heading), while the word "overload" is used four times. As near as I can
tell, the words are used interchangeably .

I haven't been following the conversation closely enough, but overload
and override are pretty well defined in the C# and .NET world.

I certainly understand the distinction (even if I've confused the two on
occasion in the past :) ). However, I have only ever called the act of
changing an operator's beahvior "overloadin g", even when I haven't changed
the types involved in the comparison. Nor have I ever seen documentation
that makes a clear distinction between the two in that case. Even in the
context of C#, where the two terms are clearly distinct as applied to
methods, when talking about operators, the same care is not taken to
distinguish the two.

Pete

[Jon Skeet [C# MVP]]

Re: =?ISO-8859-1?Q?compare_two _structs_via_=3 D=3D?=

Peter Duniho <NpOeStPeAdM@nn owslpianmk.comw rote:

On Thu, 07 Jun 2007 11:37:47 -0700, Jon Skeet [C# MVP] <skeet@pobox.co m>
wrote:
>

but you *overload* the == operator by providing different signatures,
eg
bool operator ==(string x, string y)
bool operator ==(DateTime x, DateTime y)

>
You seem to be in agreement with me. Mark's claim was that it's only
"overloadin g" when the types are different. However, both of your
examples show using the == operator on identical types. This is the way
I'm using the phrase "overload" as well.

It's not that the types are different to each other within the
signature - it's that the *signatures* are different.

Basically, if the string type didn't overload the == operator with

bool operator ==(string x, string y)

then there wouldn't be any such operator. There's be the implicit

bool operator ==(object x, object y)

but that's got a different signature, so isn't overridden by the string
one. (And wouldn't be anyway, as they're always static... which I
realise I haven't included above.)

Is there anything in the article which goes against that? I could see
anything in a brief skim, but I'm happy to look at any particular bits
more closely.

>
Look at the text in the section named "Overriding Operator ==":
>
By default, the operator == tests for reference equality by determining
if two references indicate the same object, so reference types do not
need to implement operator == in order to gain this functionality. When
a type is immutable, meaning the data contained in the instance cannot
be
changed, overloading operator == to compare value equality instead of
reference equality can be useful because, as immutable objects, they
can
be considered the same as long as they have the same value. Overriding
operator == in non-immutable types is not recommended.
>
Overloaded operator == implementations should not throw exceptions. Any
type that overloads operator == should also overload operator !=. For
example:
>
I do not read that text as talking about anything other than changing the
behavior of the == operator in a specific case. But within two
paragraphs, the word "override" is used only once (twice, if you count the
heading), while the word "overload" is used four times. As near as I can
tell, the words are used interchangeably .

"Overriding " there is a mistake. As operators are implemented as static
methods, they can't be overridden. Apologies for not finding it before
- I looked for "override" which of course misses "overriding ".

I haven't been following the conversation closely enough, but overload
and override are pretty well defined in the C# and .NET world.

>
I certainly understand the distinction (even if I've confused the two on
occasion in the past :) ). However, I have only ever called the act of
changing an operator's beahvior "overloadin g", even when I haven't changed
the types involved in the comparison. Nor have I ever seen documentation
that makes a clear distinction between the two in that case.

There's no such thing as operator overriding, basically - could you
given an example where you think you *have* been doing what you'd call
operator overriding?

Even in the
context of C#, where the two terms are clearly distinct as applied to
methods, when talking about operators, the same care is not taken to
distinguish the two.

It is by some - just not by all :)

--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Peter Duniho]

Re: compare two structs via ==

On Thu, 07 Jun 2007 12:46:19 -0700, Jon Skeet [C# MVP] <skeet@pobox.co m>
wrote:

[...]
There's no such thing as operator overriding, basically - could you
given an example where you think you *have* been doing what you'd call
operator overriding?

Nope. As I mentioned, *I* always call it "overloadin g" (whether I do so
knowing the intricacies of the difference between the two is a separate
question :) ).

It's Mark who wrote "We're not talking about overloading ==, since that
would imply comparing an object to a different kind of object. We're
talking about comparing an object to an object of the same class - no
overloading." and "The behavior of operator== could be overridden"

Maybe he could offer such an example. :)

Pete

[Jon Skeet [C# MVP]]

Re: =?ISO-8859-1?Q?compare_two _structs_via_=3 D=3D?=

Peter Duniho <NpOeStPeAdM@nn owslpianmk.comw rote:

[...]
There's no such thing as operator overriding, basically - could you
given an example where you think you *have* been doing what you'd call
operator overriding?

>
Nope. As I mentioned, *I* always call it "overloadin g" (whether I do so
knowing the intricacies of the difference between the two is a separate
question :) ).
>
It's Mark who wrote "We're not talking about overloading ==, since that
would imply comparing an object to a different kind of object. We're
talking about comparing an object to an object of the same class - no
overloading." and "The behavior of operator== could be overridden"
>
Maybe he could offer such an example. :)

And definitely talking about C# at the time? If so, I agree, that's
wrong.

--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Mark Wilden]

Re: compare two structs via ==

"Peter Duniho" <NpOeStPeAdM@nn owslpianmk.comw rote in message
news:op.ttkdfxq z8jd0ej@petes-computer.local. ..
On Thu, 07 Jun 2007 10:41:17 -0700, Mark Wilden <mwilden@commun itymtm.com>
wrote:

>How is the syntax for what you call an "operator override" different from

the syntax described in the documentation for "Operator Overloading"
(http://msdn2.microsoft.com/en-us/library/5tk49fh2.aspx, for example)?

That page uses the term as I understand it. "This gives the operator more
than one meaning, or 'overloads' it." Overriding, on the other hand,
replaces the -one- meaning the operator used to have.

>And why does the C# documentation use the terms "override" and "overload"

interchangeably in this page:

http://msdn2.microsoft.com/en-us/library/ms173147.aspx

Sloppiness. :)

>Actually, it would not. I'm talking about a class that contains

*references* to strings, and a member-wise compare will not detect the
equality case when the strings contain identical data but are different
references.

Operator == for string references compares the strings' contents.

///ark

[Mark Wilden]

Re: compare two structs via ==

"Jon Skeet [C# MVP]" <skeet@pobox.co mwrote in message
news:MPG.20d260 d1cbe100971cb@m snews.microsoft .com...

Is there anything in the article which goes against that? I could see
anything in a brief skim, but I'm happy to look at any particular bits
more closely.

Near the end, they talk about adding a method to the ThreeDPoint class,
operator==(Thre eDPoint a, ThreeDPoint b) and they use both "overloadin g" and
"overriding " to describe it.

///ark

[Peter Duniho]

Re: compare two structs via ==

On Thu, 07 Jun 2007 13:23:46 -0700, Jon Skeet [C# MVP] <skeet@pobox.co m>
wrote:

And definitely talking about C# at the time? If so, I agree, that's
wrong.

At this point, I would be loathe to say for sure that he was "talking
about C# at the time". This thread is a result of discussing both C++ and
C# equality operations, and I think it was pretty clear that his original
statement to which I responded was specifically about C++ and not C#.
However, I can't comment on the more general use of his attempt to
describe the differences between "overload" and "override". I suppose he
might feel that they are used differently in C++ than in C#.

Rather than put words into his mouth, I will let Mark clarify if necessary.

Pete