这就使得我们面临着一种困难的选择：我们是将这些指代品称为指针，并且继续用指针的语法来表示它们呢？还是引入一种新的类似的语法来表示它们需要特殊的处理？我们最后决定采用后者，看下面的代码：

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 ] ：在翻译 Stan Lippman 先生这篇文章的过程中，我发现 Stan 在遇到第三人称的程序员时，总是使用“ She ”、“ Her ”这样的女性代词，一开始我很困惑，因为感觉很不符合阅读习惯，但我总觉得 Stan 是有意为之。最后我决定向 Stan 询问这样做的用意。果不其然， Stan 的回答是大家习惯用“ He ”是一种男性至上主义者的体现，好像一提起程序员，大家都认为是男性。他并不认同这样的看法，特意嘱我要在翻译的文本中保留“ She ”和“ Her ”的用意，因为他反对那种老套的观点。同时还举出了两位计算机领域的女杰：软件界的先驱之一、汇编语言的创始人 Grace Hopper 博士，以及 Smalltalk 领域的重量级专家 Adele Goldberg 女士。希望 Stan 的良苦用心能够鼓励更多的女性程序员朋友来阅读我们这个专栏 J ? back

[ 译注 2 ] ：单一的根基类为反射提供支持机制的理由在于反射总需要某种形式的 handle 来维护类型信息。比如在 ISO-C++ 中，这样的 handle 需要虚表来支持，如果没有虚表，就不能支持 RTTI ，这使得 ISO-C++ 对反射的支持比较弱。但 CLI 采用在一个公共的 object header 中放入一个 handle 来维护类型信息，巧妙地解决了运行时类型发现的问题。这个公共的 object header 最后就会导致所有的类型都有一个根基类——如果不是刻意隐藏该根基类的话。 back

[ 译注 3 ] ：作者这里没有考虑 Managed C++ 是因为 C++/CLI 是 Managed C++ 的第二版。 back

[ 译注 4 ] ：这里的“执行空间”指的是应用程序运行时的一些基础构造，如程序集、应用程序域等。back