469,282 Members | 1,977 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

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

Explicitly cast a string to an object before testing if null

I just happened to be looking through the implementation of the
System.Version class in the SSCLI and one of the constructors starts
like this:

public Version(String version) {
if ((Object) version == null)
throw new ArgumentNullException("version");

Does anyone have any ideas why the string parameter is being cast to an
object prior to checking for null? Is there some circumstance where not
having the explicit cast to object would cause the test for null to not
work as expected?

--
-glenn-

Nov 16 '05 #1
8 3899
On 15 Feb 2005 08:47:28 -0800, "GlennDoten" <gd****@gmail.com> wrote:
I just happened to be looking through the implementation of the
System.Version class in the SSCLI and one of the constructors starts
like this:

public Version(String version) {
if ((Object) version == null)
throw new ArgumentNullException("version");

Does anyone have any ideas why the string parameter is being cast to an
object prior to checking for null? Is there some circumstance where not
having the explicit cast to object would cause the test for null to not
work as expected?


Yes -- if the object in question is of a type that overrides
operator== and does funny things when comparing to a null reference.
However, such an implementation would be considered defective by any
standard and should be fixed rather than worked around!

But in fact, it's a good idea to cast to object before comparing to
null whenever operator== is overriden by the compared type, even if it
doesn't do funny things. The reason is that it's much faster.

When applied to System.Object the "==" and "!=" tokens directly
translate to a single IL instruction each. But when applied to a type
that overrides operator== method calls are generated instead.

I suspect it's for this latter reason that the object cast exists.
System.String does override operator== to achieve "value type
semantics", as they call it; i.e. two strings are equal if they have
the same contents. The object cast saves a method call.
--
http://www.kynosarges.de
Nov 16 '05 #2
Christoph Nahr wrote:
On 15 Feb 2005 08:47:28 -0800, "GlennDoten" <gd****@gmail.com> wrote:

I just happened to be looking through the implementation of the
System.Version class in the SSCLI and one of the constructors starts
like this:

public Version(String version) {
if ((Object) version == null)
throw new ArgumentNullException("version");

Does anyone have any ideas why the string parameter is being cast to an
object prior to checking for null? Is there some circumstance where not
having the explicit cast to object would cause the test for null to not
work as expected?

Yes -- if the object in question is of a type that overrides
operator== and does funny things when comparing to a null reference.
However, such an implementation would be considered defective by any
standard and should be fixed rather than worked around!

But in fact, it's a good idea to cast to object before comparing to
null whenever operator== is overriden by the compared type, even if it
doesn't do funny things. The reason is that it's much faster.

When applied to System.Object the "==" and "!=" tokens directly
translate to a single IL instruction each. But when applied to a type
that overrides operator== method calls are generated instead.

I suspect it's for this latter reason that the object cast exists.
System.String does override operator== to achieve "value type
semantics", as they call it; i.e. two strings are equal if they have
the same contents. The object cast saves a method call.

It's interestinig - i was always under impression that overriden operators are in fact virtual, in
other words if you do (Object)StringVariable == null, it would do StringVariable == null, as happens
with virtual functions...

But i guess i had a wrong idea of how operators work...
Nov 16 '05 #3


"Christoph Nahr" <ch************@kynosarges.de> wrote in message
news:7q********************************@4ax.com...
On 15 Feb 2005 08:47:28 -0800, "GlennDoten" <gd****@gmail.com> wrote:
I just happened to be looking through the implementation of the
System.Version class in the SSCLI and one of the constructors starts
like this:

public Version(String version) {
if ((Object) version == null)
throw new ArgumentNullException("version");

Does anyone have any ideas why the string parameter is being cast to an
object prior to checking for null? Is there some circumstance where not
having the explicit cast to object would cause the test for null to not
work as expected?


Yes -- if the object in question is of a type that overrides
operator== and does funny things when comparing to a null reference.
However, such an implementation would be considered defective by any
standard and should be fixed rather than worked around!

But in fact, it's a good idea to cast to object before comparing to
null whenever operator== is overriden by the compared type, even if it
doesn't do funny things. The reason is that it's much faster.

When applied to System.Object the "==" and "!=" tokens directly
translate to a single IL instruction each. But when applied to a type
that overrides operator== method calls are generated instead.

I suspect it's for this latter reason that the object cast exists.
System.String does override operator== to achieve "value type
semantics", as they call it; i.e. two strings are equal if they have
the same contents. The object cast saves a method call.
--
http://www.kynosarges.de


Not sure where you get this from, the generated IL is the same in both
cases, there is no cast done.

Willy.
Nov 16 '05 #4
MuZZy <le*******@yahoo.com> wrote:
It's interestinig - i was always under impression that overriden
operators are in fact virtual, in other words if you do
(Object)StringVariable == null, it would do StringVariable == null,
as happens with virtual functions...

But i guess i had a wrong idea of how operators work...


They're not overridden operators - they're overloaded operators.
Polymorphism doesn't come into it.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #5
On Tue, 15 Feb 2005 12:37:20 -0500, MuZZy <le*******@yahoo.com> wrote:
It's interestinig - i was always under impression that overriden operators are in fact virtual


All C# operators are static, so there can't be any polymorphism. The
compiler determines which operator to invoke by looking at the types
of the operands, and then hard-codes the result. You get an error if
the correct operator cannot be determined at compile time, and you'll
get the wrong operator (!) if the type is not visible at compile time.

However, this should not matter because a properly written operator==
always defers the actual comparison to the obligatory Object.Equals
override, and *that* method is indeed polymorphic...
--
http://www.kynosarges.de
Nov 16 '05 #6
On Tue, 15 Feb 2005 19:03:04 +0100, "Willy Denoyette [MVP]"
<wi*************@pandora.be> wrote:
Not sure where you get this from, the generated IL is the same in both
cases, there is no cast done.


After some experimentation, it seems you're right regarding String...
apparently the C# compiler special-cases this type.

You get the behavior I describe with other reference types that define
custom equality operators, though.

The quoted code excerpt may have been written with an earlier C#
version in mind that didn't special-case strings. Or else the author
didn't know about this feature, either...
--
http://www.kynosarges.de
Nov 16 '05 #7

"Christoph Nahr" <ch************@kynosarges.de> wrote in message
news:m6********************************@4ax.com...
On Tue, 15 Feb 2005 12:37:20 -0500, MuZZy <le*******@yahoo.com> wrote:


Good explaination.

- Michael S
Nov 16 '05 #8
Right, String objects are special-cased by the compiler and the CLR .

Willy.

"Christoph Nahr" <ch************@kynosarges.de> wrote in message
news:cl********************************@4ax.com...
On Tue, 15 Feb 2005 19:03:04 +0100, "Willy Denoyette [MVP]"
<wi*************@pandora.be> wrote:
Not sure where you get this from, the generated IL is the same in both
cases, there is no cast done.


After some experimentation, it seems you're right regarding String...
apparently the C# compiler special-cases this type.

You get the behavior I describe with other reference types that define
custom equality operators, though.

The quoted code excerpt may have been written with an earlier C#
version in mind that didn't special-case strings. Or else the author
didn't know about this feature, either...
--
http://www.kynosarges.de

Nov 16 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by mra | last post: by
15 posts views Thread by David | last post: by
4 posts views Thread by John Smith | last post: by
4 posts views Thread by colson | last post: by
9 posts views Thread by Jim in Arizona | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.