面对C /CLI，很多人的第一个问题自然是“什么是C /CLI”
，我个人喜欢将其看作是位于静态程序设计和动态程序设计
之间的一座桥梁。C /CLI这个名称本身就包含着一组术语—
—而其中最重要的术语却是最不明显的那一个。
首先来看第一个术语“C ”，这当然指的是由Bjarne
Stroustrup在Bell实验室时发明的C 编程语言。它所支持的
是一种为代码执行速度和执行体所占空间所高度优化的静态
对象模型。除了堆内存分配以外，它不支持在运行时对应用
程序进行任何的更改。它允许我们对底层机器进行无限的访
问，但对于正在运行的程序中的活动类型、以及相关的程序
基础构造，它的访问能力却非常有限、或者根本就不可能。
它是一门非常成功的编程语言，但是它却不能适应目前的Web
编程环境以及相关的安全问题——这已经成为目前程序设计
中一个越来越重要的考量。
再来看第三个术语“CLI”，即通用语言基础构造（Common
Language Infrastructure），这是一个支持动态组件编程
模型的多层架构。在许多方面，它所表示的对象模型和C 的
完全相反。在CLI中，存在一个运行时软件层（即虚拟执行环
境）运行在应用程序和底层操作系统之间，应用程序代码对
底层机器的访问会受到相当严格的限制；事实上，CLI根本不
允许安全环境中的代码进行这样的访问。但另一方面，CLI却
允许我们对正在运行的程序中的活动类型、以及相关的程序
基础构造进行完全的访问，甚至允许我们动态构造额外的类
型和程序基础构造。这些灵活性的获得当然伴随有相当的空
间（执行体所占空间）和时间（程序执行效率）代价，但是
它却解决了日益增长的基于连接的计算环境中所面临的问题
和需要。
最后，再来看第二个术语，即中间的斜线“/”，它往往为人
们所忽略。其表示对C 和CLI的一种绑定（binding），它正
是C /CLI设计的焦点所在。据此，对于“什么是C /CLI”这
一问题可能的一种答案便是“它是对静态C 对象模型和动态
CLI组件模型的一种绑定”。
对于C /CLI，一个C 程序员只需要将其添加到她已有的编程
工具箱中就可以了。要成为一个C /CLI程序员，你无需放弃
任何已有的东西，虽然你要步入一个新的技术世界，你仍然
需要学习它——但愿你能享受这一过程，至少我知道我是这
样的。由此观之，我们还可以将C /CLI看作是一扇通往另一
个世界的大门。
C /CLI将动态的、基于组件的编程模型和ISO-C 集成在了一
起，这种集成非常类似于我们当年在Bell实验室对使用模板
的泛型编程和当时的C 所做的集成。在两种情况下，你已有
的代码投资和编码经验都将得到保留。这是我们设计C /CLI
时一个基本的需求。
通用语言基础构造（CLI）是一个多层的体系架构，它为所有
CLI语言提供了各种各样的服务。例如CLI中定义了一个通用
类型系统（Common Type System，简称CTS），而各个CLI语
言都提供了自己对CTS的一个映射。该类型系统由一个根基类
开始被组织为一个完整的类继承体系。实际上，每一个CLI类
型都是一个类——不仅包括像integer、double这样的数值类
型，而且也包括字面常量（literal constant）。每一个
CLI类型（或者值）都表示一种Object（所有CLI类型的根基
类），比如数值3.14159、比如字符串常量"Homer Simpson"
。
单一的根基类为运行时类型查询和代码生成（通常被称为反
射）提供了支持机制[译注2]，这是ISO-C 所缺乏的。我们将
在今后一系列文章中详细讨论它们给CLI带来的动态编程特性
。
除此之外，CLI还支持一种被称作特性元数据（attribute
metadata）的构造，它允许我们定义一些特性类，然后将其
关联在CLI类型和当前正在运行的程序构造上——这有效地扩
展了内建于CLI中的类型和程序构造。这些用户定义的特性也
可以通过反射机制来获得，应用程序则可以根据它们的值来
进行条件逻辑判断。这也是C /CLI为C 带来的动态组件编程
的一部分。再次强调一遍，类型反射和特性将在我们的专栏
中得到深入的讨论。
AntonlioX(做人要厚道) 于 2005-7-16 14:08:53
那么，对于大家来说怎样学习C /CLI呢？学习C /CLI的其中
一个要点便是学习底层的通用类型系统（CTS），它包括以下
三种类型：
1． 多态引用类型，其用于所有的类继承。我们将在早期的
一些专栏文章中讨论它们。
2． 非多态值类型，其用于实现一些类似于数值类型那样的
、对运行时效率要求比较高的类型。我们将其放在引用类型
之后讨论。
3． 抽象接口类型，其用于定义一组供引用类型或者值类型
实现的操作。接口为多继承提供了一种别样的设计模式。我
们也将有一系列专栏文章来讨论它们。
将CTS映射为一组语言内置类型对于所有的CLI语言都适用，
虽然各种语言所使用的语法各不相同。这也是一门CLI语言所
要面对的第一个设计层面。例如，在C#中，我们可以用以下
代码来定义一个抽象基类型Shape（一些具体的几何对象将继
承自它）。
public abstract class Shape {…}
而在C /CLI中，我们用下面的代码来定义同样的类型。
public ref class Shape abstract {…};
除了语法差异之外，两种声明的实际表示完全相同。类似地
，在C#中，我们可以用下面的代码来定义一个具体类Point2D
。
public struct Point2D {…}
而在C /CLI中，我们用下面的代码来定义同样的类型。
public value class Point2D {…};
我们对语法的选择基于如下的出发点：以一种直观的设计视
角将CLI类型和ISO-C 类型紧密地集成在一起。
因此，简单地说一种语言比另一种语言更接近底层CLI并不正
确。相反，每一门CLI语言都只是表达了自己对底层CLI对象
模型的一种视图。
学习C /CLI的第二个要点是学习我们选择直接提供给程序员
操作的那些底层CLI元素。例如，CLI为所有语言都提供了垃
圾收集服务。一门语言不能选择是否支持垃圾收集，而只能
选择如何更好地提供该服务。
在CLI中，一个引用类型的所有对象都只能被分配在CLI托管
堆上。这意味着C /CLI支持两种动态堆——本地堆（没有任
何形式的自动内存回收机制），和CLI托管堆。对于这两种动
态堆，开发人员通常要用某种形式的new操作符来分配对象；
如果操作成功，对象在堆中初始位置的地址将被返回。但是
两者又有所区别，这是因为CLI托管堆中对象的位置有可能在
垃圾收集器的清除以及随后的压缩中被重新调整。如果一个
对象的位置被重新调整，那么CLI运行时中所含的其中一项服
务会透明地更新所有引用该对象的指代品（thingee）。
这就使得我们面临着一种困难的选择：我们是将这些指代品
称为指针，并且继续用指针的语法来表示它们呢？还是引入
一种新的类似的语法来表示它们需要特殊的处理？我们最后
决定采用后者，看下面的代码：
N *pn = new N;
R ^rn = gcnew R;
这里，N表示一个本地类型，而R表示一个CLI引用类型，帽子
状的符号（^）表示相关的地址是一个托管堆上的追踪句柄（
tracking handle）——也就是说，对象位置的任何重新调整
都会被CLI所追踪，相应的句柄也会被透明地更新。其中关键
字gcnew在这里被用作与CLI托管堆打交道的new表达式。
值类型事实上也可以位于托管堆上，虽然这并非必须。当它
们作为一个引用类型的成员时，就会出现这种情况。如果我
们允许获取一个引用类型内部成员的地址，那么本地指针也
是不合适的，因为这些成员的位置也需要被追踪。一种解决
方法是简单地禁止该项功能。这样语言当然会变得更加简单
，但是同时语言也会变得更弱——例如我们将不能通过增长
元素的地址值来遍历CLI数组，这是因为CLI数组是一个引用
类型，其内的元素都位于托管堆上。不提供这样的功能意味
着CLI数组将不能适用于标准模板库（STL）中的iterator模
式以及泛型算法。对于一个C 程序员来说，这是不可接受的
。
支持获取可能位于托管堆中的值类型的地址同样需要引入一
种追踪指针，我们称之为追踪内部指针（tracking
interior pointer）。另外，我们还支持追踪引用
（tracking reference）这样的概念——它具有类似本地引
用的别名语义，但是它会在必要的时候被CLI透明地更新。最
后，我们还支持一种固定指针（pinning pointer）的概念，
它可以在该指针的作用范围内阻止垃圾收集器移动其所引用
的对象。
这些新的符号及其表示的复杂的间接类型是在我们对托管堆
反复学习和认识之后产生的。面对生存期短暂的托管堆对象
，我们需要某种精巧的方式来认识和使用它们，我们相信这
些额外的间接类型可以给大家很多帮助。我们将在今后的专
栏文章中详细讨论它们。
我们在此对一门CLI语言所选择的第二个设计层面表示了其对
底层CLI实现模型的一层映射。选择什么样的映射取决于该编
程语言定位于什么样的程序及程序员模型。当你选择一门CLI
语言进行编程的时候，你实际上也是在选择遵从一种程序员
模型。我们对于C /CLI程序员的定位是那些历练较深的系统
程序员，这些程序员通常所面对的任务是为高层的商业逻辑
提供基础性的构造和关键性的应用，这时候她就必须要同时
考虑系统的扩展性和性能，因此必须对底层CLI有一个系统级
的视角。
学习C /CLI的第三个要点是学习那些非CLI本身所直接提供的
功能特性。这也是每一门面向CLI的语言所要面对的设计选择
，也是各种CLI语言之间相互区分的一种体现。
例如，CLI本身并不支持多类继承(multiple class
inheritance，简称MCI)，而只支持多接口继承和单类继承。
但Eiffel语言在设计其面向CLI的实现时就选择了支持源代码
级的多类继承。这需要一种巧妙、甚至是复杂的设计将源代
码级的多类继承映射为底层CLI的单类继承模型。Eiffel语言
的设计人员认为这种映射对于CLI平台上的Eiffel程序员是一
个利好的元素。
在此C /CLI的第三个设计层面上，我们没有采用多类继承的
方案。其中一个原因是我们不能说服自己多接口继承模型有
任何不够简单或者优雅的地方。我们没有足够的经验来确定
哪种方案绝对的优秀，但是我的直觉告诉我多类继承（MCI）
是一个死胡同。我们在此设计层面上的主要关注点在于为那
些CLI本身所欠缺的地方提供一些额外的解决方案，我们主要
集中在以下三个方面：
1． 为某些CLI要求手动干预的地方提供一种自动化的解决方
案，例如确定性终止化操作（deterministic finalization
）和稀有资源释放。
2． 提供一些特殊的类成员函数——例如拷贝构造器和拷贝
赋值操作符，以及在CLI直接支持的操作符的基础上再为一些
操作符提供一些扩展支持——例如用来支持函数对象
（function object）设计模式的调用操作符“（）”。
3． 提供一种静态的参数化机制来支持设计适用于CLI类型的
标准模板库（STL），这是因为CLI中的泛型机制在我们来看
对于当代的参数化设计是不够的——虽然我们也支持它们。
以上几点在我们的系列专栏中都将有相关的讨论。特别地，
我们将会详细阐释C /CLI中的模板和泛型机制。
C /CLI的第四个设计层面在于它选择了“集成”而非“替换
”的策略，这是C 以及一些语言所独有的，而其他一些语言
则没有这样做，例如Visual Basic采取的就是“替换”的策
略。一个合法的C 程序是可以顺利通过C /CLI编译，并且可
以正常运行的。我们认为这对于我们的程序员是一项基本的
需求。
谈到C /CLI的第四个设计层面，这究竟是什么意思呢？它表
示我们对C /CLI语言规范和ISO-C 所做的深入的集成。例如
，除了我们扩展支持集合使其也适用于统一的CLI类型系统，
表达式评估的标准转换集合与重载函数的辨析都和ISO-C 的
相同。当我们引入模板和多继承机制时，我们也应用了同样
的扩展策略。这些都是在语言中稍显抽象的部分，在某种程
度上我们已经使它们的行为变得更加直观，免除了程序员深
入算法细节的需要。但我们仍会在系列专栏中花费笔墨关注
一些主要的变化，例如对字面常量（literal）字符串的处理
。
在C /CLI未来的版本中，我们希望为本地类型和CLI类型提供
更为无缝的集成。在目前的实现中，仍然存在许多不能跨越
的壁垒。例如，我们现在还不能直接在一个CLI类中声明一个
本地类的实例对象；相反，我们必须声明一个指向那个本地
对象的指针，然后在CLI类的构造器/析构器对中处理对它的
内存分配与释放。我们希望将来能够透明地处理它们。类似
地，如果可以方便地编写下面的代码就更好了：
N^ n = gcnew N;
R* pn = new R;
即将一个本地类透明地放在垃圾收集控制的托管堆中，以及
将一个CLI引用类型透明地放在本地堆中，并使它们正常运行
。这些是我们对于C /CLI未来的一些设想和愿景。随着这些
设想的实现，我们也会在我们的专栏中讨论它们。
AntonlioX(做人要厚道) 于 2005-7-16 14:09:08
最后，再回答一个大家经常问到的一个问题，“我为什么要
学习C /CLI”？首要的原因是C /CLI将会为你进入CLI所表示
的动态组件编程模型领域提供一张第一等的入口签证。如果
你像我一样认为这将成为越来越重要的一种编程模型，并且
如果你是一个历练较深的程序员，那么C /CLI就是你想要的
一个语言工具。如果你不喜欢某些地方，或者发现某些东西
很难表达，那么请告诉我们。我们代表着一个动态编程社区
，C /CLI也会持续不断地前进。
在C /CLI之前，如果我们希望或者需要在CLI所表示的动态编
程领域工作，那么我们只能放弃使用C [译注3]，这意味着我
们同时放弃了我们现存的代码库和编码经验。有了C /CLI之
后，我们就拥有了一条沿着C 向上的移植路径。这是学习C
/CLI的第一个原因。
学习C /CLI的第二个原因在于它允许我们访问整个CLI框架类
库，包括用户界面，线程，网络，XML，ADO.NET，ASP.NET
，以及Web服务这个宽广诱人的世界。另外，在即将推出的
WinFX中，一个封装了整个操作系统的类库体系（包括应用程
序及其执行空间[译注4]）也会被收编在CLI门下。
