最近我访问了中国的上海和北京，参加在两地举办的微软 Tech-ED 技术大会，在那里我非常荣幸地向大家介绍了我们在 C++/CLI 方面的工作。大家的反馈非常之好，非凡是中国年轻一代程序员对 C++/CLI 的热爱和理解给我留下了深刻的印象。在那里，我还熟悉了来自上海的一位开发人员，同时也是一位技术作者， 李建忠 先生。我们经过讨论之后决定合作撰写一系列 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 程序员的定位是那些历练较深的系统程序员，这些程序员通常所面对的任务是为高层的
