The boxing issue is fairly trivial. Much worse is the double type-checking. Type-checking is heavy-duty in .NET. The "is" operator will invoke type-checking, and then the cast will then invoke the same type-checking.
I think I'd rather write the code this method replaces.
Cheers, Julian
I agree with Julian, doing an _is_ and then an _as_ or a _castclass_ is more expensive in the msil and tools like code analysis (FxCop) may yell.
The _as_ keyword is always going to be the better choise in C# (and TryCast in VB.NET) for reference types.
If you want to test for a value type with as in 2.0 use ?. e.g.
void Foo(object o)
{
int? a = o as int?;
if(a != null)
{
DoSomething((int)a); // or DoSomething(a.Value);
}
}
(With the RC and RTM releases, _as_ works with Nullable<>, as well as the coalesce operator ?? works with reference types)
Rob, Julian, Thanks for mentioning this.
I agree that the native syntax for nullability chekcing will outperform this code.
Think of this code as an exercise in Generics. In fact, I'd probably use this code and optimize for efficieny at a later time, when it's needed. That wasy I can use the same syntax for both value types and reference types.
(Unless i'm at a place where I *know* this will be a problem sucjh as tight loops that need to run fast on a lot of objects)
Roy,
Its not just about performance though. The _as_ keword is used to perform a cast without an exception, returning null if the cast was not possible. Since a ValueType has no concept of null _as_ would not work by default. The above method would return default(T) rather then null, giving you no way to assure that the value supplied to the _as_ actually *could* be safely cast to the supplied type.
Through the use of Nullable<> however, you then gain the ability to perform the null test, and the compiler for C# has been designed to handle using a nullable ValueType with _as_. That way you can use the same syntax as a ref type and still have the null test.
This method then becomes the most consistent as well as does not incur a cost to box the value.
Ron, yes. There is a slight difference in behavior there, isn't there? :)
A simple change such as returning null if the cast won't work instead of default would change this into the same behavior as "as".
I'll update teh post to reflect this fact.
It would be cool to do something to a similar effect in .NET 3.0 as an extension method to certain types ;o)