在我可以安全地应用ToUpper(), StartWith()等方法之前,测试我所有的字符串为空是非常烦人的…
如果字符串的默认值是空字符串,我就不必测试,而且我觉得它与其他值类型(例如int或double)更一致。 此外,Nullable<String>也有意义。
那么为什么c#的设计者选择使用null作为字符串的默认值呢?
注意:这与这个问题有关,但更关注的是为什么,而不是如何处理它。
在我可以安全地应用ToUpper(), StartWith()等方法之前,测试我所有的字符串为空是非常烦人的…
如果字符串的默认值是空字符串,我就不必测试,而且我觉得它与其他值类型(例如int或double)更一致。 此外,Nullable<String>也有意义。
那么为什么c#的设计者选择使用null作为字符串的默认值呢?
注意:这与这个问题有关,但更关注的是为什么,而不是如何处理它。
当前回答
因为字符串是一个引用类型,引用类型的默认值是null。
其他回答
你可以写一个扩展方法(为了它的价值):
public static string EmptyNull(this string str)
{
return str ?? "";
}
现在这个工作很安全:
string str = null;
string upper = str.EmptyNull().ToUpper();
如果string的默认值是空字符串,我就不必进行测试
错了!更改默认值并不会改变它是引用类型的事实,并且有人仍然可以显式地将引用设置为空。
此外,Nullable<String>也有意义。
真正的点。不允许任何引用类型为空会更有意义,而需要Nullable<TheRefType>作为该特性。
那么为什么c#的设计者选择使用null作为字符串的默认值呢?
与其他引用类型的一致性。现在,为什么在引用类型中允许空呢?可能会让它感觉像C语言,尽管在一种也提供Nullable的语言中,这是一个有问题的设计决策。
可空类型直到2.0才出现。
如果可空类型已经在语言的开始,那么字符串将是非空的和string?是可空的。但是他们不能做到向后兼容。
很多人谈论ref-type或不是ref type,但string是一个不寻常的类,并且已经找到了解决方案,使其成为可能。
最根本的原因/问题是CLS规范(定义了语言如何与。net交互)的设计者没有定义一种方法,通过这种方法,类成员可以指定它们必须直接被调用,而不是通过callvirt,而调用方不执行空引用检查;它也没有提供一种定义不受“正常”装箱约束的结构的方法。
Had the CLS specification defined such a means, then it would be possible for .net to consistently follow the lead established by the Common Object Model (COM), under which a null string reference was considered semantically equivalent to an empty string, and for other user-defined immutable class types which are supposed to have value semantics to likewise define default values. Essentially, what would happen would be for each member of String, e.g. Length to be written as something like [InvokableOnNull()] int String Length { get { if (this==null) return 0; else return _Length;} }. This approach would have offered very nice semantics for things which should behave like values, but because of implementation issues need to be stored on the heap. The biggest difficulty with this approach is that the semantics of conversion between such types and Object could get a little murky.
An alternative approach would have been to allow the definition of special structure types which did not inherit from Object but instead had custom boxing and unboxing operations (which would convert to/from some other class type). Under such an approach, there would be a class type NullableString which behaves as string does now, and a custom-boxed struct type String, which would hold a single private field Value of type String. Attempting to convert a String to NullableString or Object would return Value if non-null, or String.Empty if null. Attempting to cast to String, a non-null reference to a NullableString instance would store the reference in Value (perhaps storing null if the length was zero); casting any other reference would throw an exception.
Even though strings have to be stored on the heap, there is conceptually no reason why they shouldn't behave like value types that have a non-null default value. Having them be stored as a "normal" structure which held a reference would have been efficient for code that used them as type "string", but would have added an extra layer of indirection and inefficiency when casting to "object". While I don't foresee .net adding either of the above features at this late date, perhaps designers of future frameworks might consider including them.
因为字符串是一个引用类型,引用类型的默认值是null。