The type of comparison between the current instance and the obj parameter depends on whether the current instance is a reference type or a value type.

• If the current instance is a reference type, the object.Equals(object) method tests for reference equality, and a call to the object.Equals(object) method is equivalent to a call to the object.ReferenceEquals(object, object) method. Reference equality means that the object variables that are compared refer to the same object. The following example illustrates the result of such a comparison. It defines a Person class, which is a reference type, and calls the Person class constructor to instantiate two new Person objects, person1a and person2, which have the same value. It also assigns person1a to another object variable, person1b. As the output from the example shows, person1a and person1b are equal because they reference the same object. However, person1a and person2 are not equal, although they have the same value.

  code reference: System.Object.Equals#2

• If the current instance is a value type, the object.Equals(object) method tests for value equality. Value equality means the following:

Because the object class is the base class for all types in the .NET Framework, the object.Equals(object) method provides the default equality comparison for all other types. However, types often override the object.Equals(object) method to implement value equality. For more information, see the Notes for Callers and Notes for Inheritors sections.

Notes for the wrt

When you call the object.Equals(object) method overload on a class in the wrt, it provides the default behavior for classes that don’t override object.Equals(object). This is part of the support that the .NET Framework provides for the wrt (see .NET Framework Support for Windows Store Apps and Windows Runtime). Classes in the wrt don’t inherit object, and currently don’t implement an object.Equals(object) method. However, they appear to have object.ToString, object.Equals(object), and object.GetHashCode methods when you use them in your C# or Visual Basic code, and the .NET Framework provides the default behavior for these methods.

Notes for Callers

Derived classes frequently override the object.Equals(object) method to implement value equality. In addition, types also frequently provide an additional strongly typed overload to the Equals method, typically by implementing the IEquatable`1 interface. When you call the Equals method to test for equality, you should know whether the current instance overrides object.Equals(object) and understand how a particular call to an Equals method is resolved. Otherwise, you may be performing a test for equality that is different from what you intended, and the method may return an unexpected value.

The following example provides an illustration. It instantiates three System.Text.StringBuilder objects with identical strings, and then makes four calls to Equals methods. The first method call returns true, and the remaining three return false.

code reference: System.Object.Equals#5

In the first case, the strongly typed System.Text.StringBuilder.Equals(System.Text.StringBuilder) method overload, which tests for value equality, is called. Because the strings assigned to the two System.Text.StringBuilder objects are equal, the method returns true. However, System.Text.StringBuilder does not override object.Equals(object). Because of this, when the System.Text.StringBuilder object is cast to an object, when a System.Text.StringBuilder instance is assigned to a variable of type object, and when the object.Equals(object, object) method is passed two System.Text.StringBuilder objects, the default object.Equals(object) method is called. Because System.Text.StringBuilder is a reference type, this is equivalent to passing the two System.Text.StringBuilder objects to the object.ReferenceEquals(object, object) method. Although all three System.Text.StringBuilder objects contain identical strings, they refer to three distinct objects. As a result, these three method calls return false.

You can compare the current object to another object for reference equality by calling the object.ReferenceEquals(object, object) method. In Visual Basic, you can also use the is keyword (for example, If Me Is otherObject Then ...).

Notes for Inheritors

When you define your own type, that type inherits the functionality defined by the Equals method of its base type. The following table lists the default implementation of the Equals method for the major categories of types in the .NET Framework.

For a value type, you should always override object.Equals(object), because tests for equality that rely on reflection offer poor performance. You can also override the default implementation of object.Equals(object) for reference types to test for value equality instead of reference equality and to define the precise meaning of value equality. Such implementations of object.Equals(object) return true if the two objects have the same value, even if they are not the same instance. The type's implementer decides what constitutes an object's value, but it is typically some or all the data stored in the instance variables of the object. For example, the value of a string object is based on the characters of the string; the string.Equals(object) method overrides the object.Equals(object) method to return true for any two string instances that contain the same characters in the same order.

The following example shows how to override the object.Equals(object) method to test for value equality. It overrides the object.Equals(object) method for the Person class. If Person accepted its base class implementation of equality, two Person objects would be equal only if they referenced a single object. However, in this case, two Person objects are equal if they have the same value for the Person.Id property.

code reference: System.Object.Equals#6

In addition to overriding object.Equals(object), you can implement the IEquatable`1 interface to provide a strongly typed test for equality.

The following statements must be true for all implementations of the object.Equals(object) method. In the list, x, y, and z represent object references that are not null.

• x.Equals(x) returns true, except in cases that involve floating-point types. See ISO/IEC/IEEE 60559:2011, Information technology -- Microprocessor Systems -- Floating-Point arithmetic.

• x.Equals(y) returns the same value as y.Equals(x).

• x.Equals(y) returns true if both x and y are NaN.

• If (x.Equals(y) && y.Equals(z)) returns true, then x.Equals(z) returns true.

• Successive calls to x.Equals(y) return the same value as long as the objects referenced by x and y are not modified.

• x.Equals(null) returns false.

Implementations of object.Equals(object) must not throw exceptions; they should always return a value. For example, if obj is null, the object.Equals(object) method should return false instead of throwing an ArgumentNullException.

Follow these guidelines when overriding object.Equals(object):

• Types that implement IComparable must override object.Equals(object).

• Types that override object.Equals(object) must also override object.GetHashCode; otherwise, hash tables might not work correctly.

