C++0x简讯

关于C++0x核心进展的一组简讯

                                           刘未鹏 /文

              C++的罗浮宫(http://blog.csdn.net/pongba)

 

Concepts无疑是C++0x的杀手级特性之中的一个（也许称它“杀手级”另一个原因：杀死新手:)）。近期关于concepts的提案最终汇聚了Bjarne Stroustrup和Douglas Gregor领导的两派做法之长，已然有大局渐定的端倪。非常多两派之间一直以来的分歧得到了美丽的折衷；辅以concept_map这样美丽而有用的特性，着实非常有说服力，并且，concept眼下的实现竟然隐含着一个潜在的decltype设施，前几天看到Douglas在boost.devel上提到，吓了一跳，自己怎么没有想到呢？想想也自然，人家但是ConceptGCC（GCC with Concepts support）的实现者这一，对于自己实现的东东，当然最熟悉了，呵呵。连David Abrahams看到这个trick时都说自己实在是dumb。Douglas给出的样例是推导函数/仿函数的返回值类型的，眼下boost库里面的result_type设施的实现仍然是侵入式的，远不够完美。而有了concept之后，仅仅需两三行代码就可以实现一个完美的非侵入式result_type设施。实际上，concept作为aspect traits能够推导出一个类的不论什么成员签名里蕴含的类型来，当然也包含使其成为仿函数的operator()的返回值类型了。此外，就我的思考，concept可能蕴含着decltype的一个比較完好的非侵入式实现，至少比方今boost库里面的BOOST_TYPEOF用起来easy，后者须要注冊类型，总的来说，concept引入了比眼下的模板类型推导系统粒度更细的类型推导能力。

此外，concept的定义语法也逐渐成型成熟。尽管像late checking这种特性我还是比較怀疑（实在有点“补丁”的感觉，眼下这个特性也是整个concept系统里面最不稳定的，关于late_check的应用粒度问题还在揣摩其中，只是我想非常可能这个特性会被剔除掉，而代替以更一般性的东西，毕竟显得太“孤立”了。）但毕竟来说整个concept系统已经呈现出所谓的“优雅”的感觉了，正如数学里面的“美”往往意味着正确一样，语言设计里的“优雅”也是如此。希望C++0x的这个主要特性可以美丽的完毕。本来打算单独介绍一下concept迄今为止走过的历史足迹的，然而重于还是抽不出时间好好组织一下，所以干脆仅仅介绍一下最新进展了，有兴趣的朋友可以去C++ Committee Website上搜以往的proposal。

还有一个我非常关心的template特性——variadic templates——近期也露出了十分可喜的迹象。Douglas最终在gcc上做出了第一份实现，并附带了一份新的提案和一个Introduction Paper，此外还用这个新特性又一次实现了tuple、bind、function这三个已增加tr1的库，非常美丽，光是代码量来说，tuple的我算了一下大概节省了2/3，此外还有大幅度提高的可读性和优雅性等等。这个新闻这阵子在新闻组上非常是引起了一些兴奋~:) 跟曾经的两份提案相比，新的提案临时削减了几个小的特性，但基本的特性都已经实现了。这个快两年没有动静，然而十分优雅的语言特性总算迈出了一大步，说实话，前阵子看到C++议会语言进展列表里面把它排在“不活跃”一栏时真是有点操心呢，心想别又等到花都谢了菜都凉了。如今既然编译器实现已出，看来离成熟之期已然不远矣。热心如Alexandrescu者在comp.std.c++上对此也提出了不少建设性意见，看得出来不少人还是非常看好这一特性的，尤其是boosters，光是它给模板库代码可读性带来的提高就是一大亮点，更何况还有代码量的大规模节省，一些十分诡异的（宏的、元编程的）技巧的废弃，等等，全部这些都会使得模板库代码朝向更优雅的方向发展。加上眼下支持者甚众，预计进入0x是基本不会错的了。

 

