拳击/拆箱空类型 - 为什么这个实现？ [英] Boxing / Unboxing Nullable Types - Why this implementation?
问题描述
解...
在拳击：如果可空实例不是空，CLR的取值出可空实例和箱子吧。换句话说一个可空＆LT; INT32> ，值为 5 被装箱成盒装-的Int32 为5的值。
On Boxing: If the nullable instance is not null, the CLR takes the value out of the nullable instance and boxes it. In other words a Nullable < Int32 > with a value of 5 is boxed into a boxed-Int32 with a value of 5.
在拆箱：拆箱仅仅是获得一个引用的盒装对象的拆箱部分的行为。问题是，装箱值类型不能简单地拆箱到该值类型的可空版本，因为装箱值不具有布尔hasValue的字段在里面。所以，当拆箱值类型为一个可空的版本，CLR必须分配可空＆LT; T> 对象，初始化 hasValue的字段为真的，并设定值字段以相同的值，在盒装值类型。这会影响应用程序的性能（拆箱过程中内存分配）。
On Unboxing: Unboxing is simply the act of obtaining a reference to the unboxed portion of a boxed object. The problem is that a boxed value type cannot be simply unboxed into a nullable version of that value type because the boxed value doesn't have the boolean hasValue field in it. So, when unboxing a value type into a nullable version, the CLR must allocate a Nullable < T > object, initialize the hasValue field to true, and set the value field to the same value that is in the boxed value type. This impacts your application performance (memory allocation during unboxing).
为什么CLR团队经历了这么多的麻烦可空类型？为什么它不是简单盒装入可空＆LT; INT32>摆在首位？
推荐答案
我记得这种行为是那种最后一分钟的变化。在.NET 2.0早期测试版，可空＆LT; T＆GT; 是一个正常值类型。包装一个空价值诠释？把它变成了盒装诠释？用布尔标志。我认为，他们毅然选择了目前的做法的原因是一致性。你说：
I remember this behavior was kind of last minute change. In early betas of .NET 2.0, Nullable<T> was a "normal" value type. Boxing a null valued int? turned it into a boxed int? with a boolean flag. I think the reason they decided to choose the current approach is consistency. Say:
int? test = null;
object obj = test;
if (test != null)
Console.WriteLine("test is not null");
if (obj != null)
Console.WriteLine("obj is not null");
在以前的方法（盒空 - >盒装可空＆LT; T＆GT; ），你不会得到测试不空，但你会得到对象不空，这是奇怪的。
In the former approach (box null -> boxed Nullable<T>), you wouldn't get "test is not null" but you'd get "object is not null" which is weird.
此外，如果他们盒装的一个空值到盒装空的＆LT; T＆GT; ：
Additionally, if they had boxed a nullable value to a boxed-Nullable<T>:
int? val = 42;
object obj = val;
if (obj != null) {
// Our object is not null, so intuitively it's an `int` value:
int x = (int)obj; // ...but this would have failed.
}
旁边的是，我认为当前的行为非常有意义，对于像可空数据库值的情况（想想SQL-CLR ...）
Beside that, I believe the current behavior makes perfect sense for scenarios like nullable database values (think SQL-CLR...)
提供可空类型的整点是可以很容易地处理有任何有意义的值的变量。他们并不想提供两个不同的，不相关的类型。一个诠释？应该表现或多或少像一个简单的 INT 。这就是为什么C＃提供了提升运营商。
The whole point of providing nullable types is to make it easy to deal with variables that have no meaningful value. They didn't want to provide two distinct, unrelated types. An int? should behaved more or less like a simple int. That's why C# provides lifted operators.
所以，当拆箱值类型为一个可空的版本，CLR必须分配可空＆LT; T＆GT; 对象，初始化hasValue的字段设置为true，并设置值场相同的值，在装箱值类型。这会影响应用程序的性能（拆箱过程中内存分配）。
So, when unboxing a value type into a nullable version, the CLR must allocate a
Nullable<T>object, initialize the hasValue field to true, and set the value field to the same value that is in the boxed value type. This impacts your application performance (memory allocation during unboxing).
这是不正确的。在CLR将不得不分配内存的在堆栈以保持变量是否是空值。这里没有性能问题来分配空间，但需要额外的布尔变量。
This is not true. The CLR would have to allocates memory on stack to hold the variable whether or not it's nullable. There's not a performance issue to allocate space for an extra boolean variable.
这篇关于拳击/拆箱空类型 - 为什么这个实现？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
