工作中的C++:基本原理，重点推荐和结束语

未来的乐趣

在“基本原理”更吸引人的章节中，有一个称为“Future Unifications”（未来统一化）的章节。它给出了一些关于 C++/CLI 未来走势的引人入胜的提示。例如，本机类当前无法从托管类派生，反之亦然。但可以获得同样的效果，解决办法是：将“基”类作为数据成员，然后编写 passthrough 包装程序，该包装程序只起到调用包含的实例的作用。哦，这个听起来挺老套，那么为什么编译器做不到呢？编译器可以将混合对象作为分成两部分的对象表示，其中一个是包含所有 CLI 部分的 CLI 对象，另一个是包含所有 C++ 部分的 C++ 对象。

在这里，Sutter 报道了一个有趣的轶事：当他第一次向 Bjarne Stroustrup 表明这个混合类的主意时，Bjarne 走向书架“然后打开一本书，其中写道他一贯坚持（不管批评）C++ 不必要求对象在一个单独的内存块中连续排列。”那时，没有人看到非连续对象有任何好处 - 但那时也没有谁预料到 .NET 和 CLI。Bjarne 坚持敞开非连续的大门使得混合对象成为可能。如果在未来的 C++/CLI 版本中看到它们，不要惊讶。而寓意就是：当您正在设计一种期望会永久存在并会以不可预计的方式发展的新的语言或复杂的程序时，请不要做不必要的设想，因为这样会让生活更轻松！

“基本原理”提供了另一则有趣的历史珍闻：Redmondtonians 原来为 C++/CLI 取的内部名称是 MC^2。正如在 M（托管）C(++) 中，有一个致与 Albert Einstein 的帽尖 (^)。但正如 Sutter 所说的，那样“太矫揉造作”。我同意。您真的认为如果它被称作 MC^2，大家就会热烈接受 C++/CLI 吗？在决定将其称为 C++/CLI 方面，架构师再一次沿着 Bjarne 的足迹。Bjarne 说：“我选择了 C++，因为它简短、有很好的释义，而且它不是‘修饰的 C’的形式”。C++/CLI 表明 C++ 在前，而且还谨慎地避免了“修饰的 C++”的形式。

“基本原理”证明了其他的 C++/CLI 扩展（像 property、gcnew、generic 和 const）是有效的，并以很有用的常见问题解答部分结束。有关详细信息，请下载“基本原理”自行阅读。说到 const，回到我最初的问题 - 为什么 C++/CLI 允许 const 数据，但不允许 const 函数呢？简短的回答就是：CLI 不允许您将 modopt/modreq 直接放在函数上（尽管 CLI 实际上确实有办法在元数据中编码此信息，只是未测试而已）。至少现在还不行，“基本原理”阐述得很小心，暗示可能某一天会加上这个功能。

编程的演变

C++/CLI 使 C++ 成为了一等 CLI 公民。此外，如果您阅读了“基本原理”，就会意识到做到这一点只对 C++ 作了最少的改动。而且 C++ 仍然是系统编程最好的语言，因为其相对于任何其他语言，提供了更多对 CLI 的直接访问，还因为您如果想要调用旧的 Win32® API（将会陪伴我们更长的时间，我肯定），仍可以降回到 C。

要理解 C++/CLI 有多么重要以及它代表了什么，就必须考虑我们处于编程演变过程中的什么位置。就让我给您一个简洁、特别而快速的回顾吧。在过去，程序员使用切换开关来编写程序。纸带是一个改进，但每台计算机都有其自身的“机器”语言。随着计算机的发展壮大，程序员不得不为每台新的机器都重新编写其程序。唉，那是非常烦的，因此程序员发明了像 FORTRAN、BASIC 和 C 这样的高级语言，使用了称为“编译器”的东西来将高级语言翻译为针对每台机器的机器指令。图 2 说明了这点。现在，可以编写一次程序，然后针对不同的机器进行编译。太酷了！C 语言成为系统编程的选择，因为它是“最低级的高级语言”，这意味着它在自身和机器之间引入了最少的累赘。现在使用的大多数操作系统都是用 C 语言编写的，在少数对性能要求特别严格或与硬件交互的部分可能采用汇编语言进行编码。

许多年以后，C++ 改进了 C 语言，使其面向对象，哦，而且更有趣。再次引用 Bjarne 的话：“C++ 的设计旨在于使作者和他的朋友不必用汇编语言、C 语言或各种现代高级语言来编程。它的主要目的就是使单个程序员更轻松愉快地编写好的程序。”C++ 很棒，但是高级语言互相之间的通讯不太好。如果您用 C++ 编写了某些代码，那么不能在 BASIC 中使用它 - 反过来也一样，至少非常困难。每种语言都在其自己的世界中运行。对于独立的应用程序来说，这很好，但是随着应用程序变得更加复杂和环境更加分散，共享代码的需求就变得更加迫切。从第一个子程序开始，程序员就在寻求完全封装的可重用组件的终极目标：程序员可通过组装软件小构造块来创建应用程序。那么为什么所有部分都得用相同的语言编写呢？

