Bjarne新文章《Evolving a language in and for the real world: C++ 1991-2006》的读后感
《Evolving a language in and for the real world: C++ 1991-2006》是Bjarne Stroustrup于2007年6月，在HOPL-III上发表的一篇新论文。
文章大体的内容同D&E相近，但补充了一些新的信息，特别是D&E出版后C++的发展和变化，以及对未来的展望。更重要的是，Bjarne一反D&E里中立的态度，比较了几种热门语言同C++的差别，非常有趣。
该文的原版链接在这里（http://www.research.att.com/~bs/hopl-almost-final.pdf）。但水木的overcomeunic不辞辛劳，翻译了这篇整整60页（够得上单行本了）的巨大paper，这里对其表示敬意和万分的感谢。文章中文版的连接在此处：http://groups.google.com/group/pongba/attach/51e4c9025624a302/%E7%AB%8B%E8%B6%B3%E7%8E%B0%E5%AE%9E_%E4%B8%8E%E6%97%B6%E4%BF%B1%E8%BF%9B%EF%BC%9AC%2B%2B_1991-2006.pdf?part=4，也可以从ponba的讨论组TopLanguage里下载（http://groups.google.com/group/pongba/browse_thread/thread/35805f439702e27d）。
我花了大半天的时间，几乎一口气看完了这篇文章，感想颇多。于是决定写下来，同大家一起交流。
开篇是一些概括性的介绍。然后便是早期历史，这些也没什么，D&E上基本都有。引起我注意的，是第8页关于iso标准进程的内容。D&E中讲述过一些，但这里提供了更多的细节信息。有这样一段话引起了我的注意：
“J16委员会的成员是自愿者，他们必须付钱（一年大约800美元）去获得做这些工作的荣幸。因此，大部分的成员代表公司，公司愿意支付会费和旅行开销，但总有一小部分人得为自己买单。”
我把这段paste给一个同事看。他立刻回复我：“倒贴啊！”。不过几秒钟后，他马上发出了感叹：“他们的学术环境很好，中国现在是利字当头，不会有人去做这种事情的。”当然，对于那些公司支付费用的而言，并没什么。令我们感到诧异的是那“一小部分得为自己买单”的人。从文章后面的内容来看，这种苦差事，别说“倒贴”，就是付钱少了，也很少有人原意干的。
这段紧接着讲述WG21(ISO)的情况。然后是投票的方式等等。这段最后以这样一句话结束：
“对于1997/1998的最后标准投票，ANSI投票是43-0，ISO是22-0。我们真的达到了一致性，甚至是全体通过。我被告知这样明确的投票是很不寻常的。”
这种一致性当然是委员会成员长期努力的结果。这也是这个组织充分平衡的结果。当然，后面可以看到，这种平衡通常也会造成很大的问题，甚至是伤害。
“对于大多数成员来说，与C++的早期版本（ARM C++[35]）兼容，与C的早期版本（K&R C[76]）兼容和公司的各种方言兼容是一个严重的事件。我们（委员会的成员们）尝试面对将来的挑战，比如并发，但我们真的牢记C++是许多工具链的基础。破坏C++，那么Java和C#的主要编译器也会被破坏。显然地，委员会不能通过不兼容性来“破坏C++”，尽管不兼容性会破坏C++。工业界会简单地忽视一个严重的带有不兼容的标准，同时开始偏离C++。”
这段内容明显地表明标准化的重要性，同时也表明C++有多么大的历史负担。
3.3节 ISO C++标准进程，第10页，：
“在1991年的Lund（瑞典）会议后，下面的警戒性的传说在C++社团中流行起来：
我们常常提醒自己关于轮船Vasa的故事，那时它是瑞典海军的骄傲，计划建造成有史以来最大和最漂亮的战舰。不幸的是，为了装载足够的雕像和大炮，它在建造过程中经历了重大的重新设计和扩展。结果是它在跨Stockholm港湾的途中，一阵风过后它就沉了，大约
有50人遇难。这艘船已经被打捞上来，你可以从Stockholm的博物馆里看到它。它看起来非常漂亮—比它第一次扩展重新设计前漂亮得多。也比那些17世纪的战舰漂亮得多—但那不能成为它的设计者、建造者和预期的使用者的安慰。
这个故事经常被提起，作为反对增加特征的预警（那就是我告诉委员会的场景）。不管怎么样，对于复杂的事物，总有另一面：如果Vasa已经完成原来的设计，当首次遇到“现代的两层甲板”的战舰，它也同样会被打得满身是洞，沉到海底。忽视世界中的改变也不是选择。”
关于Vasa战舰的故事D&E里已经说过了。最后这一段则是新的内容。这表明了任何事物都必须不断变化。而反过来，为了避免Vasa的结局，应当事先考虑周密，需要更富于远见。
4.1节 STL 第11页
讲述了STL的故事。从STL前的传统做法开始，到STL的创建过程和思想。其中提到了Bjarne对容器的要求：
“STL代码看起来非常不同，然而，多年后我总结出一个清单，那些我认为对于容器来说是很重要的属性都列于其上：
1、单独的容器是简单和高效的
2、容器提供它的“自然的”操作（比如，list提供put和get，vector提供下标操作）
3、简单操作，比如成员访问操作，不需要函数调用用于它们的实现
4、提供公共函数（可以通过迭代器或基类）
5、容器默认是静态类型安全的，并且是homogeneous（即在同一个容器的所有元素的类型相同）
6、heterogeneous容器能够由存储指向共同基类的指针的homogeneous容器所实现
7、容器是非侵入式的（比如，要成为容器的成员，一个对象不需要有特殊的基类或链接的字段）
8、容器能够包含内建类型的元素
9、容器能够包含有外部强加布局的structs
10、容器能应用在一般的框架上（容器和在容器上的操作）
11、没有sort成员函数的容器也能排序
12、“公共服务”（比如persistence）能独立地提供给一组容器（通过基类？）”
这些标准多少有些理想化，但STL都做到了（除了最后一条）。足见Stepanov的智慧。
“它花了我一些时间—很多周—去习惯STL。”
学习STL需要很大的转变，即便Bjarne，也花了这么多时间。其中Koenig起了至关重要的作用。Koenig在C++上所起的作用，可以说仅次于Bjarne，但他的名气远不及Bjarne，甚至Meyes。这位幕后英雄的这种执着，令人敬佩。
4.1.3节 STL理想和概念，p10
“那么STL是什么？它来源于一种尝试，应用数学的一般性的理想去解决数据和算法的问题。对容器里面的对象进行排序并写一个算法去操作这些对象，对这类问题的思考也就是理想的方向，独立和组合地表达概念：
用代码直接表达概念
用代码直接表达概念之间的关系
用独立的代码直接表达独立的概念
组合代码自由表达概念，只要组合言之有理。”
这让我想起了工业界已经使用了百余年的模块化和组件化方式。在过去，很多人都试图让编程也具备这种能力。但STL所展示的技术，则是第一次如此灵活、自由、简洁和优雅地实现了这种方式。STL的出现彻头彻尾地改变了C++的编程，使得C++成为了一种全新的语言。可惜的是，业界似乎尚未从OOP的震撼中清醒过来，对于这种技术的价值，还未有深刻的认识。（这就像神经细胞，一次发放之后，总会有个“不应期”，不对任何刺激做出反应）。
5.2节 export论战，p31
关于Export的论战。讲述了这样一个故事：
“这个伤感传奇的真正主角是EDG编译器的实现者：Steve Adamczyk，John Spicer和David Vandevoorde。他们强烈反对分离模板编译，最后为达到最佳妥协投赞成票，然后花了超过一年的时候完成了他们所反对的东西。这就是专业！编译器的实现正如他的竞争对手所预测的那样困难。但它成功了并带来了一些好处，正如它的支持者所承诺的那样。不幸的是，由于一些对分离模板编译的必要的约束，因此承诺以因没能提供它们预期的利益并且让编译器变得更加复杂而告终。一如往常，在技术问题上的政客般的承诺导致了“warts”。”
职业的精神，这种人才称得上大师。
5.4 自动废料收集，p34。
出乎我的意料，Bjarne是C++的GC倡导者，甚至还发出了一个提案。我一直以为Bjarne反对gc。C++0x最终还是会引入gc，而且更加完善。或许当时没有加入gc是对的。反观java等语言的gc，显得那么不成熟。现在新的gc模型要进步许多，或许现在才是C++使用gc的时候。
5.5 未完成的工作，p36。
“对“为什么我们没有提供更多有用的库”的回答是简单的：我们没有资源（时间和人力）去做比我们所能做到的更多的工作。”
唉，都是钱闹得。
“在1992年，TI提供他们的非常漂亮的库用于考虑，在一个小时内，有5个主要公司的代表清楚地表达了他们的观点：如果这个库被认真考虑的话，那么他们将推荐他们自己公司的基础库。这不是委员会所能接受的。对一致性要求不是很高的委员会也许会通过从商用库中选择一个来达到目的，但对于C++委员会来说，这是不可能的。”
商业利益总是象一剂毒药，损害着真正重要的东西。
“1994年同样也是必须被记住的，许多人已经认为C++标准库太大了。Java还没有改变程序员的观点，即他们可以从一门语言中免费得到某些东西。反而，C++社团中的许多人使用微小的C标准库作为库大小的比较单位。一些国家代表（荷兰和法国）反复表达他们对C++标准库的膨胀的担忧。象委员会中的大多数人一样，我也希望标准会对C++工业库有所帮助而不是取代它们。”
这些都是平衡带来的问题。
6.1节 性能技术报告，p38。
与其空谈C++的性能如何如何，或者没完没了地争论C++和C谁快，还不如认认真真地去看看这些报告，来提升自己的水平。谁都可以得益，不管用不用C++。
6.2节 TR库，p41。
“尽管标准库和它的扩展的重要性是非常巨大的，我在这里只能简要地列出新的库：
多态函数对象封装器
Tuple类型
数学的特殊函数
类型粹取
正规表达式
增强的成员指针适配器
通用的智能指针
引用封装器
用于计算函数对象返回类型 的统一的方法
增强的binder
hash table”
这些库也都是些基础库，尽管非常关键，有用。但程序员的需求远远超过这些。况且除了boost，还没有哪家厂商正式实现它们。我们只能等待C++0x早日到来。
[解决办法]
这个要顶！
[解决办法]
这篇我喜欢！技术性强的贴子太累了。
[解决办法]
回家再细看。
[解决办法]
收了，这个非常好。
PS：koenig可是唯一一个被以其名字命名C++语言特性的人……
[解决办法]
精彩
[解决办法]
收藏
[解决办法]
事实真的就是这样吗？？？
[解决办法]
这文章要顶一下
[解决办法]
mark
[解决办法]
收起来,慢慢看
[解决办法]
顶
[解决办法]
mark
[解决办法]
瞧瞧先
[解决办法]
这篇论文，需要静下心来，好好学习。
[解决办法]
Wonderful~
Mark~
[解决办法]
mark
xuexi;
