469,283 Members | 2,263 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,283 developers. It's quick & easy.

interactions between operator== and the two Object.Equals methods


Having difficulty getting myself clear on how a type's operator== fits
in with Object.Equals.

Let's just consider reference types.

The default operator== tests for object identity (reference)
equivalence. You can override it if you like.

Object has ... public virtual bool Equals(object);

The default implementation also gives you a reference equality test.
You can override it if you like.

So ... why two different ways of achieving the same thing? What's one
for? What's the other for? When would you override one? When would you
override the other? I'm asking how these two methods are the same and
also how they are different!!! Let's just consider reference types

I did notice if you implement IComparable you must provide an
implementation of Equals.

I also noticed this advice (Object.Equals help): "if your programming
language supports operator overloading and if you choose to overload
the equality operator for a given type, that type should override the
Equals method. Such implementations of the Equals method should return
the same results as the equality operator."

If they need to be consistent why *two* different ways to achieve the
same functionality - isn't this asking for trouble?!

And then it says this seemingly contradictory quote: "most reference
types should not overload the equality operator, even if they override

Eek - it's pretty clear now that I need some help from someone
understanding the rationale behind == and .Equals!!!

As a finale, what's the point of the static Equals method on Object?
public static bool Equals(object objA, object objB);

What does it do that objA.Equals(objB) would not achieve?

Cheers for listening and hope someone can help my lack of

Emma Middlebrook
Nov 15 '05 #1
2 9174

Equals is also used when comparing e.g. strings. You can implement your own
ways to compare objects. A wellknown fact, but I just wanted to point it out
to you! :)

venlig hilsen / with regards
anders borum
Nov 15 '05 #2

"emma middlebrook" <em**************@fastmail.fm> wrote in message
news:e2**************************@posting.google.c om...
Having difficulty getting myself clear on how a type's operator== fits in with Object.Equals.

I suspect some of the confusion comes from the fact that not all .Net
languages support operator overloading (e.g. vb.net). Those langauges
will still allow you to override object.Equals. In C# we get the
additional benefit of having more concise code.

That is, if we implemented ComplexNumber as a class (even though a
struct probably makes more sense):
ComplexNumber a = new ComplexNumber (10, 20);
ComplexNumber b = new ComplexNumber (10, 20);

we could override equals to provide syntax like
in order to get value-type equality checking.
We should also override the static method so that
a.Equals(b) is the same as ComplexNumber.Equals(a,b);

In C#, we would probably want to override the operator also, thus
(a==b) would return true.

I believe the online help was saying that if you've changed the ==
operator to make it more convenient to compare using value-type
semantics, then you should change the Equals method so that they both
"do the same thing". That is, it would be disturbing in the above
example if
a==b returned true but a.Equals(b) returned false. That would only
happen if you overload the operator but forget the method.

For most reference types, overloading the operator == is a bad idea,
IMO. Other languages will assume that the == operator means reference
type equality. They would only be used to Equals() to test for value

In the above example, it would be fine to have an implementation
a.Equals(b) = true (since they have similar values)
but have a == b still performing reference equality and hence return
false (since the two objects are unique instances of ComplexNumber).

I guess the help should have said that (a == b) should always behave
the same as either a.Equals(b) or Object.ReferenceEquals(a,b), with
the preference being ReferenceEquals.

Nov 15 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

45 posts views Thread by Jordan Rastrick | last post: by
3 posts views Thread by #Hai | last post: by
4 posts views Thread by Peter | last post: by
17 posts views Thread by Chris | last post: by
5 posts views Thread by Brian Keating | last post: by
9 posts views Thread by Tony | last post: by
12 posts views Thread by mathboy2 | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.