并发内存模型是还有一个杀手级特性，虽然是个默默无闻的杀手级特性。显然，这是全部新特性里面最难搞清楚的，由于多线程编程本来就是很微妙的东西。Java前几年在这个上面花了相当多的工夫，呵呵，这次C++也就不打算又一次发明轮子了，把现成的Java内存模型削减一些不附合C++国情的方面，“抄”过来就可以:) 有兴趣的能够參考Java标准里面的内存模型部分，以及Boehm的主页上这方面的内容，Boehm是參加过Java内存模型的修订工作的，干起这方面来轻车熟路（http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/）。只是话说回来，刚才说过了这是个默默无闻的杀手级特性，说它杀手级是由于多线程从本质上无法全然以库的形式来实现，非得语言层面支持不可，而并发编程的时代已然到来，并发编程技术将会是极为重要的一项技术，一门现代的语言对此若没有健全的支持是不管怎样不行的，所以这个特性对于C++的今后至关重要，其重要性甚至超过了concept/variadic template这些fancy的语法特性。而说它默默无闻则是由于它并非须要程序猿在日常编程中须要时时关心的东西，就像GC一样，它们都属于在背后默默无闻地提供支持和保障的特性。正如有了GC程序猿就仅仅需关心对象创建一样，有了并发内存模型的语言级支持，程序猿就能够放心地将注意力放到真正的并发编程技术上面了。个人认为C++在这个时候完好内存模型应该不算晚，甚至恰到优点，Herb Sutter说过并发编程的技术发展了这么多年到今天刚刚算是进入业界大规模应用的前夕，并发时代即将到来，而C++恰好将在未来三年内做好准备。对于像C++这样一门主要应用于大规模系统级应用/游戏/图形等开发中的语言，效率是很重要的，而并发则是对效率的有力提升。

 

另外一个不得不说的“工业级”特性就是Module（模块），这也是一个对大规模C++应用可以带来显著优点的特性，相信熟悉的朋友都知道一个事实，如今C++应用尤其是大规模应用的系统编译构建速度越来越成问题，Intel内部的一个统计表明C++头文件里的代码量占整个项目代码量的比重从90年代的10%左右一直涨到如今的超过50%！并且还有上升趋势，由于以模板技术为基础的C++现代库将大量的代码放在头文件里，并且大量运用宏以及高级模板技术，使得编译构建时间大大添加。比方win32gui就是由于boost.signal带来的编译时间太巨而自己设计了一个轻量级的signal类（Qt用的也是自己的QSignal）。《Large Scale C++ Software Design》里面也说头文件的parse是项目构建里面非常虚耗光阴的一个过程（并用多加一层“包括哨位”的笨重手法来缓解）。Module的出现，依据已有经验的预測，可以大幅度缓解这一问题。这也是其主要动因之中的一个（Java是早就有了Module的）。此外Module还能带来另外一些优点（C++里面添加新特性就是这样，一般总要想尽办法挖掘新特性的潜在优点）。只是，像Module这种工业级特性在新闻组上获得的喧哗反而远远不及一些美丽的语法/类型系统层面的特性，希望不会在投票上落选吧:)

 

最后就是几个已经相当成熟的特性了，auto算是其一，实际上这么一个小巧有用，早该增加标准的东东从被提出那一天起就已经是铁板钉钉了。只是，跟auto算是孪生双胞胎的decltype倒是还在摇摆，我感觉decltype还没有定数主要还是它看上去太“难看”了，并且违反DRY原则，其提出的函数的新声明语法实在是有点别扭，倒是期望concept系统可以涵盖其能力，免得搞得太复杂。

当然，还有rvalue/move这个宠儿，rvalue/move也已经进入终于“订正“阶段了，所做的就是一些细微的调整，相同，这也是一个打一提出就等于是鱼上砧板的特性，用一句老美的话，It just feels right!（关于auto和rvalue/move，我曾经的一篇做过一些介绍）

 

除此之外一些还比較有活力的特性有：Initializer（Bjarne领导，旨在统一初始化语法形式、以更好的支持C++的泛型系统。此外还提供更方便的初始化手段）、opaque typedef（比較有意思的特性，可以进一步强化C++的类型系统，降低某些因类型系统不够强健而带来的隐蔽错误的机会，Matthew在《Imperfect C++》中有一章就提到这个问题），跟opaque typedef有点关联的strong typed enums（这个不说大家也知道）、此外，还有aliasing template、new for-loop。

 

差点儿相同吧，最基本的语言特性都在上面了。最令人遗憾的就是，看上去C++在0x是别指望能有reflection能力了。从新闻组上的反应来看，似乎committee guys和boosters对这一特性不是非常热心，的确存在几个第三方的实现，只是都要借助于C++编译器之外的工具。看来非常长一段时间内C++别指望有一个非侵入式的完美serialization库了。其他倒没太大关系，毕竟，C++的应用领域跟如今热火朝天的动态语言不同，后者非常依赖于相似reflection的能力。也许这也是那些guru们不关心这个的原因吧:)

写得匆忙，链接和文献就不一一列举了。主要来自C++ committee website（http://www.open-std.org/JTC1/SC22/WG21/）。