扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条
作者:佚名 来源:中国IT实验室 2007年12月11日
关键字: Visual Studio 体验 泛型编程
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接口。只要提供两个方法和一个属性,好像很简单。但是在强类型语言中,提供对所有用户都可用的单一接口其难度是无法想象的。其难就难在我们的实现中无法再使用“???”;
|
类型系统需要你静态标识与属性的存储器回填相关的类型以及获取存取器(accessor)返回类型,但这当然是不可能的。用户需要枚举的潜在类型无以计数。你怎么办?
简单一点的常规解决办法是UTCM,在这里对象被作为容器。
|
这样提供了一定程度上的隔离。它允许用单一不变的代码库来支持潜在的无穷多的类型。并且对于被动存储和引用类型对象的获取,其工作表现不俗。
一旦你需要象混凝土类型那样来获取和处理该对象,事情就变得有些不那么雅致了。这要求向下强制转换为最初的对象类型。不幸的是,编译器没有必要的类型信息来保证强制类型转换的正确性,从而造成程序员得手工显式向下转换,如下例所示:
|
在实现集合时碰到的问题更多,因为无法静态约束某个集合在通用类型容器模型下仅容纳单一类型的对象。这只能从程序一级提供,而且稍显复杂和易错。此外,因为它是一个程序解决方案,只能被用于运行时期。你再次得不到编译器的支持。
除了安全性和复杂性之外,还涉及大规模存储以及在通用类型容器模型下获取值类型的性能问题。借助类型参数化,这三个问题迎刃而解。
什么是参数化的类型?
类型参数模型提供了第二层隔离,消除了向下强制类型转换和框入/框出操作,并允许编译时同类容器元素类型冲突的降格(flagging)。它是一种两步解决方案。在第一步中,将一个类型参数当作一个实际类型的占位符,就像函数所做的那样:
|
在第二步,你告诉编译器(程序的机器阅读器),typeParameter是一个占位而不是一个程序实体。这一步是通过叫做参数化列表的泛型署名来完成的。在C++/CLI中,要么引入generic关键字以选择公共语言运行时(CLR)泛型机制,要么引入template关键字以选择使用C++模板类型机制。如Figure 1所示。
|
这样便导致了一个类型无关的接口定义。之后,当某个类实现IEnumerator时,它必须提供一个实际的类型绑定到typeParameter占位符。这是通过将括弧中实际的类型与参数化类名配对实现的,比如IEnumerator<int>。
如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。
现场直击|2021世界人工智能大会
直击5G创新地带,就在2021MWC上海
5G已至 转型当时——服务提供商如何把握转型的绝佳时机
寻找自己的Flag
华为开发者大会2020(Cloud)- 科技行者