11

I often see in source codes the usage of if (object.ReferenceEquals(myObject, null)) for checking if myObject is null instead of if (myObject == null) which I am familiar with.

Is there any particular reason (like speed, readability, etc) for using the first way instead of the second one? Which one do you use?

Thank you in advance.

Dummy01
  • 1,985
  • 1
  • 16
  • 21

6 Answers6

6

When using ReferenceEquals you make sure that no special handling (overloaded operator for instance) is being applied. This also leads to different results if used with unbound generics.

Lucero
  • 59,176
  • 9
  • 122
  • 152
6

Simple things are usually the most efficient : (myObject == null) is more performant

Look at this article

Mehdi LAMRANI
  • 11,289
  • 14
  • 88
  • 130
  • The referenced article, while a seemingly interesting read, but targets .NET 2.0. At the time .NET 4.0 was out for some time and in it, there is no difference between using `(object) myObj == null` and `ReferenceEquals`. However, your suggestion in this post (while 7 yrs ago) is very dangerous (as explained in the linked article) and should certainly *not* be used without a cast (unless you truly want to use a possible overload, but then "performant" has nothing to do with it). – Abel Nov 19 '17 at 01:44
3

Take a look at this interesting article

Performance Tip: Prefer (((Object) x)== null) to Object.ReferenceEquals(x,null)

CSchulz
  • 10,882
  • 11
  • 60
  • 114
Jan
  • 15,802
  • 5
  • 35
  • 59
  • That article is outdated, it comes to the wrong conclusions. The IL is exactly equal for both approaches in .NET 4.0 and above. You can see that easily by trying the examples in that article. For readability I would suggest `ReferenceEquals`. – Abel Nov 19 '17 at 01:46
2

The == operator can be overloaded by class implementations, so it might not do a reference comparision (though it probably should with nulls). object.ReferenceEquals can't, so it reliably always does a reference comparision.

Cheers Matthias

Matthias Meid
  • 12,455
  • 7
  • 45
  • 79
2

The ReferenceEquals method cannot be overridden and so you can always be certain that the comparison is going to compare the object references and not be passed to some override of the Equals method.

Lazarus
  • 41,906
  • 4
  • 43
  • 54
2

They usually have the same effect, although they compile to different things. if (myObject == null) results in a ceq opcode, which I'd expect to compile to quicker code. object.ReferenceEquals is a method call like any other.

They're different when myObject has an operator= method; when this is present, your code calls into this method instead of using ceq. operator= can then do whatever it likes.

Always if (myObject == null) unless you have a reason not to.

Tim Robinson
  • 53,480
  • 10
  • 121
  • 138
  • Just because it's a method call in IL doesn't mean it's a method call once the jitter is finished. Reference equals is very short, so it is likely to be inlined. And it's content is just `obj1==obj2`, so I'd expect exactly the same performance as with ==, but it casts the arguments to object, so any overloaded == operators don't affect it. – CodesInChaos Dec 10 '10 at 11:14
  • It's _not_ a "method call like any other", when compiled, the IL will _not_ have that method call in it, instead, special IL codes are used, which are equal (since .NET 4.0) for both approaches. @CodesInChaos is right, it is exactly the same performance (and IL). – Abel Nov 19 '17 at 01:49