I have -never- used as or is in C# or any language that supports the keyword.
What have you used it for?
I dont mean how do i use it i mean how have you actually need it?
I also got away with doing no typecasting in a fairly large c++ project (i was proud).
So considering i almost never typecast why do i need the keyword as or is?
C-style casts (like (Foo)bar) will throw InvalidCastException if cast fails. as, on the other hand, will yield null (see this). is operator is just used to test whether a run-time type of given instance is compatible with the type provided (see this).
is is used extensively in.NET System.ComponentModel namespace. More specifically, TypeConverter API relies heavily on is operator to determine how to convert from one type to another.
Intriguing question. Actually, I use them all the time. is is handy to find out whether an object is of a certain type, I use that occasionally in generics or in loops through objects that are of different types. It is also invaluable with Reflection.
The other, as finds many more uses. It is often much safer to use then a normal cast: when it fails, it returns null, instead of an exception. I also find it clearer syntax and easier to use it, check the return value for null, then to add an exception block.
Basically, what I mean to say is, I prefer this:
protected void GeneralEventHandler(object sender, EventArgs e)
{
Button btn = sender as Button;
if(btn != null) // click came from a button!
// do something
else
// other cases
}
and this:
protected void GeneralEventHandler(object sender, EventArgs e)
{
if(sender is Button) // click came from a button!
// do something
else
// other cases
}
as opposed to this:
protected void GeneralEventHandler(object sender, EventArgs e)
{
try
{
Button btn = (Button) sender;
// if we get this far, it's a button
}
catch(InvalidCastException ice)
{
// click did not come from a button! Handle other cases
}
}
of course, this is just an example, but when I can avoid try / catch, I will. This also lets more room for real exceptions to get through.
I use 'as' as a handy shortcut in event handlers to get the sending object back when I can't know at design time the sender.
protected void SomeButtonInAGridView_Click(object sender, EventArgs e)
{
Button clickedButton = sender as Button;
}
Here's one that comes up alot:
class Foo {
public override bool Equals(object obj)
{
// The more specific function needs to do null checking anyway.
return Equals(obj as Foo);
}
public bool Equals(Foo obj)
{
// do some comparison here.
}
}
Here is a post from Eric Lippert describing how "as" is used in C#:
I use as all the time. When i have to pull back a serialized object from session cache, I use as to determine if the serialized object is there and of the right type. I can avoid the program throwing an error, using the as operator and checking for null. If it's null, I know something is missing, and I can recreate the object and push it back into cache for the next time I need it.
You could accomplish the same result using the cast operator, but that adds the overhead of an exception, especially when you know that the serialized object isn't going to be there part of the time.
I had to write code to enumerate over all the controls placed on a ASP.NET webform and perform certain operations on specific controls, e.g. add a background color to all Textboxes, and so on.
The main benefit of as and is for me is that I can safely check whether a variable is of a given type using is without exceptions happening. Once I'm sure it's of a given type, I can safely and easily convert it to the type needed using as.
What I basically did (simplified!) is a
foreach(Control c in form.Controls)
{
if(c is Textbox)
HandleTextbox(c as Textbox);
if(c is Listbox)
HandleListbox(c as Listbox);
}
and so on. Without as and is this would be a lot messier, IMHO.
Basically, you'll probably need or can make good use of as and is if you're dealing with polymorphism a lot - if you have lists of things that can be any number of types, like controls on a page in my example. If you don't have or don't use polymorphism a lot, you're unlikely to encounter the need for those operators.
Marc
C# offer way to cast using the is and as operator. The is operator checks whether an object is compatible with a given type, and the result of the evaluation is a Boolean: true or false. The is operator will never throw an exception. The following code demonstrates:
System.Object o = new System.Object();
System.Boolean b1 = (o is System.Object); // b1 is true.
System.Boolean b2 = (o is Employee); // b2 is false.
If the object reference is null, the is operator always returns false because there is no object available to check its type.
The is operator is typically used as follows:
if (o is Employee) {
Employee e = (Employee) o;
// Use e within the ‘if’ statement.
}
In this code, the CLR is actually checking the object’s type twice: the is operator first checks to see if o is compatible with the Employee type. If it is, then inside the if statement, the CLR again verifies that o refers to an Employee when performing the cast.
C# offers a way to simplify this code and improve its performance by providing an as operator:
Employee e = o as Employee;
if (e != null) {
// Use e within the ‘if’ statement.
}
In this code, the CLR checks if o is compatible with the Employee type, and if it is, as returns a non-null pointer to the same object. If o is not compatible with the Employee type,then the as operator returns null.
I used both keywords extensively in a WinForms app where there's a GUI to edit an invoice, each row in the ListView could contain different types of items (i.e., it could be a line item or a description, or ...). All the items I put in the ListView were derived from ListViewItem, so then later on when I went to implement things like editing the selected item, I had to check which item type was selected (using is) to show the appropriate editing GUI.
If you ever develop on a project that offers a plugin interface then as and is will quickly become your VERY best friends.
I use it for cleanly getting data from a DataReader that might be DBNull.
int? personHeight = dr["Height"] as int?;
or
int personHeight = dr["Height"] as int? ?? 0;
Here's another use-case to go into the Cabinet of Dr. Caligari ;-)
You can chain the as operator, as in:
x = obj as Label as Control;
Why would you do such a thing? If you want null if its not a Label, but you want to treat them all as Control. Just casting Textbox and Label directly to Control would yield success for both, now it'll be null for unwanted types of Control. This is a shortcut method you won't need often but is occasionally handy.
An alternative use for the same is when you need ToString() on an object, but only when it is of the correct type, otherwise you want a default string. This is a scenario that I do encounter very often, esp. with POCOs. Because ToString() is virtual, this works:
// assume SomeClass has overridden ToString()
// return "none" if item is not of type SomeClass or if it is null to begin with
string itemText = (item as SomeClass as Object ?? "none").ToString();
If you're really never having to do casting then I you likely wouldn't have much use for these operators. In my experience, however, .NET programming calls for a lot of casting particularly when dealing with delegates where arguments are provided typed as 'object'. I think that the introduction of generics has helped cut down on the need for casting, but it's certainly something that I use pretty often. I might be "doing it wrong" but that's just been my experience.
So if you're going to do casting anyway I really like the 'is' operator for improved readability of the code. I'd much rather look at
if(foo is SomeType) {...}
then
if(foo.GetType() == typeof(SomeType)) {...}
Custom TypeConverters comes first to mind.
public override object ConvertFrom(ITypeDescriptorContext context, System.Globalization.CultureInfo culture, object value)
{
if (value is string)
{
return GetEnumValue(myVal, (string)value);
}
if (value is Enum)
{
return GetEnumDescription((Enum)value);
}
return base.ConvertFrom(context, culture, value);
}
Second comes from a case where I have a shadow of an object (for tracking changes) which is inherited from a base class
class BaseClass
{
BaseClass _shadow;
}
protected override void UpdateShadow()
{
ThisClass shadow = _shadow as ThisClass;
//...
}
marc_s's answer is a little flawed, I see this code all the time so I want to emphasize the importance of the difference between these operators. is is a boolean test to determine if an object is assignable to a certain type. as checks to see if an object is assignable to a certain type and if it is, it returns that object as that type, if not, it returns null. marc_s's answer is really doing this
foreach(Control c in form.Controls)
{
if(c is Textbox)
HandleTextbox(c is Textbox ? (Textbox)c : null);
if(c is Listbox)
HandleListbox(c is Listbox ? (Listbox)c : null);
}
It is redundant to use is with as. When ever you use as just replace it with the expression above, it is equivalent. Use is with direct casts () or as only by itself. A better way to write that example would be.
foreach(Control c in form.Controls)
{
if(c is Textbox)
HandleTextbox((Textbox)c);
//c is always guaranteed to be a Textbox here because of is
if(c is Listbox)
HandleListbox((Listbox)c);
//c is always guaranteed to be a Listbox here because of is
}
Or if you really like as
foreach(Control c in form.Controls)
{
var textBox = c as Textbox;
if(textBox != null)
{
HandleTextbox(textBox);
continue;
}
var listBox = c as ListBox
if(listBox != null)
HandleListbox(listBox);
}
A real world example that I run into all the time is getting objects from a storage area that only return type object. Caching is a great example.
Person p;
if (Cache[key] is Person)
p = (Person)Cache[key];
else
p = new Person();
I use as much less in real code because it really only works for reference types. Consider the following code
int x = o as int;
if (x != null)
???
as fails because an int can't be null. is works fine though
int x;
if (o is int)
x = (int)o;
I am sure there is also some speed difference between these operators, but for a real application the difference is negligible.