c++的演化被几条“格言”（你不必为你不使用的东西付出代价，与c兼容，等等）所推动，从这个角度来看，c++是成功的，您是否认为这些“格言”需要重新斟酌呢？
bjarne：煽风点火？我倒认为你非常有礼貌而且很专业 — 你的“编辑器或缓和剂（editor/moderator）”去除了真正过激的成分j
某种程度的复杂性是不可避免的，我认为“在语言中以直接支持的形式实现强大而常用的技术”是一个优秀的思想（否则我不会这么做j）。你见到过模仿实现“类层次结构”、“参数化的类型”或者“异常”的c代码吗？这类代码倾向于将指针、转型（casts）和宏弄得一团糟。在c++中，此类代码可以干净而简单地表达出来。至关重要的是，这些构造（constructs）有着详细说明的语义（semantics），而不只是一些对代码的意图进行说明的注释。这样一来，复杂性就从代码转移到了语言定义本身（以及编译器）。
你认为在每个项目中没有必要明确地使用c++的所有特性，这是正确的。然而，这并不意味着你需要强加一些限制性的“指导方针”。请问你什么时候在一个项目中明确使用了unix或nt的所有功能？你希望某个管理者确切地告诉你操作系统的哪些功能可以使用哪些不应该使用吗？它们本来就跟具体的项目毫无关系。
典型的“指导方针”显然来自于“黑暗时代”，它们基于“几年前世界的状态”以及对“什么复杂、什么不复杂”的生疏的假定。那些制定这些“指导方针”的人肯定会说：从总体上看，教育机构在“使学生重点学习c++中有效的关键编程技术”方面做得很差。其后果是导致了“混乱的c风格代码”与“过分臃肿的smalltalk风格的类层次结构”的搀杂状况。对转型（casts）和宏的大量使用，是非最优化使用c++的普遍共同点。
我见过许多成功的c++项目（远比失败的多）以及对c++的“良好”运用。“良好”一词的意思是：优雅、高效、可靠和可维护。因此，对很多人来讲，c++的确已达到了预期的设计效果。请记住，我只对c++做过一点点明确的、“记录资料良好”（well-documented）的承诺（请参阅《d&e》 和《the c++ programming language》）。我不是商业oo骗局的效力者。
我想我明白“c++的成功使用”与“尊重c++的局限性（施加于‘设计’之上深思熟虑的约束）”以及“积极地使设计思路适应于已提供功能”之间的相互关系。例如，如果你在构建一个层次深的层次结构时，拒绝使用抽象类，并且在每一层都定义很多数据成员，你真的不应该惊讶于编译时间之长、重新编译之频繁以及需要理解“某物在何处定义”的问题之多。类似地，如果你不使用c++的功能，而使用c风格字符串、数组、普通结构（plain structs）以及大量的指向低阶数据结构的指针而搞乱你的代码，你也真的不应该惊讶于碰到c风格的问题而不是获得c++所承诺的好处。
c++语言主要的辅导内容在《tc++pl》第一版中有186页，第二版有282页，第三版则有360页。“增加的部分”目的在于进一步强调编程技术。书页数增加（从第一版327页到最新特别版的1040页）的其它原因是为了描述更多的编程和设计技术以及标准库方面的信息。“特别版”花了363页讲述标准库，这还不包括该书其他部分的标准库应用示例程序。
10）提给bjarne的问题（由scherrey提问）
1989年，通过bix online service，您和greg comeau把我带进了c++的世界，当时你们两位开始示范（并最终使我信服）oo并非一时流行的狂热，而且c++语言可以高效地实现oo。《computer language》杂志那段时间正在开设“本月语言”特色专栏，当时编程语言有种“来也匆匆、去也匆匆”的趋势。
在我的印象中，您强调以下两个主要目标：a.构建一种语言，使之可以处理那些c语言难以对付的巨型项目；b.在“特性”和“效率”两方面达到一种平衡，因此开发者要为他用不到的特性而有所付出。
以我个人在种类极其繁多的项目（包括非常“受拘束”的嵌入式系统和大型跨平台的企业级系统）中的c++使用经验来看，毫无疑问，第一个目标已经取得了重大进展，而第二个目标可能已经完全达到了。
然而，最让我失望的是，在系统级的开发中缺少“用c++完全代替老旧平常的c”的能力，而这正是可以通过语言的抽象特性获益最多的领域，同时这也是您声明的语言目标之一。虚函数、继承决议（inheritance resolution）之类的东西的实现技术非常具有“经验主义”性质，因此，在早期我就晓得定义标准abi（application binary interfaces，应用二进制接口）是不可能的。如今已经过了整整十年时间，一个惊人强大的标准也已经出台，这些实现方面的差异，比基于架构方面的考虑更加具有“人为性”。
如今，开放源代码运动在商业和非商业方面的普及工作都进展得如火如荼。不幸的是，c++不能用来提供可连接的api（linkable api），除非降级到严格受限的基于c的连接，或迫使调用你的库的所有用户和你使用一样的编译器 — 因为不存在关于结构和调用约定的标准表示。
您是否认为现在应该优先考虑abi的标准化问题了？果真如此，将使用什么机制定义这些接口（事实上的标准 vs.正规的标准，等等）？谁来做这项工作，还有，哪些工作可以促进这项技术的发展？
bjarne：ben，你好。
我想我做到了高效、通用以及某种程度上的优雅，然而，我低估了连接器（linker）的问题，我可能也低估了因为与c兼容而滋生的问题。
假如我是一个平台供应商，我在几年之前就会优先考虑实现c++ abi了，这么一来，当编译器高度符合标准时，所有基于我的平台的厂商就会提供和我一致的实现。据我的了解，这样的工作已经由sun公司（针对sparc系统）和一群针对intel公司即将推出的merced架构（ia-64，请访问http://reality.sgi.com/dehnert_engr/cxx/）的供应商而展开了。
我将会鼓励所有人 — 尤其是那些编写“意图作为协作成果的一个组成部分”的软件的人来推动实现这种平台abi标准。假如你在此类人之列，请为在你钟爱的平台上实现c++ abi而游说。不幸的是，对于如何做到这一点，我无法提供具体建议。
尽管使用以类或模板表述的高层抽象机制要好得多，但“在系统接口层与c兼容”已经怂恿人们去使用c风格的字符串、数组和结构。他们不但没有使低层工具局限于系统层和类的实现之内，反而让低层结构及其指针弥漫于设计之中。显而易见的后果就是类型错误、“狂野”指针（wild pointers）、数组越界错误和内存泄漏。大量的宏及转型操作（casts）使得代码更加晦涩。眼看着人们陷入一些本可避免的混乱之中，我感到悲哀。
问题的部分原因在于差劲的教育。良好的教育必然是部分解决方案，然而教育也只能起这么大的作用。在我们期望“新手”冲出c子集并使用更强大的技术之前，那些利用现代c++思想而实现的库和工具必须业已遍地开花。
人们应该意识到c++的入门要比c的入门来得容易些。要学习的c++的“最佳初始子集”并不是“c的绝大部分”，与通常情况相比，c++的学习曲线要平滑得多。进一步的讨论请参阅《把标准c++当作一门新语言来学习》一文（可从我的论文网页下载）。
我们一直使用c++编写的应用软件和专门的库来为程序员提供一个高阶的工作环境。标准库的重大意义之一就是为所有人提供了这样的一个榜样。使用标准便利设施（例如string、vector、map以及算法）来编写代码，确实可以改变人们的编程方式以及对编程的思考方式。我希望看到“用于定义和实现标准库”的技术也应用于许多其它领域，从而产生同样的利益 — 无论是在源代码尺寸、类型安全、代码清晰度还是运行时效率方面。
我认为，试验标准c++中的更高级、更有趣的部分的日子已经来临。举个例子，我新撰写的一份补充材料standard-library exception handling展示了一种编程风格，它更加显著地违反了“c的普遍常识”，但它可以使代码更加简洁。尽管此文并非为新手而写，但从中可以一瞥标准库的内部运作情况。
当然了，对于“产品代码”我们必须更加谨慎，因为它们与老代码的兼容性的要求更高。然而，我们也不应囿于老旧风格或兼容问题，以至于不敢尝试更现代、更高效的风格。现在有了原生的c++风格（ native c++ styles），我们应该使用它们。
一些附加评论
coward的匿名人士的评论
这真是一些有趣的东西，我将转发给这儿的每一个人。
我只提一个“负面”的问题：他真的需要那么多次提到他的书吗？好像他从来没有错过一次说“请参阅我的第三版《tc++pl》”之类的话的机会，我往往不信任那些多次提及他们自身或者他们的产品的人。
当然啦，这个问题微不足道，感谢这篇精彩的访谈。
bjarne：不妨设想对一位严肃的画家或雕塑家进行一次广播采访。对于这样的一位艺术家来讲，真正重要的是他（或她）的作品，但又不可能通过广播展示这些作品，你将预期获得很多关于作品以及“人们可以去参观这些作品”的博物馆的参考信息。描述性的言辞绝对是不够的。拙劣的艺术家可能会将讨论主题从作品转移到私生活或政治观点上以作为弥补话题，但严肃的艺术家们不会这样做。
我虽然不是一个艺术家，但对于这样的一个采访来说，同样存在类似的问题。我想展示代码并对问题进行严肃的讨论，但“q&a （问答）”的方式使我无法做到这一点。我的解决办法就是引用我已经出版的著作和我的个人主页。
毕竟，我已经出版的著作是首要的c++资源。因此，我可以坦然地说，如果你希望了解更多的信息，请访问我的个人主页，阅读《tc++pl》、《d&e》或我的论文。
c++和科学计算（由j. chrysostom评论）
作为一名即将毕业的科学计算专业的学生，我有时非常疑惑，为什么c++对数学和科学计算的支持如此有限，而fortran，那个丑陋且难以控制的“野兽”，才是计算数学的唯一“避风港”。
