C++0x设计之路(4)

通过将语言特性简单映射为硬件功能获得高效率是C++成功的核心（C也一样）。有个明显的例外就是使用异常时C++将要求一个最小的运行时支持。RTTI（dynamic_cast和typeid）和自由存储（new和delete）仅在你直接或间接使用它们时才被包含进来。这种可以消灭潜在开销的能力在某些应用领域——主要是嵌入式领域——是极其重要的。尽管近年来，技术上已经能越来越高效地处理异常问题，可在某些实时性要求极高的领域，其结果还是难以预期。在必要的时候，可以通过编译器开关禁止异常的使用。

C++0x中没有任何事物将会改变现有的状况，C++以前是，并且C++0x将会继续是那些追求最高效率以及最小资源消耗的应用的首选语言。如果C++0x中加入了一些需要运行时支持的特性，那这些特性也肯定会被设计成只有在代码中真正使用了的时候，才会要求获得额外的支持。这就是，著名的“0开销”原则：“不使用，不负责”以及“媲美手写”，这条原则将仍然是C++最根本的信条。

C++的硬件模型非常简单：基本的类型直接映射为硬件能够识别的实体，例如：字节、字以及寄存器；对象间的联系直接映射为硬件间的联系；各种操作直接映射为机器指令；任何操作都可以直接完成，不需要额外的分配、间接性以及不必要的七弯八绕。现在的挑战是如何将并发加入这幅图画中。

总结：C++0x将继续遵循“0开销”原则，并且继续保持能够直接而有效的使用所有硬件的机器模型。

语言和程序库

 

并不是每个库都必须进入标准。

      一门语言不可能覆盖任何事物，可是一个巨大的程序库可以做到这一点。并不是每个库都必须进入标准。C++社群有充足的空间来容纳一个大的标准库和一个工业库（商业的和开源的都可以）。标准委员会的程序库技术报告（Library TR[7]）通过增加正则表达式和哈希表等基础设施的方式扩充了标准库的内容。Boost社群则对什么东西是可能成为标准的给出了另外的例子。然而，甚至这种形式的扩充也无法满足我的胃口。我希望看到C++标准库成为一个系统程序设计的更具弹性的平台，这当然也应该包括对并发和地理上的分布式计算的支持。“分布式”也许超出了社区能力的限制——毕竟我们也只不过是一群有自己的日常工作并且没有多余的经费支持开发的志愿者。尽管如此，我们能够，也必须，怀有梦想。

      “程序库”是一个社区能够承受得起的，能自由探索并有望收获幸运的领域。在这里，社区能够提供大量的（非常重要的）支持。一个程序库和一个语言特性的关键性区别就在于它并不是独占式的：如果你不喜欢一个库，换一个就是。而且，程序库可以在和编译器提供商完全无关的情况下，完全自由地进行开发、测试甚至是部署。C++为各程序库提供的非常富有表现力的机制——甚至在效率要求严格和资源严重受限领域——不应该被低估。现有的例子可以参看Boost [8]。C++0x应该能让建立程序库更有效率。

      一个最常见而普遍的对C++的要求就是一个标准的GUI库。然而技术上、经济上还有政治上对其阻碍力量是巨大的。尽管如此，回顾过去，我们也曾遭遇过对在C++98中融入一个优秀的容器和算法库的巨大阻碍。可结果STL出现了。我希望发生一个奇迹，梦想着能有一个标准的界面将现有的各种商业的和开源的GUI设施标准化。这不能算一个合理的梦想，可正如很多人指出的一样，世界从来不为循规蹈矩的人而改变。

      总结：扩充程序库比扩充语言要好。我们对待语言扩充要谨慎小心，多方求证；而在对待一个新的程序库——特别是当这个库能够扩展系统程序设计的可移植性的时候——我们则应该勇敢果断，敢于探索。

标准和现实

 

      对C++社区而言，ISO标准委员会是重要的，可很明显，它也仅仅是影响C++程序发展的诸多力量中的一小部分。我在此并未提到其他的语言，可C++的天性就是能够与大量系统和程序库协同工作。而这一点，影响了我们对语言特性和程序库的看法。更进一步地说，很多语言改进建议和库扩充建议或多或少都是以“向X语言一样做”这样的要求开始的。我想也许几乎所有语言的较优秀的特性几乎都，在不同时间，曾被建议加入C++中。作为教授，很多标准委员会的成员都对大量的程序设计语言非常熟悉，而我们的经验又会指引着我们做设计决策。请参考[9]，那里阐述了C++和ISO C之间一些特定而微妙的议题。

      C++0x的发展必须及时，而且得到编译器产商的认同，新的语言特性实现起来必须比C++98中最难的容易。

      作为程序员——而且是一个在多种系统上工作的程序员——我们并不喜欢语言中的方言。可这些方言曾经而且也将继续存在。这些非标准的特性主要来源于与操作系统、数据库、中间件的绑定；支持“准标准”是另外的一个原因；而第三个原因就是为了对一小部分人群提供支持，而所提供的特性与C++社区的绝大部分并无关系。我的建议是：只要可能，请尽量避免使用非标准的特性。当避无可避时——这种情况在很多主要系统中都存在——我建议将那些非标准的用法局部化并通过ISO C++为其提供一个标准的存取界面。C++对通用抽象机制的改善很大一部分原因就是让包装这类非标准代码更容易一些。作为替代，可以使用编译器提供的

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有