C++0x设计之路

每隔一两天，我都会收到关于改进C++的e-mail建议。很多建议如果真的能够成为语言或者标准库的一部分将是一件不错的事情，会让很多程序员深受其益。当然，综合来看，这些建议有很多重复之处，因此，也可以说，在我提出的列表中仅有上百个建议而已——具体的数量取决于你对“相关建议”这个概念的定义。人们希望改进的语言特性的一份不完全列表在 http://www.research.att.com/~bs/evol-issues.html；而与之对应的要求标准库改进的不完全列表则在 http://lafstern.org/matt/wishlist.html。我对这两份列表的基本观点是：前者太长而后者太激进。

      现在，假设你就是ISO C++标准委员会负责人，有权决定下一代C++标准的内容，请你仔细思考：什么是可以加入的？什么是应该剔除的？什么是需要改变的？这不是开玩笑，请暂时中断阅读，严肃认真地权衡把握，然后作出一份改进列表。如果你在读完这篇文章之后仍然对你的结论感到满意，请把它们加上注释并且e-mail给我。

      在修订标准的过程中，有一个问题必须首先明确：我们希望取得什么样的结果？当然，这个问题很难有完美的答案；我们甚至不能准确地定义“我们”这个词的范围到底有多大！C++社群是一个庞大的集体——去年IDC的统计结果是300万人左右——而且这个集体内部还可以细分为很多更小的单位。我们使用现有的几乎全部的计算机和操作系统，与所有的应用软件协同工作，生活在世界上全部的国家。这种情况必然导致我们具有各自完全不同的需求和愿望，而对我而言，这就表示我必须特别小心并且遵循一些基本的原则，以避免在迎合一部分人需要的同时损害了另外一部分人的利益。

      在本文中，我将阐释在往C++0x——下一代C++标准——发展的过程中，我们所必须遵循的一些最主要的原则。很明显，这些原则都是[3]中的“概要原则”的具体发展和体现。这种情况并不是偶然的。我的目的是进一步加强C++中已经被证明了的最具威力的部分，而不是试图去发明一项新的标准进而带来一场翻天覆地的大变化。这就是说，我的目标并不是让标准C++继续成为一门充满活力的语言，C++应该成长，应该适应，应该在我们整个社群现在和将来所面临的各种问题前，成为一件更有效率的工具。在这里，请注意我将行文语气转换成了第一人称，我想强调的是，我只不过是一个拥有很多成员的标准委员会中的一员。C++社群提出了大量的覆盖很多领域的观点，尽管我所持的观点是由大部分成员的认同所支撑的，可是这里给出的原则及其在现实世界中的应用仍然需要进一步的讨论、阐释和试验。这也是对待它们本应有的态度。

      那么，为什么我们不干脆接受所有合情合理的建议，让大家皆大欢喜呢？因为现在已经有了太多的建议等待我们去分析并给出详细而充分的说明。如果我们接受所有的建议的话，那完成这项工作将需要6到7年，而不是2，3年而已；并且将由此产生大量的新特性需要程序员们重新学习，而大部分程序员都将会偏安于一个较小而自我感觉舒适的子集之内，对大部分新特性视而不见；而且这样做的结果将会对“零开销”原则提出严峻的挑战——众多的特性将要求实现者耗费巨大的努力去实现新的标准，而在实现各个不同的特性时又会产生交互影响，还有很多建议的提出根本没有考虑效率因素，并需要一整套复杂而精致的运行时机制对其提供支持。不仅如此，上述一切还是建立在各编译器提供商愿意实现这个新标准的基础上——而我对他们是否愿意还完全没有把握。所以，在你下次想要提出“仅加上我这两个新特性吧”这样的要求前，请仔细考虑上面这些利害关系，三思而后言。

设计和演化

 

      C++0x将会100%兼容现有的C++标准。如果你现有的代码符合C++98标准，那么在过渡到C++0x的过程中，它们将有非常好的可移植性。对这个最好的保证就是标准委员会需要对比你手头更多的旧代码负责。尽管如此，我们也并未固步自封，我们明白C++的进一步进化是必要的，而且我们都希望未来的代码能够更简单、更优雅、更易维护，甚至——更高效。

      我们的目的是兼容，可我们也认识到，在某些情况下，付出微小的不兼容的代价的确能换来巨大的进步。一个明显的例子就是加入一个新的关键字。我们试图避免不兼容，可绝对的“没有不兼容”就意味着“没有改变”或者让新特性都具有丑陋的语法形式。就我个人而言，我极度不喜欢一些折衷、将就的做法。例如：利用宏提供一个__XXX关键字：

#define   XXX  __XXX

而不是直接加入一个新的XXX关键字。这种折衷是为那些持有包含XXX的代码而又无法对其进行修改的人提供的，而这个折衷确是以社群中其他所有人的不便为代价的，并且它给学习者增加了复杂度，并且给那些不太喜欢C++的人又提供了一个廉价的谈资。当然，前面所说的那种情况的确是存在的，可你仍然有别的选择——不升级或者通过一个编译器开关获得向后兼容性。

通常会认为，语言的演化和语言的设计是两件相去甚远的事情。而我想指出这种观点是错误的，语言的演化就等同于语言的设计。只不过，语言的演化和通常想象中的 “白手起家”式的语言设计并不相同，它既要受到现存的大量代码的约束，同时也可以从一些将现有经验直接应用的过程中（通过反馈）受益良多。保证新标准的兼容性是一件非常困难的工作，可我们能籍此使得数量巨大的社群成员轻松地过渡到新标准，并能使得新旧特性之间能够互动交流，平滑合作。选择这种设计式的演化方式，我们也能避免由于我们自身的经验和眼界所限而扼杀一些非常有用的程序设计技术的情况的出现。

如果沉溺于一些微不足道的形式符号表现的问题的话，那语言的设计工作就将变得杂乱无章，毫无条理。一门语言中，最明显最重要的特性就是那些能给其用户提供一种新的更有效率的编程风格的特性。就C++而言，这就意味着语言本身和标准库的变化必须能将一些崭新的编程和设计技术带入主流群体（包括工业界和教育界）的使用之中。只有那些能改变我们思维方式的特性才是值得提供的。

总结：C++0x的目标是在高度可移植的强力限制下做出的一种演化。这种演化应该能在现实世界中带来巨大的改进。

一般和特殊

 

标签：

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