.NET Framework Class Library
Object..::.Equals Method

Determines whether two Object instances are equal.

Overload List
  NameDescription
Public methodSupported by the .NET Compact FrameworkSupported by the XNA FrameworkEquals(Object)Determines whether the specified Object is equal to the current Object.
Public methodStatic memberSupported by the .NET Compact FrameworkSupported by the XNA FrameworkEquals(Object, Object)Determines whether the specified Object instances are considered equal.
Top
See Also

Reference

Object Class
Object Members
System Namespace
Tags :


Community Content

lambertwm
This tests instance equality
-- IMHO this is incorrect, lambertwm --

if

object foo = new object();
object bar = foo;

then

object.Equals(foo, bar)

evaluates to true. Variables foo and bar both point to the same object on the managed heap. If we were to say

StringBuilder foo = new StringBuilder();
foo.Append("lol");
StringBuilder bar= new StringBuilder();
bar.Append("lol");

and then examine the memory locations for foo and bar, they would be indistinguishable. The only difference between the two is that they are seperate objects on the managed heap. In this case, even though we would consider them to be the same, as they have the exact same content,

object.Equals(foo, bar)

would evaluate to false because they are two different objects.

It is the responsibility of coders to override the operators == and != and to provide overrides for both Equals methods if you want to change this behavior so that you compare the states of two objects rather than the instances of the objects when testing for equality.
Tags : contentbug

Thomas Lee
The content above ("This tests instance equality") is incorrect
It confuses Object.Equals( ) with Object.ReferenceEquals( )
Tags : contentbug

Thomas Lee
Correct Explanation
The Object.Equals method tests whether the CONTENT of two objects are the same irrespective of whether the two objects are referring to the same memory location on the heap or not

Hence the below code snippet:

StringBuilder foo = new StringBuilder();
foo.Append("lol");
StringBuilder bar= new StringBuilder();
bar.Append("lol");

foo.Equals(bar)


will always return true since both foo and bar have the CONTENT as "lol"


However the following will return false:

Object.ReferenceEquals(foo,bar)

since foo and bar are two SEPARATE objects on the heap and hence their memory references are not the same.

The exception to the above is in case of strings.

Consider the following code snippet:

string

s1 = "Hello";

string s2 = "Hello";

Console.WriteLine(s1.Equals(s2)); // this returns true since both s1 and s2 contain the string 'Hello'

Console.WriteLine(Object.ReferenceEquals(s1, s2)); // this also returns true!!


Here the Object.ReferenceEquals returns true since although s1 and s2 are two different string objects; .NET CLR handles strings in a special way and according to my understanding uses string pooling wherein two strings that have the same content will point to the same memory location.


Let me know if there is any misunderstanding on my side with respect to the above statement

Tags : contentbug?

Thomas Lee
I'm Confused here. The MS Documentation states differently
MS doc says Equals tests reference equality is this a misprint?
It's obvious that Equals test DOES test content.

"The default implementation of Equals supports reference equality for reference types, and bitwise equality for value types. Reference equality means the object references that are compared refer to the same object."
Tags : contentbug?

rac1234
Default versus overridden implementations
In response to the post by Equals, above:

No, I don't think it's a misprint. As I understand it, Microsoft are saying that the default implementation of Equals checks for reference equality, but in your own objects you may prefer to override this method to test for value equality (sameness of content). In other words, don't use the default implementation of Equals on your own objects where you are interested in whether the objects have the same value rather than whether they are the same instance. The default implementation will not give you the right answer in that case.

If you override Equals to check for value equality, you can still check for reference equality on your objects by using the ReferenceEquals method.

Another implication of this is that you should not depend on the Equals method to check for reference equality - use ReferenceEquals instead since Equals may have been overridden to test value equality.



MotMiller
I think this page mis-/under-documents object.Equals( a, b )
I'm entirely new to C# and .NET (but a long-time c/c++ developer), I was lead to this page in trying to answer a question in reading through my first C# book. I haven't seen what I believe is the correct answer clarified here yet, so I'll add my $0.02. The static function object.Equals( a, b ) appears to behave like it was written like the following (you can confirm this with a test using your own class for "a" and see that a.Equals is called, so there is no magic member by member memory comparison going on). This explains why classes which override Equals with a member by member comparison return true from object.Equals( a, b ) when a and b are not the same reference. object.Equals(a, b) returns false if "a" doesn't implement it's own Equals() (and a and are not equal references)

public static bool Equals( object a, object b )

{

if ( object.ReferenceEquals( a, b ) )

return true;

return a.Equals( b );

}




Tags :

Thomas Lee
More Clarity

check this article . says opposite

http://msdn.microsoft.com/en-us/library/ms173147(VS.80).aspx

It says a==b is for Reference equal and a.equals(b) is for Value equal


Thomas Lee
It behaves different for custom objects and immutable objects
By default, the operator == tests for reference equality. This is done by determining if two references indicate the same object. Therefore reference types do not need to implement operator == in order to gain this functionality.

When a type is immutable, meaning the data contained in the instance cannot be changed, overloading operator == to compare value equality instead of reference equality can be useful because, as immutable objects, they can be considered the same as long as they have the same value. Overriding operator == in non-immutable types is not recommended.

Also, overloaded operator == implementations should not throw exceptions. Any type that overloads operator == should also overload operator !=. For

AL202
some more found on ==
some more i found on msdn site

For predefined value types, the equality operator (==) returns true if the values of its operands are equal, false otherwise. For reference types other than string, == returns true if its two operands refer to the same object. For the string type, == compares the values of the strings.
Tags :

Page view tracker