(account deleted)出处：http://www.royaloo.com/bjarne/interviews/bsinterview2005.htm (http://www.royaloo.com/bjarne/bjarne.htm)
C++热点问题一席谈
荣耀 访 荣耀/刘未鹏 译
荣耀: 和大多数人一样，我认为C++缺乏一个大一统的库是阻碍C++更为广泛地使用的关键原因，您认为现在C++社群有足够的资源来开发一个像Java或.NET那般规模的库了吗？如果没有，我们该怎么做？我发现使用形形色色的第三方库非常不方便（一个插曲。我在使用微软Visual C++时，有时希望使用STL组件，例如vector，但由于我大幅使用了MFC，而MFC中也有类似的容器，所以，虽然vector更好用，但为了避免因链接两个不同的库而导致文件体积增大，我最终往往放弃使用标准库。不过，倘若标准库提供了MFC所提供的所有功能，我将肯定全部改用标准库）。
Bjarne: 毫无疑问，MFC是迄今为止被广泛运用的最糟糕的基础库。它违反了一个好的C++设计应该遵循的大多数原则。它严重地扭曲了许多程序员对于“什么是C++”的看法！
当然，我也认为缺乏全面且标准的基础库是C++社群的一个主要问题。对于个体程序员来说，这也许是他们面对的最困难的问题。我在《C++语言的设计与演化》中谈到了这一点，至今我仍然坚持这一点。
C++社群没有一个有钱的公司来支持“平台中立的”标准库的开发 — 从来没有，跟其它专有语言（以及它们的“标准”库）相比，这一直是阻碍C++发展的一道藩篱。和专有的基础库的扩展速度相比，我们对标准库的扩展是很慢的（不过和其他ISO标准库相比，我们的扩展速度应该算是比较快的）。我们还期望能够和新兴的非标准库（译注：如Boost）逐渐达成更为平滑的整合。别忘了，当年MFC以及其它“后80年代”风格的库被设计出来投放市场之际，尚无任何标准库可作它们的构建基础。因此，我希望今后的专有库和开源库都能充分尊重标准库，以便使它们之间的互操作变得容易 — 至少容易一点点。
C++社群并不是为大规模设计和实现而组织的。C++社群中也没有什么传统或惯例。和其它社群相比，我们缺少一个“统帅”，他可以有效地激励新库的创建，否决或“保佑”我们的努力和成果。然而，我对“统帅模式”是否可行心里没底 — 除非你所做的事情只是基本的模仿而已。Boost（http://www.boost.org）是一个优秀的成果，它的某些方面已经超出了模仿的范畴，然而它仍然缺乏一个明确的目标以及用于维持自身发展的权威机构或权威人物。
在以下三个相关的领域中，大规模的合作努力对于C++社群而言是必需且有意义的：基本的并发编程库（包括线程、锁和lock-free算法等）；平台无关的操作系统服务库（目录和文件操纵以及套接字等）；以及GUI编程库。前两个看起来是可行的，但要想建立一个标准的GUI库，也许从技术上、经济上尤其是政治上都显得太困难了。
荣耀: 是的，我相信对于许多C++程序员而言，一个标准的GUI库是极其重要的。许多人以为GUI库不是一个太复杂的问题，但我却认为这可能是最棘手的问题。为了解决它，我们可能需要难以置信的大量的资源。同时我认为政治问题可能是其他问题的根源。举个例子，我们知道Windows的GUI风格和Java的GUI风格是不一样的，甚至不同版本的Windows的GUI风格也不一样。而且我们知道GUI风格很不稳定，它发展演化得非常快，而且很容易被微软这样的大公司所引导和操纵。
Bjarne: 在这个问题上，资源（包括财力和人力）是一个关键问题，与“保持设计蓝图的一致性”同样重要。另外，即使我们已经有了这三样东西：蓝图、人力（数打甚至更多）、以及财力（至少要担负得起一些优秀的人在这个项目上的全职工作），这仍然会是个需要N年才能完成的项目。而SUN、微软、苹果以及其他主要竞争对手将会做些什么呢？毕竟包含了一个工业强度的GUI库的ISO标准C++对于它们的专有系统可不啻一记重击啊！我的猜测是它们大多会通过强大的市场手段来保护既得利益，标准委员会可不是为了在这种市场环境中呼风唤雨而组织起来的，我们至少还需要一个工业社团的支持以及和开源社群主力军的联盟。
荣耀: 在您看来，C++要想继续向前发展，除了开发一个更为广泛、更具威力的库以外，我们还应该做些什么？
Bjarne: 我认为库方面的工作是关键。标准委员会没有足够的资源去创建一个全新的库，而且无论如何“让委员会设计”都不是个好主意。如果人们创建了新的库，在紧密相关的领域把它们的努力融合起来以达到冲突最小，并且文献记录良好（并非只记录细节，还有设计原则），那么他们也许可以把这些东西带到委员会来，并有希望让它们成为标准。如果没有成为标准的话，至少他们的努力有最大的机会成为“准”标准。有此打算的人应该把C++真正当作“C++”（使用继承、模板以及异常等）来看待，而不是从其它特性不是那么丰富的语言中抄袭设计而来。如果一个库的设计被发现没有用C++最佳地表达出来，那么它被接受为标准的几率微乎其微。
另一个可作贡献的领域是对技术的开发和推广。C++往往被以“很不理想”的方式使用着，MFC就是一个典型的例子，它甚至还达不到80年代中期对一个良好的OO设计的看法！我所说的“不理想”，是指没有达到它所能达到的可维护性的设计（通常这是由于对设计决策的糟糕的分解、低劣的封装以及对概念的拙劣表达而造成的），而并非指在外部压力下要尽快把项目赶出来的个体程序员或团队的“不理想”。通常，一个较好的设计和现有的实践是背道而驰的，后者往往需要立即付出代价（往往在很短时间内）。显然，任何显著的改进都需要在“一切照常”的基础上，并且至少追加学习所需的代价以及时间上的延迟。
这就把我们带到了最重要并且也许是最明显的改进实践的途径面前：教育。我们对编程和设计的教育必须比当前做得更好。新的语言特性、新技术以及新库碰到了不能理解并使用它们的人仍然是无用之刃。遗憾的是，我们恰恰缺乏优秀的C++入门书籍。Francis Glassborow的新书《You Can Do It》（译注：中文版《C++编程你也行》即将由人民邮电出版社出版）和Koenig & Moo的《Accelerated C++》是打破旧式而令人厌烦的教育方式的例子。那种教育方式把C++当作一个“稍微好一点的C” 或者一门在实现“真正的面向对象”方面失败的语言。前者倾向于用一大堆语言技术细节来迷糊和恼怒读者，偏离了学习好的编程及设计技术的正确道路。后者通常除了存在这些问题之外，还没能够教会在性能攸关的领域里编程的必要技术，而且没有让人感受到静态类型系统的价值。尤其遗憾的是，Glassborow和Koenig & Moo的书的风格都不是编程入门教材的传统风格，这也阻碍了它们的广泛普及。
我自己的两本书《C++程序设计语言》和《C++语言的设计与演化》的目标读者则是已经知道如何去编程然而不知道如何使用C++的人。这两本书确实满足了这部分读者，但我们要做的还不止这些。
任何时候只要有可能，程序员都可以通过将程序的主要部分用ISO C++来写，并将系统依赖性封装起来，从而来支持标准。也就是说，把系统依赖性限定到特定的区域，并通过以标准C++表达的接口去访问它们。通常这并不容易做到，因为厂商总是怂恿程序员在代码中使用专有的、排他性的特性，但这就影响了可移植性，从而使程序移植到其他系统上非常困难。然而，站在应用构建者的立场来说，从长远来看，挣脱厂商的束缚、维持可移植性是一件好事，这种隔离系统依赖性的努力终将从经济和技术两方面都得到回报。
