469,267 Members | 1,050 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,267 developers. It's quick & easy.

compairing to null when operator is overridden

I'm having a difficulty compairing null to a class object whose "equal"
operator is overridden.. Consider the following:

class Foo
{
// ...
public static bool operator==(Foo f1, Foo f2)
{ return (f1.n == f2.n); }

Now the following throws:
Foo foo = new Foo();
if(null == foo) // throws System.NullReferenceException
{ //

If I check for null inside my operator override, it causes stack overflow.
public static bool operator==(Foo f1, Foo f2)
{
if(null == t1) ... // stack overflow

So my question is what's the correct way to handle null comparison when your
class overrides the equal operator?

Nov 17 '05 #1
8 1896
The correct way to override == is to first override .Equals and
..HashCode and then call .Equals method. You can check for null values
inside the .Equals method.

Your overloaded operator will look like :

public static bool operator==(Foo f1, Foo f2)
{ return (f1.Equals(f2)); }

and the .Equals method can look like :

public override bool Equals(object obj)
{
if (obj == null)
return false;
return ((Foo)obj).n.Equals(n);
}

Nov 17 '05 #2
Pesso <pe***@no.where> wrote:
I'm having a difficulty compairing null to a class object whose "equal"
operator is overridden.. Consider the following:

class Foo
{
// ...
public static bool operator==(Foo f1, Foo f2)
{ return (f1.n == f2.n); }

Now the following throws:
Foo foo = new Foo();
if(null == foo) // throws System.NullReferenceException
{ //

If I check for null inside my operator override, it causes stack overflow.
public static bool operator==(Foo f1, Foo f2)
{
if(null == t1) ... // stack overflow

So my question is what's the correct way to handle null comparison when your
class overrides the equal operator?


Either cast t1 to object first, or use object.ReferenceEquals.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 17 '05 #3
On 10 Sep 2005 14:06:56 -0700, "Tasos Vogiatzoglou"
<tv*****@gmail.com> wrote:
The correct way to override == is to first override .Equals and
.HashCode and then call .Equals method. You can check for null values
inside the .Equals method.

Your overloaded operator will look like :

public static bool operator==(Foo f1, Foo f2)
{ return (f1.Equals(f2)); }


That's not quite enough, you must check f1 against null before
attempting to invoke a method on it. Add the following line before
the return:

if ((object) f1 == null) return ((object) f2 == null);

Additionally, your Object.Equals override won't get called by
operator== if the class also provides a strongly-typed overload of
Equals, and in such a strongly-typed overload you'll once again have
to use an object cast for the null check.
--
http://www.kynosarges.de
Nov 17 '05 #4
On Sat, 10 Sep 2005 22:09:41 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote:
Either cast t1 to object first, or use object.ReferenceEquals.


Do you know the IL generated for ReferenceEquals? If it's a method
call you should use an object cast instead because ((object) x ==
null) gets compiled into optimal IL (a single null comparison opcode).
--
http://www.kynosarges.de
Nov 17 '05 #5
Christoph Nahr <ch************@kynosarges.de> wrote:
On Sat, 10 Sep 2005 22:09:41 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote:
Either cast t1 to object first, or use object.ReferenceEquals.


Do you know the IL generated for ReferenceEquals? If it's a method
call you should use an object cast instead because ((object) x ==
null) gets compiled into optimal IL (a single null comparison opcode).


It will certainly be a method call in IL, but of course it may well be
inlined by the JIT. However, I wouldn't use that as the main criterion
at all - for me, it depends which you find most readable. Use the most
readable form until you've got good evidence that the code in question
is actually a bottleneck in your application.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 17 '05 #6
On Sun, 11 Sep 2005 09:42:50 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote:
It will certainly be a method call in IL, but of course it may well be
inlined by the JIT.
Good point, my mistake. Object.ReferenceEquals is a static method
that contains just the single line "return (x == y)" so it's certainly
going to be inlined, and the effect will be the same... at least when
optimization is turned on.
However, I wouldn't use that as the main criterion
at all - for me, it depends which you find most readable. Use the most
readable form until you've got good evidence that the code in question
is actually a bottleneck in your application.


Personally I don't see any difference in readability between the two
variants -- the operator== version would be more readable if you
didn't need the object cast, but since you do it's a wash.

In general, though, if there's one place where premature optimization
is a good idea it's in infrastructure methods such as equality tests.
These low-level methods are likely to show up at the end of a lot of
call trees, and so will have a broad influence on your application's
performance regardless of the presence of specific hotspots.

If you never pay any attention to performance before profiling you may
well end up with an application that's quite sluggish everywhere, but
does not have any bottlenecks that are detectable by profiling...
--
http://www.kynosarges.de
Nov 17 '05 #7
Christoph Nahr <ch************@kynosarges.de> wrote:
On Sun, 11 Sep 2005 09:42:50 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote:
It will certainly be a method call in IL, but of course it may well be
inlined by the JIT.
Good point, my mistake. Object.ReferenceEquals is a static method
that contains just the single line "return (x == y)" so it's certainly
going to be inlined, and the effect will be the same... at least when
optimization is turned on.


Yup.
However, I wouldn't use that as the main criterion
at all - for me, it depends which you find most readable. Use the most
readable form until you've got good evidence that the code in question
is actually a bottleneck in your application.


Personally I don't see any difference in readability between the two
variants -- the operator== version would be more readable if you
didn't need the object cast, but since you do it's a wash.


It's very much a matter of taste. I don't find either particularly more
readable, but I think object.ReferenceEquals is perhaps a little more
explicit.
In general, though, if there's one place where premature optimization
is a good idea it's in infrastructure methods such as equality tests.
These low-level methods are likely to show up at the end of a lot of
call trees, and so will have a broad influence on your application's
performance regardless of the presence of specific hotspots.

If you never pay any attention to performance before profiling you may
well end up with an application that's quite sluggish everywhere, but
does not have any bottlenecks that are detectable by profiling...


You *may* do - but in my experience, you don't actually do so. Firstly,
it would depend on how often Equals was actually called - I don't find
myself calling Equals on my own types on a very regular basis.

Secondly, the architecture design is still more likely to be the
overwhelming factor, IMO. *That* is very hard to change later on,
whereas improving the performance of "leaf" methods like Equals is very
easy to do *if* you need to.

(Profiling *would* show this up to be a bottleneck if it genuinely was,
IMO - if you can see a significant portion of your time spent in Equals
methods, that should ring alarm bells.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 17 '05 #8
You are correct... I didn't thing the other situations... My mistake
....

Nov 17 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by user | last post: by
102 posts views Thread by junky_fellow | last post: by
3 posts views Thread by Mark Oliver | last post: by
2 posts views Thread by Tom Smith | last post: by
17 posts views Thread by sonu | last post: by
14 posts views Thread by Hunk | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.