CLR中的范型详解中的范型详解
本页内容本页内容
编译器如何处理范型？
规则和限制
where T :
IComparable
范型接口和委托
类库中的范型
小结
在本专栏某一期中，我初步讨论了公共语言运行库 (CLR) 中的范型。我引入了范型的
概念，介绍了范型所带来的灵活性和代码重用，探讨了性能和类型安全，并通过一个
简单的代码示例展示了 C# 中的范型语法。本月，我将深入讨论与范型有关的 CLR 内
部工作机制。我将介绍类型约束、范型类、方法、结构和即将问世的范型类库。
编译器如何处理范型？编译器如何处理范型？
C++ 模板和 Java 语言中提议的范型等效都是它们各自编译器的功能。这些编译器在
编译时根据对范型或模板类型的引用来构造代码。这会导致代码臃肿并降低结构之间
的类型等效（即使类型变量相同）。相反，CLR 范型不采用这种工作方式。
CLR 中的范型是平台本身出类拔萃的功能。要通过这种方式实现它就需要更改整个
CLR（包括新的和修改过的中间语言指令），并更改元数据、类型加载器、实时 (JIT)
编译器、语言编译器等等。这对 CLR 中的运行时扩展有两个重要的好处。
首先，即使范型的每个结构（例如 Node首先，即使范型的每个结构（例如
Node<Form> 和 Node<String>）都有自己独特的类型标识，但 CLR 能够在类型实例
化期间重用许多真正的 JIT 编译的代码。这极大地降低了代码膨胀，并且也是切实可
行的，因为范型的各种实例化都是在运行时才展开的。在编译时，构造类型的所有内
容就是类型引用。当程序集 A 和 B 都引用在第三方程序集中定义的范型时，它们的构
造类型就会在运行时展开。这意味着，除了共享 CLR 类型标识（在适当的时候）以
外，来自程序集 A 和 B 的类型实例化也共享运行时资源，如本机代码和扩展的元数
据。
类型等效是构造类型运行时扩展的第二个好处。以下为一个示例：引用 AssemblyA.dll
中构造 Node <Int32> 的代码和引用 AssemblyB.dll 中构造 Node <Int32> 的代码都会
在运行时创建具有相同 CLR 类型的对象。通过这种方式，如果两个程序集由同一个应
用程序使用，则它们的 Node <T> 类型的结构会解析为相同的类型，并且它们的对象
可以自由交换。应该注意的是，编译时扩展会使得这种逻辑上很简单的等效变得有问
题或者无法实现。
在运行库级别（而非编译器级别）实现范型还有其他一些好处。其中一个好处是范型
信息会在编译和执行期间保留下来，因此在代码生存期的任何时刻都可以访问它。例
如，反射提供对范型元数据的完全访问。另一个好处是 Visual Studio .NET 中丰富的
IntelliSense 支持，以及范型代码所带来的舒心的调试体验。相反，Java 范型和 C++
模板在运行时会失去它们的范型标识。
另一个好处（也是 CLR 的支柱）是交叉语言使用 — 使用一种托管语言定义的范型可
以由用另一种托管语言编写的代码引用。同时，由于许多繁重的工作都是在这个平台
上完成的，所以语言供应商在他们的编译器中置入范型支持的可能性与日剧增。
在运行时类型扩展的众多好处中，我最喜欢的那一个就显得微不足道了。范型代码只
限明确用于类型构造实例化的操作使用。这种限制的附加好处是，使 CLR 范型比与它
们相应的 C++ 模板更好理解，也更加有用。让我们看一下 CLR 中对范型的限制。
规则和限制规则和限制
一个困扰使用 C++ 模板的编程人员的问题是许多对类型结构所作的特殊尝试都会失
败，包括类型参数的类型变量在实现由模板化代码调用的方法时会失败。同时，这些
情况下的编译器错误也很令人困扰，而且可能看起来与根本问题不相关。采用构造类
型的运行时扩展以后，类似的错误会变成 JIT 编译器错误或类型加载错误，而不是编
译时错误。CLR 架构师决定了对于范型来说，这种实现是不可接受的。
相反，他们决定了对于范型（例如 Node <T>）的任何可能的类型实例化，即使类型
实例化实际发生在运行时，该范型也必须在编译时被证实为一种有效类型。同样，有
剩余10页未读，继续阅读
资源评论
