Difference between casting to a class and to an interface

[yufufi]

lets say we have a 'shape' class which doesn't implement IComparable
interface..

compiler doesn't give you error for the lines below..

shape b= new shape();
IComparable h;
h=(IComparable)b;

but it complains for the following lines
shape b= new shape();
int a;
a=(int)b;

error is Cannot convert type 'shape' to 'int'

is there difference between casting to a class and casting to an interface
?? what does the compiler checks when it is casting to an interface (or does
it check anything ?)

Thanx a lot,

yufufi

[Mark Broadbent]

that is a very good shout.
I was under the impression that you could only cast an object to an
interface if said object implementated said interface.
After having a play I see (like you) that this is not true.
It seems that the compiler does not type check a cast to an interface
(whether this is by design or not I do not know?)
However in the runtime the cast is succeeding.
Unfortunately the methods exposed by the interface will not succeed if
accessed because of the incompatible object type -so when you try and run
one through the interface ...BANG! exception.

I can see this functionality of being of some benefit in some instances, but
I would love to know whether this is by design.

Nice post, well done!

--
Br,
Mark Broadbent
mcdba , mcse+i
=============
"yufufi" <yu****@ttnet.net.tr> wrote in message
news:OG**************@tk2msftngp13.phx.gbl...

lets say we have a 'shape' class which doesn't implement IComparable
interface..

compiler doesn't give you error for the lines below..

shape b= new shape();
IComparable h;
h=(IComparable)b;

but it complains for the following lines
shape b= new shape();
int a;
a=(int)b;

error is Cannot convert type 'shape' to 'int'

is there difference between casting to a class and casting to an interface
?? what does the compiler checks when it is casting to an interface (or does it check anything ?)

Thanx a lot,

yufufi

[Niki Estner]

If the type of your object is not sealed, the compiler can't know at compile
time whether the actual object implements the "IComparable" interface or
not. Remeber, at runtime the variable of type "shape" may point to an object
of a type that is derived from "shape" and implements "IComparable".
However - as there is no multiple inheritance - it is not possible that
there is a class that is derived from both "Shape" and "Int".

These are the exact rules, copied from the C# language specification:
"The explicit reference conversions are:
- From object to any other reference-type.
- From any class-type S to any class-type T, provided S is a base class of
T.
- From any class-type S to any interface-type T, provided S is not sealed
and provided S does not implement T.
- From any interface-type S to any class-type T, provided T is not sealed or
provided T implements S.
- From any interface-type S to any interface-type T, provided S is not
derived from T.
- From an array-type S with an element type SE to an array-type T with an
element type TE, provided all of the -following are true:
- S and T differ only in element type. In other words, S and T have the
same number of dimensions.
- Both SE and TE are reference-types.
- An explicit reference conversion exists from SE to TE.
- From System.Array and the interfaces it implements to any array-type.
- From System.Delegate and the interfaces it implements to any
delegate-type. "

Niki

"yufufi" <yu****@ttnet.net.tr> wrote in
news:OG**************@tk2msftngp13.phx.gbl...

lets say we have a 'shape' class which doesn't implement IComparable
interface..

compiler doesn't give you error for the lines below..

shape b= new shape();
IComparable h;
h=(IComparable)b;

but it complains for the following lines
shape b= new shape();
int a;
a=(int)b;

error is Cannot convert type 'shape' to 'int'

is there difference between casting to a class and casting to an interface
?? what does the compiler checks when it is casting to an interface (or does it check anything ?)

Thanx a lot,

yufufi

[Mark Broadbent]

hey Niki, thanks for that too. Always good to have exact references. Cheers.

--
Br,
Mark Broadbent
mcdba , mcse+i
=============
"Niki Estner" <ni*********@cube.net> wrote in message
news:Oi**************@TK2MSFTNGP12.phx.gbl...

