Stan Lippman：C++/CLI全景体验 （4）

学习 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 类的构造器 / 析构器对中处理对它的内存分配与释放。我们希望将来能够透明地处理它们。类似地，如果可以方便地编写下面的代码就更好了：