Equals

[shapper]

Hello,

Very often in some code I see the use of Equals instead of ==:

Equals(context.PropertyValue, null)

or

Average.Equals(8.5)

Is there any difference between using == or Equals?

Should I use Equals?

Thanks,
Miguel

[Mark Rae [MVP]]

"shapper" <mdm...@gmail.com> wrote in message
news:cc279aed-41e9-4692...@k17g2000yqb.googlegroups.com...

> Is there any difference between using == or Equals?

http://tinyurl.com/yafcwo2

--
Mark Rae
ASP.NET MVP
http://www.markrae.net

[Peter Duniho]

On Thu, 01 Oct 2009 03:28:11 -0700, shapper <mdm...@gmail.com> wrote:

> [...]

> Is there any difference between using == or Equals?

Yes.

> Should I use Equals?

It depends on what behavior you want.

If there is an == operator overload, and if you are using variables typed
as the actual type for which the overload you want to use is defined, then
the two should be the same. But otherwise, calling the Equals() method is
generally preferred because it provides reliable behavior regardless of
the declared type of the variables being used.

The == overload used is determined at compile-time, without run-time type
information about the objects being compared, while the Equals() method
called, being a virtual method in the Object class, is determined at
run-time based on the type of the objects being compared.

Very rarely, you _don't_ want the polymorphic behavior of Equals(). For
example, using the == operator is a shortcut for calling the
Object.ReferenceEquals() method, as long as the two variables being used
are both declared as System.Object types (not usually the case, but it
does come up).

IMHO, polymorphic types with Equals() method overrides and the == operator
being overloaded don't mix very well, because of this disparity. When
both have been done, it can lead to some subtle bugs. And in fact, you do
have to be pretty careful when dealing with System.String objects to make
sure you're using a comparison that produces the expected results in a
given context. But, as long as you remember to only ever use the ==
operator in a context where you know the exact type of the objects being
compared and that type is the type of the variables being compared, you
should be fine.

Eric Lippert's most recent blog post actually touches on this, somewhat
tangentially, as part of a discussion on the string interning behavior in
.NET:
http://blogs.msdn.com/ericlippert/archive/2009/09/28/string-interning-and-string-empty.aspx

Pete

[shapper]

On Oct 1, 6:03 pm, "Peter Duniho" <no.peted.s...@no.nwlink.spam.com>
wrote:

> .NET:http://blogs.msdn.com/ericlippert/archive/2009/09/28/string-interning...
>
> Pete

Thank you Pete more the explanation and for the link of the Eric
Lippert's blog post.

It is more clear now ...

Thank You,
Miguel

[Ben Voigt [C++ MVP]]

> The == overload used is determined at compile-time, without run-time type
> information about the objects being compared, while the Equals() method
> called, being a virtual method in the Object class, is determined at
> run-time based on the type of the objects being compared.

as a result, testing

x == null

will work ok, while

x.Equals(y)

is going to be trouble if x might be null