-- 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.

It confuses Object.Equals( ) with Object.ReferenceEquals( )

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

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."

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.

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 );

}

In short, if a and b are objects of the same class then:

a.Equals(b), Object.Equals(a,b) and object.ReferenceEquals(a,b) behave the same if the class does not override the Equals method.

If the class overrides the Equals method then; a.Equals(b) and Object.Equals(a,b) behave the same (i.e. check values as per override logic), which is different from Object.ReferenceEquals(a,b) which just checks object reference