If the type of your object is not sealed, the compiler can't know at compile time whether the actual object implements the "IComparable" interface or
not. Remeber, at runtime the variable of type "shape" may point to an object of a type that is derived from "shape" and implements "IComparable".
However - as there is no multiple inheritance - it is not possible that
there is a class that is derived from both "Shape" and "Int".

These are the exact rules, copied from the C# language specification:
"The explicit reference conversions are:
- From object to any other reference-type.
- From any class-type S to any class-type T, provided S is a base class of
T.
- From any class-type S to any interface-type T, provided S is not sealed
and provided S does not implement T.
- From any interface-type S to any class-type T, provided T is not sealed or provided T implements S.
- From any interface-type S to any interface-type T, provided S is not
derived from T.
- From an array-type S with an element type SE to an array-type T with an
element type TE, provided all of the -following are true:
- S and T differ only in element type. In other words, S and T have the
same number of dimensions.
- Both SE and TE are reference-types.
- An explicit reference conversion exists from SE to TE.
- From System.Array and the interfaces it implements to any array-type.
- From System.Delegate and the interfaces it implements to any
delegate-type. "

Niki

"yufufi" <yu****@ttnet.net.tr> wrote in
news:OG**************@tk2msftngp13.phx.gbl...

lets say we have a 'shape' class which doesn't implement IComparable
interface..

compiler doesn't give you error for the lines below..

shape b= new shape();
IComparable h;
h=(IComparable)b;

but it complains for the following lines
shape b= new shape();
int a;
a=(int)b;

error is Cannot convert type 'shape' to 'int'

is there difference between casting to a class and casting to an interface ?? what does the compiler checks when it is casting to an interface (or

does

it check anything ?)

Thanx a lot,

yufufi

[yufufi]

Nice, but then I have another question..

In generics you can check the type of the input like this:

class Box<T>: where T:IComparable

but compiler gives an error at compile time if you try to create Box
instance of type shape.

On the other hand if you try

class Box<T>
{
public int Compare(T inp1,T inp2)
{
return ((IComparable)inp1).CompareTo(inp2);
}
}

it compiles very well ??

Thanx,

yufufi

"Niki Estner" <ni*********@cube.net> wrote in message
news:Oi**************@TK2MSFTNGP12.phx.gbl...

If the type of your object is not sealed, the compiler can't know at compile time whether the actual object implements the "IComparable" interface or
not. Remeber, at runtime the variable of type "shape" may point to an object of a type that is derived from "shape" and implements "IComparable".
However - as there is no multiple inheritance - it is not possible that
there is a class that is derived from both "Shape" and "Int".

These are the exact rules, copied from the C# language specification:
"The explicit reference conversions are:
- From object to any other reference-type.
- From any class-type S to any class-type T, provided S is a base class of
T.
- From any class-type S to any interface-type T, provided S is not sealed
and provided S does not implement T.
- From any interface-type S to any class-type T, provided T is not sealed or provided T implements S.
- From any interface-type S to any interface-type T, provided S is not
derived from T.
- From an array-type S with an element type SE to an array-type T with an
element type TE, provided all of the -following are true:
- S and T differ only in element type. In other words, S and T have the
same number of dimensions.
- Both SE and TE are reference-types.
- An explicit reference conversion exists from SE to TE.
- From System.Array and the interfaces it implements to any array-type.
- From System.Delegate and the interfaces it implements to any
delegate-type. "

Niki

"yufufi" <yu****@ttnet.net.tr> wrote in
news:OG**************@tk2msftngp13.phx.gbl...

lets say we have a 'shape' class which doesn't implement IComparable
interface..

compiler doesn't give you error for the lines below..

shape b= new shape();
IComparable h;
h=(IComparable)b;

but it complains for the following lines
shape b= new shape();
int a;
a=(int)b;

error is Cannot convert type 'shape' to 'int'

is there difference between casting to a class and casting to an interface ?? what does the compiler checks when it is casting to an interface (or

does

it check anything ?)

Thanx a lot,

yufufi

[Niki Estner]

