-6

Possible Duplicate:
C# difference between == and .Equals()

For comparing two variables we can use == or Equals method. for example,

        string a = new string(new char[] {'a', 'b', 'c', 'd'});
        string b = new string(new char[] {'a', 'b', 'c', 'd'});

        Console.WriteLine (a==b);
        Console.WriteLine (a.Equals(b));

My question is When should I use == and when should I use Equals? Is there any difference between the two?

Community
  • 1
  • 1
Jainendra
  • 24,713
  • 30
  • 122
  • 169
  • Next time, search before you ask... there is an exact duplicate of your question already! – balexandre Apr 30 '12 at 07:11
  • If you are a component maker, you'll encounter the `==` inconsistencies. Better use anyTypeHere.Equals, or object.Equals http://www.ienablemuch.com/2011/08/getting-default-of-type-during-runtime.html – Michael Buen Apr 30 '12 at 07:19

3 Answers3

7

== is an operator, which, when not overloaded means "reference equality" for classes (and field-wise equality for structs), but which can be overloaded. A consequence of it being an overload rather than an override is that it is not polymorphic.

Equals is a virtual method; this makes it polymorphic, but means you need to be careful not to call it on null instances.

As a rule of thumb:

  • if you know the type of something, and know it has an == overload (most core types such as string, int, float, etc have == meanings), then use ==
  • if you don't know the type, Equals(a,b) may be recommended, as this avoids the null issue
  • if you really want to check for the same instance (reference equality), consider using ReferenceEquals(a,b), as this will work even if the == is overloaded and Equals overridden
  • when using generics, consider EqualityComparer<T>.Default.Equals(a,b) which avoids the null issue, supports Nullable-of-T, and supports IEquatable-of-T
Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • If == is comparison by reference, then why comparison between two primitive types returns true if the values are equal? Like this: ~~~ a = 3 // has it's own reference b = 3 // has it's own different reference a == b // is true ~~~ Why? The references are different so this should have returned false, right? – arm May 27 '20 at 08:34
  • 1
    @arm I didn't say "== is comparison by reference" - I said **when not overloaded** it means reference equality for classes, and field-wise equality for structs; "primitives" is a loose term - it looks like you're talking about `System.Int32` (aka `int`); `int` *does* overload `==` (including at the compiler level), and *unless you are boxing*: those **aren't references at all** - they are values, so it is meaningless to ask if the references are equal or different – Marc Gravell May 27 '20 at 08:49
5

This post by John Skeet will answer your question:

So, when should you use which operator? My rule of thumb is that for almost all reference types, use Equals when you want to test equality rather than reference identity. The exception is for strings - comparing strings with == does make things an awful lot simpler and more readable but you need to remember that both sides of the operator must be expressions of type string in order to get the comparison to work properly.

For value types, I'd normally use == for easier-to-read code. Things would get tricky if a value type provided an overload for == which acted differently to Equals, but I'd consider such a type very badly designed to start with.

[Author: Jon Skeet]

http://blogs.msdn.com/b/csharpfaq/archive/2004/03/29/when-should-i-use-and-when-should-i-use-equals.aspx

Dor Cohen
  • 16,769
  • 23
  • 93
  • 161
1

When == is used on an object type, it'll resolve to System.Object.ReferenceEquals.

Equals is just a virtual method and behaves as such, so the overridden version will be used (which, for string type compares the contents).

https://stackoverflow.com/a/814880/655293

Community
  • 1
  • 1
HW90
  • 1,953
  • 2
  • 21
  • 45
  • 1
    Strictly speaking, it never "resolves" to ReferenceEquals - it simply loads the two references and does a "ceq" or "beq" (it doesn't do a "call" to ReferenceEquals) – Marc Gravell Apr 30 '12 at 08:01