• You should consider implementing the IEquatable`1 interface to support strongly typed tests for equality. Your IEquatable`1.Equals(`0) implementation should return results that are consistent with object.Equals(object).

• If your programming language supports operator overloading and you overload the equality operator for a given type, you must also override the object.Equals(object) method to return the same result as the equality operator. This helps ensure that class library code that uses object.Equals(object) (such as ArrayList and Hashtable) behaves in a manner that is consistent with the way the equality operator is used by application code.

Guidelines for Reference Types

The following guidelines apply to overriding object.Equals(object) for a reference type:

• Consider overriding object.Equals(object) if the semantics of the type are based on the fact that the type represents some value(s).

• Most reference types must not overload the equality operator, even if they override object.Equals(object). However, if you are implementing a reference type that is intended to have value semantics, such as a complex number type, you must override the equality operator.

• You should not override object.Equals(object) on a mutable reference type. This is because overriding object.Equals(object) requires that you also override the object.GetHashCode method, as discussed in the previous section. This means that the hash code of an instance of a mutable reference type can change during its lifetime, which can cause the object to be lost in a hash table.

Guidelines for Value Types

The following guidelines apply to overriding object.Equals(object) for a value type:

• If you are defining a value type that includes one or more fields whose values are reference types, you should override object.Equals(object). The object.Equals(object) implementation provided by ValueType performs a byte-by-byte comparison for value types whose fields are all value types, but it uses reflection to perform a field-by-field comparison of value types whose fields include reference types.

• If you override object.Equals(object) and your development language supports operator overloading, you must overload the equality operator.

• You should implement the IEquatable`1 interface. Calling the strongly typed IEquatable`1.Equals(`0) method avoids boxing the obj argument.

Example 1:

The following example contains two calls to the default implementation of object.Equals(object) .

using System;
class MyClass {
   static void Main() {
      Object obj1 = new Object();
      Object obj2 = new Object();
      Console.WriteLine(obj1.Equals(obj2));
      obj1 = obj2; 
      Console.WriteLine(obj1.Equals(obj2)); 
   }
}

The output is

Example 2:

The following example shows a Point class that overrides the object.Equals(object) method to provide value equality and a class Point3D, which is derived from Point . Because Point's override of object.Equals(object) is the first in the inheritance chain to introduce value equality, the Equals method of the base class (which is inherited from object and checks for referential equality) is not invoked. However, Point3D.Equals invokes Point.Equals because Point implements Equals in a manner that provides value equality.

using System;
public class Point: object {
 int x, y;
 public override bool Equals(Object obj) {
 //Check for null and compare run-time types.
 if (obj == null || GetType() != obj.GetType()) return false;
 Point p = (Point)obj;
 return (x == p.x) && (y == p.y);
 }
 public override int GetHashCode() {
 return x ^ y;
 }
}

class Point3D: Point {
 int z;
 public override bool Equals(Object obj) {
 return base.Equals(obj) && z == ((Point3D)obj).z;
 }
 public override int GetHashCode() {
 return base.GetHashCode() ^ z;
 }
}

The Point.Equals method checks that the obj argument is non-null and that it references an instance of the same type as this object. If either of those checks fail, the method returns false. The object.Equals(object) method uses object.GetType to determine whether the run-time types of the two objects are identical. (Note that typeof is not used here because it returns the static type.) If instead the method had used a check of the form obj is Point , the check would return true in cases where obj is an instance of a subclass of Point , even though obj and the current instance are not of the same runtime type. Having verified that both objects are of the same type, the method casts obj to type Point and returns the result of comparing the instance variables of the two objects.

In Point3D.Equals , the inherited Equals method is invoked before anything else is done; the inherited Equals method checks to see that obj is non-null, that obj is an instance of the same class as this object, and that the inherited instance variables match. Only when the inherited Equals returns true does the method compare the instance variables introduced in the subclass. Specifically, the cast to Point3D is not executed unless obj has been determined to be of type Point3D or a subclass of Point3D .

Example 3:

In the previous example, operator == (the equality operator) is used to compare the individual instance variables. In some cases, it is appropriate to use the object.Equals(object) method to compare instance variables in an Equals implementation, as shown in the following example:

using System;
class Rectangle {
 Point a, b;
 public override bool Equals(Object obj) {
 if (obj == null || GetType() != obj.GetType()) return false;
 Rectangle r = (Rectangle)obj;
 //Use Equals to compare instance variables
 return a.Equals(r.a) && b.Equals(r.b);
 }
 public override int GetHashCode() {
 return a.GetHashCode() ^ b.GetHashCode();
 }
}

Example 4:

In some languages, such as C#, operator overloading is supported. When a type overloads operator ==, it should also override the object.Equals(object) method to provide the same functionality. This is typically accomplished by writing the Equals method in terms of the overloaded operator ==. For example:

using System;
public struct Complex {
 double re, im;
 public override bool Equals(Object obj) {
 return obj is Complex && this == (Complex)obj;
 }
 public override int GetHashCode() {
 return re.GetHashCode() ^ im.GetHashCode();
 }
 public static bool operator ==(Complex x, Complex y) {
 return x.re == y.re && x.im == y.im;
 }
 public static bool operator !=(Complex x, Complex y) {
 return !(x == y);
 }
}

Because Complex is a C# struct (a value type), it is known that there will be no subclasses of Complex . Therefore, the object.Equals(object) method need not compare the GetType() results for each object, but can instead use the is operator to check the type of the obj parameter.