基类库的变化与改进

  • Jonathan Allen
  • 张逸

2008 年 12 月 21 日

话题:.NET语言 & 开发

自 2005 年以来,基类库就处于停滞之中。当其余的.NET 框架基于 CLR 2.0 版本之上不断演进与构建时,基类库团队却在缓慢地构建他们的期望列表。跟随着.NET 4 的脚步,CLR 和 BCL(基类库)的新版本也蓄势待发,一些改进也最终得到了实现。

新的类型

类似 IronPython 和 F# 的语言虽然简单,却与核心的.NET 语言是完全背离的,它们具有真正的整数类型。VB 和 C# 限制了整数必须符合给定的设置位,而这些语言实际上可以设置为任何值。但是,为了共享二者之间的价值,别说与其它语言,甚至是一个通用的实现都是需要的。基类库会添加一个类型BigInteger。这一高性能的实现是由 BCL 团队和Microsoft Solver Foundation一起联合开发的。

另一个主要为 F# 和 IronPython 添加的类型为Tuples。Tuples 本身并无任何特别之处,本质上就是一个数据结构,能够存储一组固定长度的值。从某种程度上讲它就像是一个数组,但每个值都可以是不同的类型。与 BigInteger 相似,在基类库级引入它的主要原因是为了避免重复且不一致的实现。

在集合中新增的类为 SortedSet。这是另外一个可以支持排序的对象集合的类,其中每个排序键必须是唯一的。目前仍然缺乏允许键重复的排序列表。

非托管的内存支持

在处理巨型文件时,真正的开发人员会转而使用一种技术,名为内存映射文件。顾名思义,一个内存映射文件将一个类似文件的结构映射到内存的地址中。除了实际的文件,设备与共享内存对象都能够被映射。使用内存映射文件的一种最常见的情形是内部进程通信。要做到这一点,每个应用程序都要打开相同的文件描述符。在 BCL 的下一个版本中,.NET 开发人员将能够直接使用内存映射文件,而无需通过平台调用的方式。

国际化

.NET 4 和 Silverlight 2 的资源管理器都将支持用户对 UI 语言的参数选择,而不是仅仅将其默认设置为 CurrentUICulture 链。当用户拥有多个首选语言时,这一功能就显得非常重要。

不一致的变化

System.String中,好几个方法的默认比较逻辑都发生了变化。它不会影响到仅仅使用英语的应用程序,但可能会影响到国际化应用程序。

System.String(StartsWith,EndsWith,IndexOf 和 LastIndexOf)的默认部分的匹配重载被修改为默认与文化信息无关(顺序)。此外,System.String 以及 System.Char 的 ToUpper 和 ToLower 则被修改为使用不可变的文化信息,而不是使用当前文化信息。虽然我们已经制定了编程指南以及 FxCop 规则,以建议开发者总是使用接受 StringComparison 参数的重载方法,但开发者总是不自觉地使用默认的重载方法。在.NET 之前的版本中,默认的重载方法使用当前文化信息实现与文化信息相关的比较。当对此没有充分认识的开发人员,使用默认的重载方法执行安全敏感的字符串比较时,总会出现一些莫名其妙的错误,且具有明显的安全弱点,

性能改善

目前,Directory 和 DirectoryInfo 的方法是返回数组。这就意味着在单个入口被访问之前,必须生成整个文件数组。随着IEnumerable 对 Directory 和 DirectoryInfo 的额外支持,在目录的第一个文件被即刻访问时,列表的其余文件则可以延迟生成。

查看英文原文:Changes and Improvements to the Base Class Library

.NET语言 & 开发