Casting vs using the 'as' keyword in the CLR
The answer below the line was written in 2008.
C# 7 introduced pattern matching, which has largely replaced the as
operator, as you can now write:
if (randomObject is TargetType tt)
{
// Use tt here
}
Note that tt
is still in scope after this, but not definitely assigned. (It is definitely assigned within the if
body.) That's slightly annoying in some cases, so if you really care about introducing the smallest number of variables possible in every scope, you might still want to use is
followed by a cast.
I don't think any of the answers so far (at the time of starting this answer!) have really explained where it's worth using which.
Don't do this:
// Bad code - checks type twice for no reason
if (randomObject is TargetType)
{
TargetType foo = (TargetType) randomObject;
// Do something with foo
}Not only is this checking twice, but it may be checking different things, if
randomObject
is a field rather than a local variable. It's possible for the "if" to pass but then the cast to fail, if another thread changes the value ofrandomObject
between the two.If
randomObject
really should be an instance ofTargetType
, i.e. if it's not, that means there's a bug, then casting is the right solution. That throws an exception immediately, which means that no more work is done under incorrect assumptions, and the exception correctly shows the type of bug.// This will throw an exception if randomObject is non-null and
// refers to an object of an incompatible type. The cast is
// the best code if that's the behaviour you want.
TargetType convertedRandomObject = (TargetType) randomObject;If
randomObject
might be an instance ofTargetType
andTargetType
is a reference type, then use code like this:TargetType convertedRandomObject = randomObject as TargetType;
if (convertedRandomObject != null)
{
// Do stuff with convertedRandomObject
}If
randomObject
might be an instance ofTargetType
andTargetType
is a value type, then we can't useas
withTargetType
itself, but we can use a nullable type:TargetType? convertedRandomObject = randomObject as TargetType?;
if (convertedRandomObject != null)
{
// Do stuff with convertedRandomObject.Value
}(Note: currently this is actually slower than is + cast. I think it's more elegant and consistent, but there we go.)
If you really don't need the converted value, but you just need to know whether it is an instance of TargetType, then the
is
operator is your friend. In this case it doesn't matter whether TargetType is a reference type or a value type.There may be other cases involving generics where
is
is useful (because you may not know whether T is a reference type or not, so you can't use as) but they're relatively obscure.I've almost certainly used
is
for the value type case before now, not having thought of using a nullable type andas
together :)
EDIT: Note that none of the above talks about performance, other than the value type case, where I've noted that unboxing to a nullable value type is actually slower - but consistent.
As per naasking's answer, is-and-cast or is-and-as are both as fast as as-and-null-check with modern JITs, as shown by the code below:
using System;
using System.Diagnostics;
using System.Linq;
class Test
{
const int Size = 30000000;
static void Main()
{
object[] values = new object[Size];
for (int i = 0; i < Size - 2; i += 3)
{
values[i] = null;
values[i + 1] = "x";
values[i + 2] = new object();
}
FindLengthWithIsAndCast(values);
FindLengthWithIsAndAs(values);
FindLengthWithAsAndNullCheck(values);
}
static void FindLengthWithIsAndCast(object[] values)
{
Stopwatch sw = Stopwatch.StartNew();
int len = 0;
foreach (object o in values)
{
if (o is string)
{
string a = (string) o;
len += a.Length;
}
}
sw.Stop();
Console.WriteLine("Is and Cast: {0} : {1}", len,
(long)sw.ElapsedMilliseconds);
}
static void FindLengthWithIsAndAs(object[] values)
{
Stopwatch sw = Stopwatch.StartNew();
int len = 0;
foreach (object o in values)
{
if (o is string)
{
string a = o as string;
len += a.Length;
}
}
sw.Stop();
Console.WriteLine("Is and As: {0} : {1}", len,
(long)sw.ElapsedMilliseconds);
}
static void FindLengthWithAsAndNullCheck(object[] values)
{
Stopwatch sw = Stopwatch.StartNew();
int len = 0;
foreach (object o in values)
{
string a = o as string;
if (a != null)
{
len += a.Length;
}
}
sw.Stop();
Console.WriteLine("As and null check: {0} : {1}", len,
(long)sw.ElapsedMilliseconds);
}
}
On my laptop, these all execute in about 60ms. Two things to note:
- There's no significant difference between them. (In fact, there are situations in which the as-plus-null-check definitely is slower. The above code actually makes the type check easy because it's for a sealed class; if you're checking for an interface, the balance tips slightly in favour of as-plus-null-check.)
- They're all insanely fast. This simply will not be the bottleneck in your code unless you really aren't going to do anything with the values afterwards.
So let's not worry about the performance. Let's worry about correctness and consistency.
I maintain that is-and-cast (or is-and-as) are both unsafe when dealing with variables, as the type of the value it refers to may change due to another thread between the test and the cast. That would be a pretty rare situation - but I'd rather have a convention which I can use consistently.
I also maintain that the as-then-null-check gives a better separation of concerns. We have one statement which attempts a conversion, and then one statement which uses the result. The is-and-cast or is-and-as performs a test and then another attempt to convert the value.
To put it another way, would anyone ever write:
int value;
if (int.TryParse(text, out value))
{
value = int.Parse(text);
// Use value
}
That's sort of what is-and-cast is doing - although obviously in a rather cheaper way.
What is the difference between casting and using as in C#?
The differences are:
- If a cast fails, it throws an
InvalidCastException
. - If the
as
operator fails, it just returns a null reference. - You can't use
as
with non-nullable value types (e.g. you can't do "o as int
"). - The cast operator is also used for unboxing. (
as
can be used to unbox to a nullable value type.) - The cast operator can also perform user-defined conversions.
EDIT: I've written elsewhere about when I feel it's appropriate to use which operator. That might be worth a read...
Direct casting vs 'as' operator?
string s = (string)o; // 1
Throws InvalidCastException if o
is not a string
. Otherwise, assigns o
to s
, even if o
is null
.
string s = o as string; // 2
Assigns null
to s
if o
is not a string
or if o
is null
. For this reason, you cannot use it with value types (the operator could never return null
in that case). Otherwise, assigns o
to s
.
string s = o.ToString(); // 3
Causes a NullReferenceException if o
is null
. Assigns whatever o.ToString()
returns to s
, no matter what type o
is.
Use 1 for most conversions - it's simple and straightforward. I tend to almost never use 2 since if something is not the right type, I usually expect an exception to occur. I have only seen a need for this return-null type of functionality with badly designed libraries which use error codes (e.g. return null = error, instead of using exceptions).
3 is not a cast and is just a method invocation. Use it for when you need the string representation of a non-string object.
Is there more to the C# as keyword than simple casting?
as
will return an object of the type you requested, if the operand is compatible. If it isn't, it will return null
. If you use as
and it is possible that the cast will fail, you need to check to make sure the reference is valid.
For example, if depObj was of type String
, it would not be null
, but it would also not be able to be converted to either of the requested types and both of those variables would become null
.
C# as cast vs classic cast
With the "classic" method, if the cast fails, an InvalidCastException
is thrown. With the as
method, it results in null
, which can be checked for, and avoid an exception being thrown.
Also, you can only use as
with reference types, so if you are typecasting to a value type, you must still use the "classic" method.
Note:
The as
method can only be used for types that can be assigned a null
value. That use to only mean reference types, but when .NET 2.0 came out, it introduced the concept of a nullable value type. Since these types can be assigned a null
value, they are valid to use with the as
operator.
What is a difference between casts: (A) x and x as A?
The as operator is like a cast operation. However, if the conversion isn't possible, as returns null instead of raising an exception.
You can use the as operator to perform certain types of conversions between compatible reference types or nullable types.
Consider the following example:
expression as type
The code is equivalent to the following expression except that the expression variable is evaluated only one time.
expression is type ? (type)expression : (type)null
Note that the as operator performs only reference conversions, nullable conversions, and boxing conversions. The as operator can't perform other conversions, such as user-defined conversions, which should instead be performed by using cast expressions.
Refer:
as (C# Reference)
Does it make sense to use as instead of a cast even if there is no null check?
Your understanding is true. That sounds like trying to micro-optimize to me. You should use a normal cast when you are sure of the type. Besides generating a more sensible exception, it also fails fast. If you're wrong about your assumption about the type, your program will fail immediately and you'll be able to see the cause of failure immediately rather than waiting for a NullReferenceException
or ArgumentNullException
or even a logical error sometime in the future. In general, an as
expression that's not followed by a null
check somewhere is a code smell.
On the other hand, if you are not sure about the cast and expect it to fail, you should use as
instead of a normal cast wrapped with a try-catch
block. Moreover, use of as
is recommended over a type check followed by a cast. Instead of:
if (x is SomeType)
((SomeType)x).SomeMethod();
which generates an isinst
instruction for the is
keyword, and a castclass
instruction for the cast (effectively performing the cast twice), you should use:
var v = x as SomeType;
if (v != null)
v.SomeMethod();
This only generates an isinst
instruction. The former method has a potential flaw in multithreaded applications as a race condition might cause the variable to change its type after the is
check succeeded and fail at the cast line. The latter method is not prone to this error.
The following solution is not recommended for use in production code. If you really hate such a fundamental construct in C#, you might consider switching to VB or some other language.
In case one desperately hates the cast syntax, he/she can write an extension method to mimic the cast:
public static T To<T>(this object o) { // Name it as you like: As, Cast, To, ...
return (T)o;
}
and use a neat[?] syntax:
obj.To<SomeType>().SomeMethod()
Related Topics
How to Load Dll (Module Could Not Be Found Hresult: 0X8007007E)
What Is an Indexoutofrangeexception/Argumentouto
frangeexception and How to Fix It
Understanding Garbage Collection in .Net
The Entity Cannot Be Constructed in a Linq to Entities Query
Best Way to Parse Command Line Arguments in C#
One Dbcontext Per Web Request... Why
How to Provide User Name and Password When Connecting to a Network Share
Is There a Difference Between "Throw" and "Throw Ex"
Remove Duplicates in the List Using Linq
Using Xpath With Default Namespace in C#
Pre & Post Increment Operator Behavior in C, C++, Java, & C#
Random Number Generator Only Generating One Random Number
An Async/Await Example That Causes a Deadlock
How to Get All Child Controls of a Windows Forms Form of a Specific Type (Button/Textbox)
How to Detect the Encoding/Codepage of a Text File
The Located Assembly'S Manifest Definition Does Not Match the Assembly Reference