referece equals

[Joey Callisay]

Is there a difference between Object.ReferenceEquals() method and
the == operator comparing two reference types?

 

[Daniel O'Connell [C# MVP]]

Is there a difference between Object.ReferenceEquals() method and
the == operator comparing two reference types?

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.

 

[Jon Skeet [C# MVP]]

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.

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)

 

[Joey Callisay]

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?

 

[Jon Skeet [C# MVP]]

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?

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

 

[Joey Callisay]

Thanks a lot Jon and Daniel...

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

 

[Daniel O'Connell [C# MVP]]

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)

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.