CLR深入剖析：范型机制与内部运作

82 浏览量更新于2024-08-27 收藏 145KB PDF 举报

"本篇文章详细探讨了公共语言运行库(CLR)中的范型概念，它是C#等.NET编程语言的核心特性。作者首先回顾了上文提到的基础知识，如范型带来的灵活性、代码重用以及性能和类型安全。重点在于理解编译器如何处理CLR中的范型，与C++模板和Java的范型等价物不同，CLR通过在运行时动态展开类型参数来避免代码膨胀，实现了更高的效率和类型等效性。文章深入剖析了类型约束在范型中的作用，即whereT:IComparable这样的约束，它用于限制类型参数必须实现某个接口，确保代码的正确性和一致性。接着，作者讨论了范型类、方法、结构的实现原理，强调了在不同范型实例化下，尽管每个具体类型如Node<Form>和Node<String>看似独立，但通过CLR的机制，它们实际上可以共享大部分编译后的代码，从而减少代码大小。另一个关键点是类型等效性，即使是来自不同程序集的Node<Int32>，由于在运行时共享了相同的CLR类型标识，可以在应用程序中自由地进行对象交换，这对于跨模块协作非常重要。然而，编译时的扩展可能会导致类型等效性在实现上遇到挑战，因此在设计和使用范型时需要谨慎考虑。此外，文章还提到了在运行库级别实现范型的优势，比如能够更好地支持运行时扩展，使得类型在不同环境下的行为保持一致，这对于大型系统和组件化开发具有重要意义。本文深入剖析了CLR中的范型技术，帮助读者理解其内在机制以及在实际开发中的应用策略。"

代码的唯一区别在于，类型变量必须遵守对范型的约束。例如，以下用于 Max <T> 的

引用代码是有效的：

GenericMath.Min(5, 10);

这是因为 5 和 10 都是整数，而且 Int32 类型实现了 IComparable 接口。然而，试图

实现以下 Max <T> 结构会产生编译器错误：

GenericMath.Min(new Object(), new Object());

下面是编译器生成的错误：

MinMax.cs(32,7): error CS0309: The type 'object' must be convertible

to 'System.IComparable' in order to use it as parameter 'T' in the

generic type or method 'GenericMath.Min(T, T)'

对于 T，System.Object 是一个无效的类型变量，因为它没有实现对 T 的约束要求实

现的 IComparable 接口。当类型变量与范型代码上的类型参数不兼容时，约束就可能

会使编译器产生如前面示例中所示的描述性错误。

目前，范型支持三种类型的约束：接口约束、基类约束和构造函数约束。接口约束指

定一个接口，该参数的所有类型变量都必须与这个接口兼容。任意数量的接口约束都

可以应用于给定的类型参数。

基类约束与接口约束类似，但每个类型参数只能包含一个基类约束。如果没有为类型

参数指定约束，则应用 Object 的隐式基类约束。

构造函数约束通过约束实现公共默认构造函数的类型的类型变量，使得范型代码能够

创建由类型参数指定的类型的实例。目前，构造函数约束只支持默认或无参数构造函

数。

where 子句用于为给定的类型参数定义约束或约束列表。每个 where 子句只应用于一

个类型参数。范型或方法定义可以没有 where 子句，也可以有与类型参数一样多的

where 子句。一个给定的 where 子句可以包含一个约束，也可以包含由逗号分隔的约

束列表。

范型的基本规则（范型所有可能的实例化都是有效的，或者范型本身是无效的）还有

其他一些有趣的副作用。第一个是强制类型转换。在范型代码中，类型参数类型的变

量可能只能与它的基类约束类型或基类约束类型的基类进行相互的强制转换。这意味

着，如果类型参数 T 没有约束，它就只能与 Object 引用进行相互强制转换。然而，

如果将 T 约束为进一步派生的类型（例如 FileStream），则范型定义可以包括 T 与

FileStream 以及与 FileStream 的所有基类（直到 Object）之间的相互强制转换。

在这个示例中，T 没有约束，并且被视为未绑定。它具有 Object 的隐式基类约束。T

与 Object 类之间的相互强制转换以及与接口类型之间的相互强制转换在编译时是有效

的。但编译器不允许未绑定的 T 强制转换为其他类型（如 Int32）。范型的强制转换

规则也适用于转换，因此不允许使用强制转换语法来进行类型转换（比如从 Int32 转

换成 Int64）；范型不支持类似的转换。

下面是另一个有趣的事情。请考虑以下代码：

void Foo<T>() {

T x = null; // compiler error when T is unbounded

•••

虽然像这样赋空值很常使用，但可能存在一个问题。如果将 T 扩展为值类型，会出现

什么情况呢？对一个值变量赋空值没有意义。幸运的是，C# 编译器提供了特殊的语

法，以保证正确的结果，而不用管 T 的运行时类型：

void Foo<T>() { T x = T.default; // OK for any T}

等号右边的表达式称为默认值表达式。如果将 T 扩展为引用类型，则 T.default 会解

析为 null。如果将 T 扩展为值类型，则对于该变量，T.default 是所有位都为零的值。

如果 T 未绑定，则不允许对参数化变量 T 赋空值，因此可能有人会认为以下语句也是

无效的，但事实不是如此：

void Foo<T>(T x) {

if (x == null) { // Ok

•••

}

如果此处允许为 null，则将 T 扩展为值类型时会出现什么情况呢？如果 T 是值类型，

剩余10页未读，继续阅读

weixin_38663113

粉丝: 5
资源: 896

CLR深入剖析：范型机制与内部运作

CLR bug

演算法習題部分解答solution_to_CLR

CLR范型深入解析：类型约束、类与方法

SQL Server中调用.NET CLR方法步骤详解

CLR详解

C# CLR原理与线程池详解

C#字符串比较与CLR、IL详解

C#入门：定制Equals方法与CLR/IL详解

.NET CLR文件格式规范详解

CLR泛型详解：类型安全与代码重用

最新资源