Actually I don't know too much about .net generics yet, but I guess they
apply the implicit casting rules here.
After all, the whole fun about generics is that you don't have the runtime
overhead for casting/boxing, and that the code is safer because invalid cast
exceptions are no longer possible, like they used to be in 'pseudo-generic
containers' that used System.Object references everywhere.
If you were allowed to instantiate a "Box<T> where I:IComparable" with a
type T that doesn't implement that interface, all these advantages would be
lost, wouldn't they?

Not sure if that's the whole reason, but it sounds reasonable to me.

Niki

"yufufi" <yu****@ttnet.net.tr> wrote in
news:ur**************@TK2MSFTNGP11.phx.gbl...

Nice, but then I have another question..

In generics you can check the type of the input like this:

class Box<T>: where T:IComparable

but compiler gives an error at compile time if you try to create Box
instance of type shape.

On the other hand if you try

class Box<T>
{
public int Compare(T inp1,T inp2)
{
return ((IComparable)inp1).CompareTo(inp2);
}
}

it compiles very well ??

Thanx,

yufufi

"Niki Estner" <ni*********@cube.net> wrote in message
news:Oi**************@TK2MSFTNGP12.phx.gbl...

If the type of your object is not sealed, the compiler can't know at compile

time whether the actual object implements the "IComparable" interface or
not. Remeber, at runtime the variable of type "shape" may point to an

object

of a type that is derived from "shape" and implements "IComparable".
However - as there is no multiple inheritance - it is not possible that
there is a class that is derived from both "Shape" and "Int".

These are the exact rules, copied from the C# language specification:
"The explicit reference conversions are:
- From object to any other reference-type.
- From any class-type S to any class-type T, provided S is a base class of

T.
- From any class-type S to any interface-type T, provided S is not sealed and provided S does not implement T.
- From any interface-type S to any class-type T, provided T is not sealed or

provided T implements S.
- From any interface-type S to any interface-type T, provided S is not
derived from T.
- From an array-type S with an element type SE to an array-type T with

an element type TE, provided all of the -following are true:
- S and T differ only in element type. In other words, S and T have the same number of dimensions.
- Both SE and TE are reference-types.
- An explicit reference conversion exists from SE to TE.
- From System.Array and the interfaces it implements to any array-type.
- From System.Delegate and the interfaces it implements to any
delegate-type. "

Niki

"yufufi" <yu****@ttnet.net.tr> wrote in
news:OG**************@tk2msftngp13.phx.gbl...

lets say we have a 'shape' class which doesn't implement IComparable
interface..

compiler doesn't give you error for the lines below..

shape b= new shape();
IComparable h;
h=(IComparable)b;

but it complains for the following lines
shape b= new shape();
int a;
a=(int)b;

error is Cannot convert type 'shape' to 'int'

is there difference between casting to a class and casting to an interface ?? what does the compiler checks when it is casting to an interface

(or does

it check anything ?)

Thanx a lot,

yufufi

[yufufi]

It sounds reasonable to me too , but it also shouldn' allow

class Box<T>
{
public int Compare(T inp1,T inp2)
{
return ((IComparable)inp1).CompareTo(inp2);
}
}
Box<shape> a=new Box<shape>();

I think there is a contradiction here. compiler doesn't give an error here
since shape may be a pointer to a class which is derived from shape and
implements IComparable. But when you use "where T:IComparable" , it doesn't
think maybe I'll pass a class which is also derived from shape and
implements IComparable.
"Niki Estner" <ni*********@cube.net> wrote in message
news:Oo**************@TK2MSFTNGP10.phx.gbl...

Actually I don't know too much about .net generics yet, but I guess they
apply the implicit casting rules here.
After all, the whole fun about generics is that you don't have the runtime
overhead for casting/boxing, and that the code is safer because invalid cast exceptions are no longer possible, like they used to be in 'pseudo-generic
containers' that used System.Object references everywhere.
If you were allowed to instantiate a "Box<T> where I:IComparable" with a
type T that doesn't implement that interface, all these advantages would be lost, wouldn't they?

