By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,238 Members | 1,804 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,238 IT Pros & Developers. It's quick & easy.

Casting an Object to Interface

P: n/a
Hi all,
Can any one tell me what happens when an object is casted to
an interface, somthing bit deeper,

the case is i do have an interface Ifunction which has got one method
display(), and i have implemented the interface in one class and i have
implemented the display function in the class,
So when i say ((Ifunction)object).display(), it calls the function
in the class which i have written.

So can any one tell me casting an object to interface , what happens
behind the scene
Thanks in Advance

Regards

thomson

Nov 17 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a

"thomson" <sa**********@yahoo.com> wrote in message
news:11*********************@g44g2000cwa.googlegro ups.com...
Hi all,
Can any one tell me what happens when an object is casted to
an interface, somthing bit deeper,

the case is i do have an interface Ifunction which has got one method
display(), and i have implemented the interface in one class and i have
implemented the display function in the class,
So when i say ((Ifunction)object).display(), it calls the function
in the class which i have written.

So can any one tell me casting an object to interface , what happens
behind the scene


Well, what happens excactly depends on context. If the type can be
statically determined to support the interface, the compiler calls the
"Ifucntion::display()" method on a reference to your object. No cast
actually happens.

If, however, the object type cannot be verified to support the interface, a
castclass instruction is issued and the method is called on the returned
reference.

That is the simple story, was there something specific you wanted to know?

There is some slightly mucky techincal stuff about how the VTable works that
is covered in part in:
http://blogs.msdn.com/cbrumme/archiv.../14/51495.aspx But I don't know
how it works in the most modern version, things could have changed since
then

Nov 17 '05 #2

P: n/a
Thomson... nothing happens to the actual object in memory. you are
simply telling the compiler to restrict method invocation and access to
fields on the object in memory to the interface of IFunction.

So objects have class and references (ref variables) have type.

http://www.geocities.com/jeff_louie/OOP/oop6.htm

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***
Nov 17 '05 #3

P: n/a
> Thomson... nothing happens to the actual object in memory.

That's really the most important point. When an object is "born"
(constructed), it has a type (class) which never changes throught the
lifetime of the object.

However, within your code, you can assign references to that object to
various different variables that are declared to be of different types
(classes / interfaces). The compiler lets you do this:

MyClass myClassReference = new MyClass();
MyInterface myInterfaceReference = myClassReference;

without any cast operator, because it knows that MyClass implements
MyInterface, so a variable of type MyInterface can point to the object
created in the line above with no problem. However, if you then go and
do this:

MyClass myOtherClassReference = (MyClass)myInterfaceReference;

you need a cast, because there may be other classes that implement
MyInterface, and so the compiler doesn't know just from looking at that
line of code that the cast will be valid. So, as Daniel pointed out,
the compiler forces you to indicate an explicit cast, and generates a
run time instruction to check that the assignment is valid before
actually performing it.

That said, Jeff's point is paramount throughout all of this: the object
in memory that myClassReference, myInterfaceReference, and
myOtherClassReference all point to is of type MyClass, because that's
how it was constructed, and its type never changes through all of this.
The only thing that changes is what type of variable is pointing to the
object.

So, as Daniel said, when you assign a reference to an object from one
variable to another, sometimes the compiler can tell that the
assignment will be valid, so it simply allows it and generates nothing
more than an assignment at run time. In other cases, the compiler can't
tell if the assignment will be valid in all situations, so it generates
an additional instruction to verify, at run time, that the object for
which the reference is being assigned is of the right type (class) for
the receiving variable.

Nov 17 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.