Help with the 'is' command...

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Can someone tell me how the 'is' command works in relation to derived classes?

For example -
Class A {}
Class B : A {}

object o = new B();

if (o is A) {...}

Should the above if statement return true or false?

Thanx.
 
Sorry all,

My own fault for not actually deriving the class from the original (forgot the :A in the definition of B).

Thanx again.
 
Can someone tell me how the 'is' command works in relation to derived classes?

For example -
Class A {}
Class B : A {}

object o = new B();

if (o is A) {...}

Should the above if statement return true or false?

Thanx.
Click to expand...

My vote would be false, it's not A - it's B.

Simple enough to try though, what results do you get if you put a
small test app together?
 
Jeff Gaines said:
My vote would be false, it's not A - it's B.
Click to expand...

No, the correct answer is true, because it *is* an A in the same way
that a String is also an Object.

See section 14.9.9 of the ECMA C# spec for more details.
 
Jeff Gaines said:
My vote would be false, it's not A - it's B.

Simple enough to try though, what results do you get if you put a
small test app together?
Click to expand...

Actually, it is not B. It is not A either. It is an instance of B which derives
from A so "o = A" and "o = B". BUT, if you have:

Class A {}
Class B:A{}

object a = new A();
object b = new B();

then

a = A;
a != B;
b = A;
b = B;

get it?

Off top of my head using my own thinking process, which is 50% correct .. or not.

Mythran
 
Hi curious1,

Answer is *true*
o is B and B is A so o is A as well

You can try it.

B\rgds
100
 
Jeff said:
My vote would be false, it's not A - it's B.

Simple enough to try though, what results do you get if you put a
small test app together?
Click to expand...

I'm pretty sure it is true. One would expect A is System.Object to be
true for example..... because it is :)
 
Of course it will return true.

Why don't you try it live? I don't really understand people who post
questions that can be tested with a 2 line program (that they actually write
when they post their questions!). Also, looking at the reference manual for
the "is keyword" will give you the answer (and a small source example with
the output that it produces, so you don't even have to compile and run it).

Bruno
 
Bruno said:
Of course it will return true.

Why don't you try it live? I don't really understand people who post
questions that can be tested with a 2 line program (that they actually write
when they post their questions!). Also, looking at the reference manual for
the "is keyword" will give you the answer (and a small source example with
the output that it produces, so you don't even have to compile and run it).

Bruno
Click to expand...

Amen to that - and even worse, you get several posts from people
*guessing* the answer!
 
Related to subject:

I was reading an MS developer's blog a little while back, and they state
that if you are going to use "is" in perparation to do a cast, it's better
performance and better form to use the "as" operator and test for null.

So, they're saying that instead of doing:
if (someObject is A)
{
A anA = (A)someObject;
...
}

That we should do this:
A anA = someObject as A;
if(anA != null)
{
}

The reasont that the blogger gave is that the first example, using "is"
actually performs 2 casts, one for the is and then the "real" cast.

The "as" example only performs one cast, and by using "as" instead of "()",
no exceptions are thrown.
 
Hi J.Marsch,
Both operator *as* and *is* are translated to the same IL instruction
*isinst*.
*isinst* instruction pushes the reference to the requested type or null of
the cast is incorrect on the top of the evaluation stack.
Here comes the diference between *as* and *is* instructions. Code generated
for the *as* operator just saves the reference in a variable; Code for the
*is* instruction compares the result with *null*

What I want ot say is that *is* instruction actually does the casting.
So doing
if(a is B)
{
b = (B)a;
}

Actually you do casting two times. For b = (B) the compiler emits
*castclass* instruction which is the same as *isinst* with the only
difference that the exception is thrown if the cast is imposible instead of
pushing *null* in the evaluation stack.

IMHO *is* should be used in the rare cases (I think) where you won't do
casting afterwards.

B\rgds
100
 
Makes perfect sense: the first form will test the cast twice, the second one
will test it only once. This is the costly part. Testing against null is
almost no cost.

Bruno.
 
Back
Top