Not sure if that's the whole reason, but it sounds reasonable to me.

Niki

"yufufi" <yu****@ttnet.net.tr> wrote in
news:ur**************@TK2MSFTNGP11.phx.gbl...

Nice, but then I have another question..

In generics you can check the type of the input like this:

class Box<T>: where T:IComparable

but compiler gives an error at compile time if you try to create Box
instance of type shape.

On the other hand if you try

class Box<T>
{
public int Compare(T inp1,T inp2)
{
return ((IComparable)inp1).CompareTo(inp2);
}
}

it compiles very well ??

Thanx,

yufufi

"Niki Estner" <ni*********@cube.net> wrote in message
news:Oi**************@TK2MSFTNGP12.phx.gbl...

If the type of your object is not sealed, the compiler can't know at compile

time whether the actual object implements the "IComparable" interface or not. Remeber, at runtime the variable of type "shape" may point to an

object

of a type that is derived from "shape" and implements "IComparable".
However - as there is no multiple inheritance - it is not possible that there is a class that is derived from both "Shape" and "Int".

These are the exact rules, copied from the C# language specification:
"The explicit reference conversions are:
- From object to any other reference-type.
- From any class-type S to any class-type T, provided S is a base class of

T.
- From any class-type S to any interface-type T, provided S is not sealed and provided S does not implement T.
- From any interface-type S to any class-type T, provided T is not sealed

or

provided T implements S.
- From any interface-type S to any interface-type T, provided S is not
derived from T.
- From an array-type S with an element type SE to an array-type T with

an element type TE, provided all of the -following are true:
- S and T differ only in element type. In other words, S and T have the same number of dimensions.
- Both SE and TE are reference-types.
- An explicit reference conversion exists from SE to TE.
- From System.Array and the interfaces it implements to any

array-type. - From System.Delegate and the interfaces it implements to any
delegate-type. "

Niki

"yufufi" <yu****@ttnet.net.tr> wrote in
news:OG**************@tk2msftngp13.phx.gbl...
> lets say we have a 'shape' class which doesn't implement IComparable
> interface..
>
> compiler doesn't give you error for the lines below..
>
> shape b= new shape();
> IComparable h;
> h=(IComparable)b;
>
> but it complains for the following lines
> shape b= new shape();
> int a;
> a=(int)b;
>
> error is Cannot convert type 'shape' to 'int'
>
> is there difference between casting to a class and casting to an

interface

> ?? what does the compiler checks when it is casting to an interface

(or does
> it check anything ?)
>
> Thanx a lot,
>
> yufufi
>
>
>
>
>
>
>
>

[Niki Estner]

I don't think it's a contradiction;
If you write:
int i = ...;
IComparable comp;
comp = i;
this will compile, as the compiler can check at compile time that it "i"
does imlpement the interface IComparable. However, something like:
object o = ...;
IComparable comp;
comp = o;
will not, as the cast may work at runtime, but doesn't neccessarily.
However, if you use an explicit cast like:
comp = (IComparable) o;
the compiler "assumes" that you know what you are doing, and, as whatever o
points to might well implement ths IComparable interface does not issue an
error.
The main difference is between "static type checking", that is checking the
type of the declared variable at compile time, and "dynamic type checking",
that is checking the type of the referenced object at runtime. Static casts
are the "safer" ones, as they can never fail. So, for implicit casts and
generics "static conversion rules" apply. If you need a runtime type-check,
you have to explicitly use a cast, or an is/as operator. But of course, if
the compiler can tell that a dynamic cast will definitely never succeed
unless the variable points to "null", it can still issue an error.

I'm not really sure if this explanation makes sense to you, but the
compiler's behaviour does make sense to me.

Niki

"yufufi" <yu****@ttnet.net.tr> wrote in
news:uq**************@TK2MSFTNGP09.phx.gbl...