多年来，形成了各种各样解决互操作组件问题的办法。起初，语言与库一起提供（想想 C 运行库和 printf）。在 Windows 领域内，DLL 提供了延时加载（DLL 中的动态）来节约内存。DLL 也提供了互操作性，因为像 Visual Basic 和 COBOL 这样的语言可以调用 DLL，方法是通过引入指引编译器将正确的 C 链接调用发到 DLL 中的导入语句。但是应用程序和 DLL 之间的链接太紧密、太脆弱而且太容易中断。每个应用程序都要知道 DLL 中每个入口的名称和签名。另外，反向调用（从 DLL 到应用程序）也很讨厌，因为您必须传递函数指针作为回调。因此，程序员发明了 VBX，后来成为了 OCX，再后来成为了 COM。很高兴，COM 与语言无关：它具有“类型库”，所以语言不必在链接时知道函数；它们可以在运行时查询类型库。COM 非常酷，但众所周知，很难编写。（讽刺地是，用 C++ 编写 COM 是最困难的，而 COM 正是使用这种语言构思和实现的！）COM 也有其他问题：它太低级了，而且不处理安全性或内存管理这样的事情。

终极目标

现在是 2007 年，我们拥有 .NET Framework 及其标准子集 CLI。通过在编程语言和机器之间插入一个新的抽象层，CLI 以一种截然不同的方式解决了复用性问题。编译器现在生成的是 MSIL 代码，而不是机器指令，然后 CLI 虚拟机/实时 (JIT) 编译器将代码动态编译为机器代码。虚拟机（VES 或虚拟执行系统，对于那些喜欢缩写词的人）提供了一个位于机器之上的抽象层。虚拟机不是新的。事实上，它们已经存在了很长时间。像 Pascal 和 ZIL（Zork Implementation Language，在 Infocom 内部用于编写游戏，我曾在 Infocom 工作过）这样的语言，通过将高级程序编译为 P 代码（或 Z 代码）来运行，随后由虚拟机进行解释。但是，CLI 提供了一个所有语言都可以使用的公共虚拟机（CLI 中的 C）。CLI 支持像类、属性、继承、反射等的基本概念。VES/VM 提供了像内存管理和安全性这样的功能，因此程序员不必担心缓冲区溢出，或者其它可能为恶意病毒打开大门的程序错误。随着 .NET Framework 和 CLI 越来越受欢迎，像 Visual Basic、Fortran、COBOL 和 C# 这样的高级语言都已变得越来越相似，也与 C++ 越来越相似，因为它们都必须支持基本 CLI 概念 - 类、继承、成员函数及其他基本概念。每种语言仍保留其特性，因此程序员不必完全重新学习以使用 .NET Framework；它们只需要学习一些新的概念。

所以，现在程序员可以用他们所选的任何语言来编写类，其他程序员可以用他们所选的任何语言来使用这些类。任何人可以用任何语言来编写任何组件，只需很少的编程就可以使所有组件无缝地一起工作。它们均受益于安全性、垃圾收集和其他的基础特征（CLI 中的 I）。而且，将来 Redmondtonians 添加新的 CLI 特征后，所有语言也都将从中受益。有了 Windows Vista™ 和 .NET Framework 3.0（具有与 Windows Presentation Foundation、Windows Communication Foundation、Windows Workflow Foundation 和 Windows CardSpace™ 这样的新技术相联系的 10,000 个新类），Windows 本身正被作为 CLI 类重写。可重用的、语言无关并且可互操作的组件的目标似乎已经最终达到了。这代表了巨大的模式转变，而且令人惊讶地以一种相对渐进、进化的方式进行。您应该高兴！编程的确是变容易了。

如果您回首凝视，就会发现 C++ 怎么能不参与到这个“勇敢的新世界”呢？C++/CLI 就加入进来了！没有 C++/CLI，C++ 就会成为不能用于编写 Windows 程序的仅有的现代编程语言，处于孤立的位置。C++ 可能会缓慢消亡，或至少严重地被边缘化。C++/CLI 确保不会发生那样的情况。它保证了热爱 C++ 的程序员（像我）可以在新的时代继续使用它。图 2 说明了从物理机器到虚拟机的模式转换，以及“C++”在何处适合和不适合“/CLI”。