| | | | | | | [文章信息] | | | 作者: | 许嵩罡编译 | | 时间: | 2005-05-11 | | 出处: | VCKBASE | | 责任编辑: | 方舟 | |
| [文章导读] | | | Visual Studio 2005 为 Microsoft .NET 框架带来了泛型编程的类型参数化模型 | |
| |
|
| | | |
|
|
|
|
|
Visual Studio 2005 为 Microsoft .NET 框架带来了泛型编程的类型参数化模型。当然，类型参数化是C++程序员的事情。所以，对于那些还不熟悉它们的人，我将在本文中对泛型编程做一个简要的介绍。
泛型编程的基本思想是交付固定的代码库，这个代码库支持潜在的无限类型集合。有两种用于泛型编程的常规模型：通用类型容器模型（Universal Type Container Model，UTCM）和类型参数化模型（Type Parameter Model，TPM）。
在 UTCM 中，与对象相关的类型信息已经被剥离。因为它是可还原的，所以容易实现。所有的对象都以一种统一的、非透明的方式存储。而在一个像 CTS（Common Type System）这样单一的类型体系中，通用类型容器就是即 Object；所有的 CTS 类型均直接或间接地的从 Object 中派生。比如说 C 语言中，void * 就是 通用类型。
在 TPM 中，与对象关联的类型信息的绑定已经被提炼和延迟。从一个调用到另一种调用中，值的变化多种多样，它们被提炼为参数。这就是为什么这种实现模型被称为参数化 类型的原因——它更复杂，但功能强大。
例如，你在实现一个 System::Collections 名字空间的 IEnumerator 接口。只要提供两个方法和一个属性，好像很简单。但是在强类型语言中，提供对所有用户都可用的单一接口其难度是无法想象的。其难就难在我们的实现中 无法再使用“???”;
interface class IEnumerator
{
property ??? Current { ??? get(); }
bool MoveNext();
void Reset();
}; |
类型系统需要你静态标识与属性的存储器回填相关的类型以及获取存取器(accessor)返回类型，但这当然是不可能的。用户需要枚举的潜在类型无以计数。你怎么办？
简单一点的常规解决办法是 UTCM，在这里对象被作为容器。
interface class IEnumerator
{
property Object^ Current { Object^ get(); }
bool MoveNext();
void Reset();
}; |
这样提供了一定程度上的隔离。它允许用单一不变的代码库来支持潜在的无穷多的类型。并且对于被动存储和引用类型对象的获取，其工作表现不俗。
一旦你你需要象混凝土类型那样来获取和处理该对象，事情就变得有些不那么雅致了。这要求向下强制转换为最初的对象类型。不幸的是，编译器没有必要的类型信息来保证 强制类型转换的正确性，从而造成程序员得手工显式向下转换，如下例所示：
extern void f( Object^ anyTypeWorks );
Object^ o = "a string of all things";
// no downcast ... passive storage
f( o );
// downcast ... we need to manipulate
String^ s = safe_cast＜String^＞( o ); |
在实现集合时碰到的问题更多，因为无法静态约束某个集合在通用类型容器模型下仅容纳单一类型的对象。这只能从程序一级提供，而且稍显复杂和易错。此外，因为它是一个程序解决方案，只能被用于运行时期。 你再次得不到编译器的支持。
除了安全性和复杂性之外，还涉及大规模存储以及在通用类型容器模型下获取值类型的性能问题。借助类型参数化，这三个问题迎刃而解。
|
|
|
|
|
|
|
|
