compare two structs via ==

[Peter Duniho]

[...]
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 "overloading" (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]]

[...]
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 "overloading" (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.

 

[Mark Wilden]

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]

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==(ThreeDPoint a, ThreeDPoint b) and they use both "overloading" and
"overriding" to describe it.

///ark

 

[Peter Duniho]

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

 

[Peter Duniho]

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

And? I'm not talking about operator==(string, string). I'm talkingabout
operator==(myclass, myclass) where the class "myclass" has members that
are references to strings.

Pete

 

[Mark Wilden]

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"

Yup, I forgot that in C# (as opposed to C++, which was the original subject
of my post), operators are always static.

Nevertheless, the distinction between the terms "overload" and "override" is
well-understood in the C++ world - even by me (I think). Just consider the
English meaning of the terms. Overriding implies that the original behavior
is gone - it is overridden, like the override switch for autopilot.
Overloading means that the method name has been "loaded" with another
meaning - the original behavior is still there. Think of a burro.

///ark

 

[Mark Wilden]

And? I'm not talking about operator==(string, string). I'm talking about
operator==(myclass, myclass) where the class "myclass" has members that
are references to strings.

Right. And a memberwise comparison would report those two objects (of
myclass) to be equal. No need to overload/override.

///ark

 

[Mark Wilden]

I think it was pretty clear that his original statement to which I
responded was specifically about C++ and not C#.

You are correct. I was talking about how the default for memberwise
comparison in C++ worked well enough that I didn't know why C# didn't use
it.

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

No, each term has the same meaning in both languages (as well as English).

 

[Peter Duniho]

Right. And a memberwise comparison would report those two objects (of
myclass) to be equal. No need to overload/override.

Well, I should clarify it appears. When I write "string", I'm assuming
the old, pre-.NET days when my strings were all actually char arrays. I
can't speak to the use of the actual "String" class in managed C++, but
the old C++ behavior certainly did not pick up on references to strings
that are different, but which contained the same characters.

Without an operator== overload that would explicitly check equality on the
string arrays, the class instances would be "not equal" even though the
members are "equal".

Again, it all depends on how you're defining "equality". In any case,
even if you insist on defining "equal" to invalidate the example I offer,
the fact remains that in C++, the "definition" of equality depends on how
the operator == has been overloaded. Which is, as it happens, my original
point.

Interesting how a single sentence could digress into such a convoluted
discussion.

Pete

 

[Mark Wilden]

Without an operator== overload that would explicitly check equality on the
string arrays, the class instances would be "not equal" even though the
members are "equal".

Right - in -that- part of the discussion, I (think I) was referring to the
(mythical) memberwise comparison that C# doesn't provide, but which I
thought it should. Perfectly clear, n'est-ce pas?

///ark