tags:

views:

146

answers:

4

My understanding of these three was:

  • .Equals() tests for data equality (for the lack of a better description). .Equals() can return True for different instances of the same object, and this is the most commonly overridden method.

  • .ReferenceEquals() tests whether or not two objects are the same instance and cannot be overridden.

  • == is the same as the ReferenceEquals() by default, but this CAN be overridden.

But C# station states:

In the object class, the Equals and ReferenceEquals methods are semantically equivalent, except that the ReferenceEquals works only on object instances. The ReferenceEquals method is static.

Now I don't get it. Can anyone shed some light on this?

+1  A: 

Your understanding of .ReferenceEquals is correct.

.Equals checks data equality for value types, and reference equality for non-value types (general objects).

.Equals can be overridden for objects to perform some form of data equality check

EDIT: Also, .ReferenceEquals can't be used on value types (well it can, but will always be false)

Luke Schafer
A: 

Have a look at this MSDN article on the subject.

I think the pertinent points are:

To check for reference equality, use ReferenceEquals. To check for value equality, use Equals or Equals.

By default, the operator == tests for reference equality by determining if two references indicate the same object, so 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.

Hope this helps!

Alastair Pitts
+2  A: 

The source of your confusion appears to be that there is a typo in the extract from C# station, which should read: "... except that the Equals works only on object instances. The ReferenceEquals method is static."


You are loosely correct about the differences in the semantic meanings of each (although "different instances of the same object" seems a little confused, it should probably read "different instances of the same type) and about which can be overridden.

If we leave that aside, let's deal with the last bit of your question, i.e. how they work with plainSystem.Objectinstances and System.Objectreferences (we need both to dodge the non-polymorphic nature of ==). Here, all three operations will work equivalentally, but with a caveat:Equalscannot be invoked onnull.

Equalsis an instance method that takes one parameter (which can benull). Since it is an instance method (must be invoked on an actual object), it can't be invoked on a null-reference.

ReferenceEquals is a static method that takes two parameters, either / both of which can be null. Since it is static (not associated with an object instance), it will not throw aNullReferenceException under any circumstances.

==is an operator, that, in this case (object), behaves identically to ReferenceEquals. It will not throw aNullReferenceExceptioneither.

To illustrate:

object o1 = null;
object o2 = new object();

//Technically, these should read object.ReferenceEquals for clarity, but this is redundant.
ReferenceEquals(o1, o1); //true
ReferenceEquals(o1, o2); //false
ReferenceEquals(o2, o1); //false
ReferenceEquals(o2, o2); //true

o1.Equals(o1) //NullReferenceException
o1.Equals(o2) //NullReferenceException
o2.Equals(o1) //false
o2.Equals(o2) //true
Ani
So is the excerpt from C# station quoted above wrong (especially if I override `.Equals()`)?
Rogue
Yes. Updated my answer.
Ani
The excerpt states **"in the `object` class"**. I think you skipped over that part? Because otherwise you would not be talking about overriding it.
Domenic
My answer is *only* about the `object` class.
Ani
@Ani: your below sentence was wrong static method can throw NullReferenceException: Since it is static (not associated with an object instance), it will not throw aNullReferenceException under any circumstances.
saj
@saj: To clarify, the sentence does not mean that static methods in general cannot throw NullReferenceExceptions. The "circumstances" that I refer to here are whether either of the references to be compared are `null`. Apologies, I thought that was implied.
Ani