Casting boxed value types in C#

I came across these two posts on Eric Lippert‘s blog yesterday which I found very interesting:

Representation and Identity

Cast operators do not obey the distributive law

The blog posts go into a lot of details but long story short, if you box a value type you can’t unbox it to another type:

It would result in an InvalidCastException, and the big question is, if there exists a conversion from int to long why can’t the runtime work it out?

Well, consider three simple types A, B and C, where B inherits from A and C provides an explicit converter from A:

public class A {}
public class B : A {}
public class C 
{
    public static explicit operator C(A a)
    {
        return new C();
    }
}

There exists two types of conversion which you can achieve using the Casting operator:

var b = new B();
var a = ( A ) b; // inheritance-based conversion, equivalent to var a = b as A;
var c = ( C ) a; // operator-based conversion

In essence, the inheritance-based conversion is just showing the same object in a ‘new light’, whereas the operator-based conversion requires a special treatment on a case-by-case basis in the form of conversion methods.

	Inheritance-based Conversion (representation-preserving)	Operator-based Conversion (representation-changing)
New object is	not constructed	constructed
New variable points to	original object	new object
Changing the new variable	changes the original object	doesn’t change the original object
Conversion is	fast	slow

A box value type is an object, so as far as the compiler is concerned it could be anything. Therefore by allowing a boxed value type to be cast to a different type you introduce new challenges to the compiler:

1. it needs to generate more code at runtime (from CIL to machine code by the JIT-Compiler) because the compiler needs to check if it needs to call a conversion method after unboxing the boxed value type.
2. it also needs to work out which conversion method to call, this requires significant amount of analysis giving that there can be an arbitrary number of conversion methods (both built-in and user-defined) on arbitrarily many types.

Unfortunately the cost of meeting these challenges is performance, and the sensible default was to be “fast and precise” but still allowing this type of conversion through the Convert class.

Parting thoughts…

Towards the end of the post there was a warning to those looking to abuse the new dynamic type support in C# 4 ;-)

“…if the argument to the cast is of type “dynamic” instead of object. The compiler actually generates code which starts a mini version of the compiler up again at runtime, does all that analysis, and spits fresh code. This is NOT FAST, but it is accurate, if that’s what you really need. (And the spit code is then cached so that the next time this call site is hit, it is much faster.)…”