It sounds reasonable to me too , but it also shouldn' allow

class Box<T>
{
public int Compare(T inp1,T inp2)
{
return ((IComparable)inp1).CompareTo(inp2);
}
}
Box<shape> a=new Box<shape>();

I think there is a contradiction here. compiler doesn't give an error here
since shape may be a pointer to a class which is derived from shape and
implements IComparable. But when you use "where T:IComparable" , it doesn't think maybe I'll pass a class which is also derived from shape and
implements IComparable.
"Niki Estner" <ni*********@cube.net> wrote in message
news:Oo**************@TK2MSFTNGP10.phx.gbl...

Actually I don't know too much about .net generics yet, but I guess they
apply the implicit casting rules here.
After all, the whole fun about generics is that you don't have the runtime

overhead for casting/boxing, and that the code is safer because invalid cast

exceptions are no longer possible, like they used to be in 'pseudo-generic containers' that used System.Object references everywhere.
If you were allowed to instantiate a "Box<T> where I:IComparable" with a
type T that doesn't implement that interface, all these advantages would

be

lost, wouldn't they?

Not sure if that's the whole reason, but it sounds reasonable to me.

Niki

"yufufi" <yu****@ttnet.net.tr> wrote in
news:ur**************@TK2MSFTNGP11.phx.gbl...

Nice, but then I have another question..

In generics you can check the type of the input like this:

class Box<T>: where T:IComparable

but compiler gives an error at compile time if you try to create Box
instance of type shape.

On the other hand if you try

class Box<T>
{
public int Compare(T inp1,T inp2)
{
return ((IComparable)inp1).CompareTo(inp2);
}
}

it compiles very well ??

Thanx,

yufufi

"Niki Estner" <ni*********@cube.net> wrote in message
news:Oi**************@TK2MSFTNGP12.phx.gbl...
> If the type of your object is not sealed, the compiler can't know at
compile
> time whether the actual object implements the "IComparable" interface or > not. Remeber, at runtime the variable of type "shape" may point to

an object
> of a type that is derived from "shape" and implements "IComparable".
> However - as there is no multiple inheritance - it is not possible that > there is a class that is derived from both "Shape" and "Int".
>
> These are the exact rules, copied from the C# language specification: > "The explicit reference conversions are:
> - From object to any other reference-type.
> - From any class-type S to any class-type T, provided S is a base class

of

> T.
> - From any class-type S to any interface-type T, provided S is not

sealed

> and provided S does not implement T.
> - From any interface-type S to any class-type T, provided T is not

sealed

or
> provided T implements S.
> - From any interface-type S to any interface-type T, provided S is not > derived from T.
> - From an array-type S with an element type SE to an array-type T with an

> element type TE, provided all of the -following are true:
> - S and T differ only in element type. In other words, S and T

have the

> same number of dimensions.
> - Both SE and TE are reference-types.
> - An explicit reference conversion exists from SE to TE.
> - From System.Array and the interfaces it implements to any array-type. > - From System.Delegate and the interfaces it implements to any
> delegate-type. "
>
> Niki
>
> "yufufi" <yu****@ttnet.net.tr> wrote in
> news:OG**************@tk2msftngp13.phx.gbl...
> > lets say we have a 'shape' class which doesn't implement

IComparable > > interface..
> >
> > compiler doesn't give you error for the lines below..
> >
> > shape b= new shape();
> > IComparable h;
> > h=(IComparable)b;
> >
> > but it complains for the following lines
> > shape b= new shape();
> > int a;
> > a=(int)b;
> >
> > error is Cannot convert type 'shape' to 'int'
> >
> > is there difference between casting to a class and casting to an
interface
> > ?? what does the compiler checks when it is casting to an

interface (or

> does
> > it check anything ?)
> >
> > Thanx a lot,
> >
> > yufufi
> >
> >
> >
> >
> >
> >
> >
> >
>
>