最近我访问了中国的上海和北京，参加在两地举办的微软Tech-ED技术大会，在那里我非常荣幸地向大家介绍了我们在C++/CLI方面的工作。大家的反馈非常之好，特别是中国年轻一代程序员对C++/CLI的热爱和理解给我留下了深刻的印象。在那里，我还认识了来自上海的一位开发人员，同时也是一位技术作者，
面对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++程序员只需要将其添加到她[译注1]已有的编程工具箱中就可以了。要成为一个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++带来的动态组件编程的一部分。再次强调一遍，类型反射和特性将在我们的专栏中得到深入的讨论。
那么，对于大家来说怎样学习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未来的一些设想和愿景。随着这些设想的实现，我们也会在我们的专栏中讨论它们。
最后，再回答一个大家经常问到的一个问题，“我为什么要学习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门下。
[译注1]：在翻译
[译注2]：单一的根基类为反射提供支持机制的理由在于反射总需要某种形式的handle来维护类型信息。比如在ISO-C++中，这样的handle需要虚表来支持，如果没有虚表，就不能支持RTTI，这使得ISO-C++对反射的支持比较弱。但CLI采用在一个公共的object header中放入一个handle来维护类型信息，巧妙地解决了运行时类型发现的问题。这个公共的object header最后就会导致所有的类型都有一个根基类——如果不是刻意隐藏该根基类的话。
[译注3]：作者这里没有考虑Managed C++是因为C++/CLI是Managed C++的第二版。
[译注4]：这里的“执行空间”指的是应用程序运行时的一些基础构造，如程序集、应用程序域等。
back
声明：本链接仅出于方便阅读的目的，本人充分尊重作者的一切权利。如果原文作者或其权利人认为本链接不符合其利益，请随时和我联系，以便做出有利于作者或其权利人之修正。