Question: I'm looking for a clear, concise and accurate answer. 

Ideally as the actual answer, although links to good explanations welcome.

Answer: 
Boxing & unboxing is the process of converting a primitive value into an object oriented wrapper class (boxing), or converting a value from an object oriented wrapper class back to the primitive value (unboxing).

For example, in java, you may need to convert an `int` value into an `Integer` (boxing) if you want to store it in a `Collection` because primitives can't be stored in a `Collection`, only objects. But when you want to get it back out of the `Collection` you may want to get the value as an `int` and not an `Integer` so you would unbox it.

Boxing and unboxing is not inherently *bad*, but it is a tradeoff. Depending on the language implementation, it can be slower and more memory intensive than just using primitives. However, it may also allow you to use higher level data structures and achieve greater flexibility in your code.

These days, it is most commonly discussed in the context of Java's (and other language's) "autoboxing/autounboxing" feature. Here is a [java centric explanation of autoboxing](http://java.sun.com/j2se/1.5.0/docs/guide/language/autoboxing.html).
In .Net:

Often you can't rely on what the type of variable a function will consume, so you need to use an object variable which extends from the lowest common denominator - in .Net this is `object`.

However `object` is a class and stores its contents as a reference.

```
List<int> notBoxed = new List<int> { 1, 2, 3 };
int i = notBoxed[1]; // this is the actual value

List<object> boxed = new List<object> { 1, 2, 3 };
int j = (int) boxed[1]; // this is an object that can be 'unboxed' to an int

```

While both these hold the same information the second list is larger and slower. Each value in the second list is actually a reference to an `object` that holds the `int`.

This is called boxed because the `int` is wrapped by the `object`. When its cast back the `int` is unboxed - converted back to it's value.

For value types (i.e. all `structs`) this is slow, and potentially uses a lot more space. 

For reference types (i.e. all `classes`) this is far less of a problem, as they are stored as a reference anyway.

A further problem with a boxed value type is that it's not obvious that you're dealing with the box, rather than the value. When you compare two `structs` then you're comparing values, but when you compare two `classes` then (by default) you're comparing the reference - i.e. are these the same instance?

This can be confusing when dealing with boxed value types:

```
int a = 7;
int b = 7;

if(a == b) // Evaluates to true, because a and b have the same value

object c = (object) 7;
object d = (object) 7;

if(c == d) // Evaluates to false, because c and d are different instances

```

It's easy to work around:

```
if(c.Equals(d)) // Evaluates to true because it calls the underlying int's equals

if(((int) c) == ((int) d)) // Evaluates to true once the values are cast

```

However it is another thing to be careful of when dealing with boxed values.