I understand that boxing and unboxing is about casting (real type to object... object to real type). But I do not understand what the MSDN say about it with the Nullable. He
What it's saying is that if you do:
int? x = 5;
object y = x; // Boxing
You end up with a boxed int
, not a boxed Nullable<int>
. Similarly if you do:
int? x = null; // Same as new Nullable<int>() - HasValue = false;
object y = x; // Boxing
Then y ends up as a null reference.
If a Nullable<T>
is null
, it'll be boxed as a null reference and will not behave as a boxed value type with HasValue = true
.
In fact, to implement this feature, it was required that CLR intrinsically support Nullable<T>
type and treat it differently. Developers can not write their own type that works like Nullable<T>
.
It's worth noting that this was one of the late .NET 2.0 features. In early betas, Nullable<T>
behaved just like a normal structure. In final release, it was changed to box to null reference. This change was specifically breaking for SQL Server CLR team and they had to change some fundamental stuff for it.
What that means is that if you do:
int? i = 5;
object o = i;
it is an "int" (5) that is boxed, not an "int?" (5). If x had been null (!HasValue), o would be null, not a box around an empty "int?"
Then when you unbox:
i = (int?)o;
If o is null, i becomes an empty "int?"; otherwise, the 5 is unboxed and used to create an "new int?(5)".
Basically, you shouldn't (short of cheating) be able to get a boxed nullable<T>
directly - only a boxed T