Introduction

Boxing and unboxing is a essential concept in .NET’s type system.
With Boxing and unboxing one can link between value-types and reference-types by
allowing any value of a value-type to be converted to and from type object.
Boxing and unboxing enables a unified view of the type system wherein a value of
any type can ultimately be treated as an object.

Converting a value type to reference type is called Boxing. Unboxing is the
opposite operation and is an explicit operation.

.NET provides a unified type system. All types including value types derive
from the type object. It is possible to call object methods on any value, even
values of primitive types such as int.

This example shows both boxing and unboxing. When a variable of a value
type needs to be converted to a reference type, an object box is allocated to
hold the value, and the value is copied into the box.

Unboxing is just the opposite. When an object box is cast back to its
original value type, the value is copied out of the box and into the appropriate
storage location.

Boxing conversions

A boxing conversion permits any value-type to be implicitly converted to the
type object or to any interface-type implemented by the value-type.
Boxing a value of a value-type consists of allocating an object instance and
copying the value-type value into that instance.

For example any value-type G, the boxing class would be declared as follows:

class vBox
{
G value;
G_Box(G g) {
value = g;
}
}

Boxing of a value v of type G now consists of executing the expression new
G_Box(v), and returning the resulting instance as a value of type object.
Thus, the statements

int i = 12;
object box = i;

conceptually correspond to

int i = 12;
object box = new int_Box(i);

Boxing classes like G_Box and int_Box above don’t actually
exist and the dynamic type of a boxed value isn’t actually a class type.
Instead, a boxed value of type G has the dynamic type G, and a dynamic type
check using the is operator can simply reference type G. For example,

A boxing conversion implies making a copy of the value being boxed. This is
different from a conversion of a reference-type to type object, in which the
value continues to reference the same instance and simply is regarded as the
less derived type object.

will output the value 10 on the console because the implicit boxing operation
that occurs in the assignment of p to box causes the value of p to be copied.
Had Point instead been declared a class, the value 20 would be output because p
and box would reference the same instance.

Unboxing conversions

An unboxing conversion permits an explicit conversion from type object to any
value-type or from any interface-type to any value-type that implements the
interface-type. An unboxing operation consists of first checking that the object
instance is a boxed value of the given value-type, and then copying the value
out of the instance.

unboxing conversion of an object box to a value-type G consists of executing
the expression ((G_Box)box).value.

Thus, the statements

object box = 12;
int i = (int)box;

conceptually correspond to

object box = new int_Box(12);
int i = ((int_Box)box).value;

For an unboxing conversion to a given value-type to succeed at run-time, the
value of the source argument must be a reference to an object that was
previously created by boxing a value of that value-type. If the source argument
is null or a reference to an incompatible object, an InvalidCastException
is thrown.

Conclusion

This type system unification provides value types with the benefits of
object-ness without introducing unnecessary overhead.

For programs that don’t need int values to act like objects, int
values are simply 32-bit values. For programs that need int values to
behave like objects, this capability is available on demand. This ability to
treat value types as objects bridges the gap between value types and reference
types that exists in most languages.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

Because after almost 40 years, some people doesn't noticed yet types are not needed at all. Look at Smalltalk, 30 years without types, thousands of systems running today and still there's some guys talking about the "advantages" of type systems.

Please, let's end what is dead. Types are needed only for machines, not for humans, and reducing the semantic gap we will never need to include "casting", "boxing", "interfaces" or such relics again.

The reason is that you may need to apply an OO-style method or function upon the value type in certain cases (so it needs boxing), but most of the time the value type can be created on the stack, used, then disposed of.