C# .Equals(), .ReferenceEquals() and == operator
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?
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, ie how they work with plain System.Object instances and System.Object references (we need both to dodge the non-polymorphic nature of == ). Here, all three operations will work equivalentally, but with a caveat: Equals cannot be invoked on null .
Equals is an instance method that takes one parameter (which can be null ). 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 a NullReferenceException under any circumstances.
== is an operator, that, in this case ( object ), behaves identically to ReferenceEquals . It will not throw a NullReferenceException either.
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
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!
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)
链接地址: http://www.djcxy.com/p/58486.html