(整理)C#基础知识_泛型的实现

　　　　本文是截取自MSDN的文章部分，方便自己查看，原文地址：https://msdn.microsoft.com/zh-cn/library/ms379564(VS.80).aspx

　　　　

　　　　泛型实现

　　表面上，C# 泛型的语法看起来与 C++ 模板类似，但是编译器实现和支持它们的方式存在重要差异。正如您将在后文中看到的那样，这对于泛型的使用方式具有重大意义。

　　注 在本文中，当提到 C++ 时，指的是传统 C++，而不是带有托管扩展的 Microsoft C++。

　　与 C++ 模板相比，C# 泛型可以提供增强的安全性，但是在功能方面也受到某种程度的限制。

　　在一些 C++ 编译器中，在您通过特定类型使用模板类之前，编译器甚至不会编译模板代码。当您确实指定了类型时，编译器会以内联方式插入代码，并且将每个出现一般类型参数的地方替换为指定的类型。此外，每当您使用特定类型时，编译器都会插入特定于该类型的代码，而不管您是否已经在应用程序中的其他某个位置为模板类指定了该类型。C++ 链接器负责解决该问题，并且并不总是有效。这可能会导致代码膨胀，从而增加加载时间和内存足迹。

　　在 .NET 2.0 中，泛型在 IL（中间语言）和 CLR 本身中具有本机支持。在编译一般 C# 服务器端代码时，编译器会将其编译为 IL，就像其他任何类型一样。但是，IL 只包含实际特定类型的参数或占位符。此外，一般服务器的元数据包含一般信息。

　　客户端编译器使用该一般元数据来支持类型安全。当客户端提供特定类型而不是一般类型参数时，客户端的编译器将用指定的类型实参来替换服务器元数据中的一般类型参数。这会向客户端的编译器提供类型特定的服务器定义，就好像从未涉及到泛型一样。这样，客户端编译器就可以确保方法参数的正确性，实施类型安全检查，甚至执行类型特定的 IntelliSense。

　　有趣的问题是，.NET 如何将服务器的一般 IL 编译为机器码。原来，所产生的实际机器码取决于指定的类型是值类型还是引用类型。如果客户端指定值类型，则 JIT 编译器将 IL 中的一般类型参数替换为特定的值类型，并且将其编译为本机代码。但是，JIT 编译器会跟踪它已经生成的类型特定的服务器代码。如果请求 JIT 编译器用它已经编译为机器码的值类型编译一般服务器，则它只是返回对该服务器代码的引用。因为 JIT 编译器在以后的所有场合中都将使用相同的值类型特定的服务器代码，所以不存在代码膨胀问题。

　　如果客户端指定引用类型，则 JIT 编译器将服务器 IL 中的一般参数替换为 Object，并将其编译为本机代码。在以后的任何针对引用类型而不是一般类型参数的请求中，都将使用该代码。请注意，采用这种方式，JIT 编译器只会重新使用实际代码。实例仍然按照它们离开托管堆的大小分配空间，并且没有强制类型转换。

泛型的好处

　　.NET 中的泛型使您可以重用代码以及在实现它时付出的努力。类型和内部数据可以在不导致代码膨胀的情况下更改，而不管您使用的是值类型还是引用类型。您可以一次性地开发、测试和部署代码，通过任何类型（包括将来的类型）来重用它，并且全部具有编译器支持和类型安全。因为一般代码不会强行对值类型进行装箱和取消装箱，或者对引用类型进行向下强制类型转换，所以性能得到显著提高。对于值类型，性能通常会提高 200%；对于引用类型，在访问该类型时，可以预期性能最多提高 100%（当然，整个应用程序的性能可能会提高，也可能不会提高）。本文随附的源代码包含一个微型基准应用程序，它在紧密循环中执行堆栈。该应用程序使您可以在基于 Object 的堆栈和一般堆栈上试验值类型和引用类型，以及更改循环迭代的次数以查看泛型对性能产生的影响。