referece equals

  • Thread starter Thread starter Joey Callisay
  • Start date Start date
J

Joey Callisay

Is there a difference between Object.ReferenceEquals() method and
the == operator comparing two reference types?
 
Joey Callisay said:
Is there a difference between Object.ReferenceEquals() method and
the == operator comparing two reference types?
Click to expand...

Read this article:
http://yoda.arachsys.com/csharp/faq/#equals

Everything there holds true to this, except Object.ReferenceEquals can be
used to guarentee referential equality in all cases, whereas Equals and ==
offer no guarenttees about how equality will be determined.
 
Daniel O'Connell said:
Read this article:
http://yoda.arachsys.com/csharp/faq/#equals

Everything there holds true to this, except Object.ReferenceEquals can be
used to guarentee referential equality in all cases, whereas Equals and ==
offer no guarenttees about how equality will be determined.
Click to expand...

Well, except that if either of the parameters is an expression of type
object, it's guaranteed that the result will be the same as
Object.ReferenceEquals. In other words:

x==(object)y is always the same as
Object.ReferenceEquals(x, y)
 
Here is a revision of my question:

I have some old code here. A number of controls are linked to a common
eventhandler, since there is some interesection on the implementation. At
the eventhandler declaration, to test for the cases, it uses the Name
property of the controls and compare it to the sender's Name. I believe
this is not a good practice and comparing if both the control instance and
the sender points to the same control is a better implementation. My hunch
is to use the static Object.ReferenceEquals. Any views?
 
Joey Callisay said:
Here is a revision of my question:

I have some old code here. A number of controls are linked to a common
eventhandler, since there is some interesection on the implementation. At
the eventhandler declaration, to test for the cases, it uses the Name
property of the controls and compare it to the sender's Name. I believe
this is not a good practice and comparing if both the control instance and
the sender points to the same control is a better implementation. My hunch
is to use the static Object.ReferenceEquals. Any views?
Click to expand...

It entirely depends on what semantics you want. If you want to be able
to construct a new control with an old name and still get a match, you
need to use name comparison, otherwise you could use
Object.ReferenceEquals or just == (assuming it hasn't been overloaded
for those types).
 
Thanks a lot Jon and Daniel...

Jon Skeet said:
It entirely depends on what semantics you want. If you want to be able
to construct a new control with an old name and still get a match, you
need to use name comparison, otherwise you could use
Object.ReferenceEquals or just == (assuming it hasn't been overloaded
for those types).
Click to expand...
 
Jon Skeet said:
Well, except that if either of the parameters is an expression of type
object, it's guaranteed that the result will be the same as
Object.ReferenceEquals. In other words:

x==(object)y is always the same as
Object.ReferenceEquals(x, y)
Click to expand...

Point taken.
What I mean to say was that ==, by itself, offers no guarentees, while
Object.ReferenceEquals does, if you know your operands, you can predict the
operation of == to some extent, for example string,string is a valuish
comparison. I'm not really sure of its exact internal semantics, it may well
do *some* referential checking as well for optimization reasons. However, it
will return true if the value of the two strings are equal. And as Jon
pointed out above, if one is object you get a reference comparison.

 
Back
Top