Programming 版 (精华区)
发信人: lofe (〖老夫·为七月奋斗〗), 信区: Programming
标 题: 不知道贴过没有--C++之父 B. Stroustrup 近期言论(转载)
发信站: 哈工大紫丁香 (2001年04月22日21:31:19 星期天), 站内信件
【 以下文字转载自 Computer 讨论区 】
【 原文由 tcpip 所发表 】
--------------------------------------------------------------------------------
C++之父 B. Stroustrup 近期言论
译者 孟岩
侯捷注：本文系 CSDN（中国程序员网站）上的贴文。可读性高，译笔流畅。
承译者孟岩先生应允，
转载於此以飨台湾读者，非常感谢。
未得孟岩先生之同意，任何人请勿将此文再做转载。
以下蓝色为提问，黑色为回答。红色为译注，紫色为侯捷个人认为宜再斟酌之处。
浅蓝色是侯捷个人阅读时的神秘标记。
本繁体文系直接转码，并未将大陆惯用术语转换为台湾惯用术语。
--------------------------------------------------------------------------------
[译者按] Bjarne
Stroustrup博士，1950年出生于丹麦，先後毕业于丹麦阿鲁斯大学和英国剑挢大学，AT&T大
规模程序设计研究部门负责人，AT&T 贝尔实验室和ACM成员。1979年，B.
S开始开发一种语言，当时称为"C with Class"，後来演化为C++。1998年，ANSI/ISO
C++标准建立，同年，B. S推出其经典着作The C++ Programming
Language的第三版。C++的标准化标志 B.
S博士倾20年心血的伟大构想终於实现。但是，计算技术的发展一日千里，就在几年前人们�
共孪隒++最终将一统天下，然而随 Internet的爆炸性增长，类似Java C#等新的
现代感十足的语言咄咄逼人，各种Script语言更是如雨後春笋纷纷涌现。在这种情况下，人
们不禁有些惶恐不安。C++是不是已经过时了呢？其前景如何？标准C++有怎样的意义？应该
如何学习？我们不妨看看B.
S对这些问题的思考。以下文字是译者从Stroustrup1998年之後发表的若干文章
谈话笔记中精选出来的，由於出处不一，内容多有重复，为保持完整，亦一并译出。
以下内容选自B. S在自己主页上发表的FAQ
1. 请谈谈C++书。
没有，也不可能有一本书对於所有人来说都是最好的。不过对於那些真正的程序员来说，如
果他喜欢从"经典风格"的书中间学习一些新的概念和技术，我推荐我的The C++
Programming Language,
1998年的第三版和特别版。那本书讲的是纯而又纯的C++，完全独立於平台和库（当然得讲�
奖曜伎猓８檬槊嫦蚰切┯幸欢ň榈某绦蛟保镏钦莆誄++，但不适合毫无经验的初
学者入门，也不适合那些临时程序员品尝C++快餐。所以这本书的重点在於概念和技术，而�
以谕暾院途沸陨舷铝瞬簧俟Ψ颉Ｈ绻阆胫牢谗酑++会变成今天的模样，我的另一
本书 The Design and Evolution of C++
能给你满意的答案。理解设计的原则和限制能帮助你写出更好的程序。www.accu.org是最好
的书评网站之一，很多有经验的程序员在此仗义执言，不妨去看看。
2. 学习C++要花多长时间？
这要看你说的"学习"是什麽意思了。如果你是一个Pascal程序员，你应该能很快地使你的C+
+水平达到与Pascal相近的程度；而如果你是一个C程序员，一天之内你就能学会使用C++进�
懈錾腃风格编程。另一方面，如果你想完全掌握C++的主要机制，例如数据抽象，面向�
韵蟊喑蹋ㄓ帽喑蹋嫦蚨韵笊杓频鹊龋饲坝侄哉庑┒鞑缓苁煜さ幕埃ㄉ细鲆涣侥
晔遣蛔阄娴摹Ｄ趋崾遣皇撬嫡饩褪茄癈++所需要的时间呢？也许再翻一番，我想打算成
为更出色的设计师和程序员最起码也要这麽长的时间。如果学习一种新的语言不能使我们的
工作和思想方式发生深刻
的变革，那又何苦来哉？跟成为一个钢琴家或者熟练掌握一门外语相比，学习一种新的
不同的语言和编程风格还算是简单的。
3. 了解C是学习C++的先决条件吗？
否
C++中与C相近的子集其实比C语言本身要好学，类型方面的错误会少一些，也不像C那样绕圈
子，还有更好的支持库。所以应该从这个子集开始学习C++。
4. 要想成为真正的OO程序员，我是不是得先学习Smalltalk？
否。如果你想学Smalltaok，尽管去学。这种语言很有趣，而且学习新东西总是一个好主意�
５荢malltalk不是C++，而且把Smalltalk的编程风格用在C++里不会有什麽好结果。如果�
阆氤晌桓龀錾腃++程序员，而且也没有几个月的时间百无聊赖，请你集中力量学好C++�
约捌浔翅岬乃枷搿�
5. 我如何开始学习C++？
这取决于你的基础和学习动机。如果你是个初学者，我想你最好找个有经验的程序员来帮助
你，要不然你在学习和实践中不可避免的犯下的种种错误会大大地打击你的积极性。另外，
即使你的编译器配备了充足的文档资料，一本C++书籍也永远是必不可少的，毕竟文档资料�
皇茄氨喑趟枷氲暮媒滩摹�
选择书籍时，务必注意该书是不是从一开始就讲授标准C++，并且矢志不渝地使用标准库机�
啤＠纾邮淙胫卸寥∫桓鲎址Ω檬钦庋模�
string s; // Standard C++ style
cin >> s;
而不是这样的：
char s[MAX]; /* Standard C style */
scanf("%s",s);
去看看那些扎实的C++程序员们推荐的书吧。记住，没有哪本书对所有人来说都是最好的。�
硗猓吹氐赖腃++程序，而避免用C++的语法写传统风格的程序，新瓶装旧酒没多大意义�
＃ㄒ藕兜氖牵壳霸谑忻嫔系闹形腃++教材中，符合B.
S的这个标准的可以说一本都没有，大家只好到网上找一些英文的资料来学习了。--译者）
6. 怎样改进我的C++程序？
不好说。这取决于你是怎麽使用该语言的。大多数人低估了抽象类和模板的价值，反过来却
肆无忌惮地使用造型机制(cast)和酬。这方面可以看看我的文章和书。抽象类和和模板的作
用当然是提供一种方便的手段建构单根的类层次或者重用函数，但更重要的是，它们作为接
口提供了简洁的 逻辑性的服务表示机制。
7. 语言的选择是不是很重要？
是，但也别指望奇迹。很多人似乎相信某一种语言能够解决他们在系统开发中遇到的几乎所
有问题，他们不断地去寻找完美的编程语言，然後一次次的失败，一次次的沮丧。另外一些
人则将编程语言贬为无关紧要的细节，把大把大把的银子放在开发流程和设计方法上，他们
永远都在用COBOL
C和一些专有语言。一种优秀的语言，例如C++，能帮助设计者和程序员做很多事情，而其能
力和缺陷又能够被清楚地了解和对待。
8. ANSI/ISO标准委员会是不是糟蹋了C++？
当然不是
他们（我们）的工作很出色。你可以在一些细节上找些歪理来挑刺，但我个人对於这种语言
以及新的标准库可是欣欣然。ISO
C++较之C++的以前版本更出色更有条理。相对於标准化过程刚刚开始之初，你今天可以写出
更优雅
更易于维护的C++程序。新的标准库也是一份真正的大礼。由於标准库提供了strings,
lists, vectors,
maps以及作用于其上的基本算法，使用C++的方式已经发生了巨大的变化。
9. 你现在有没有想删除一些C++特性？
没有，真的。问这些问题的人大概是希望我回答下面特性中的一个：多继承 异常
模板和RTTI。但是没有它们，C++就是不完整的。在过去的N年中，我已经反复考虑过它们的
设计，并且与标准委员会一起改进了其细节，但是没有一个能被去掉又不引起大地震。
从语言设计的角度讲，我最不喜欢的部份是与C兼容的那个子集，但又不能把它去掉，因为�
茄造对谙质凳澜缋锕ぷ鞯某绦蛟泵抢此瞪撕μ罅恕++与C兼容，这是一项关键的设计�
霾撸圆皇且桓鼋新舻泥逋贰＜嫒菪缘氖迪趾臀な鞘掷训模肥凳钩绦蛟泵侵两
袷芤媪级唷�
但是现在，C++已经有了新的特性，程序员们可以从麻烦多多的C风格中解脱出来。例如，使
用标准库里的容器类，象vector, list, map,
string等等，可以避免与底层的指针操作技巧混战不休。
10. 如果不必和C兼容，你所创造的语言是不是就会是Java?
不是，差得远。如果人们非要拿C++和Java来作比较，我建议他们去阅读The Design and
Evolution of
C++，看看C++为什麽是今天这个样子，用我在设计C++时遵从的原则来检验这两种语言。这�
┰蛴隨UN的Java开发小组所持的理念显然是不同的。除了表面语法的相似性之外，C++与J
ava是截然不同的语言。在很多方面，Java更像Smalltalk（译者按：我学习Java时用的是Su
n的培训教材，里面清楚地写道：Java在设计上采用了与C++相似的语法，与Smalltalk相似�
挠镆濉Ｋ钥梢运礘ava与C++是貌合神离，与Smalltalk才是心有灵犀）。Java语言相对简�
ィ獠糠质且恢执砭酰糠菔且蛭庵钟镅曰共煌暾Ｋ�
时间的推移，Java在体积和复杂程度上都会大大增长。在体积上它会增长两到三倍，而且会
出现一些实现相关的扩展或者库。这是一条每个成功的商业语言都必须走过的发展之路。随
便分析一种你认为在很大范围内取得了成功的语言，我知道肯定是无有例外者，而且实际上
这非常有道理。
上边这段话是在Java
1.1推出之前写的。我确信Java需要类似模板的机制，并且需要增强对於固有类型的支持。�
虻サ厮担褪俏嘶镜耐暾砸灿Ω米稣庑┕ぷ鳌Ａ硗饣剐枰龊芏嘈〉母亩蟛糠菔
抢┱埂�1998年秋，我从James
Gosling（Java语言的创始人--译者）那里得到一份建议书，说是要在Java中增加固有类型
操作符重载以及数学计算支持。还有一篇论文，是数学分析领域的世界级大师，伯克利大学
的W. Kahan教授所写的How Java's Floating-Point Hurts Everyone
Everywhere（"且看Java的浮点运算如何危害了普天下的芸芸众生"--译者），揭露了Java的
一些秘密。
我发现在电视和出版物中关於Java的鼓吹是不准确的，而且气势汹汹，让人讨厌。大肆叫嚣
凡是非Java的代码都是垃圾，这是对程序员的侮辱；建议把所有的保留代码都用Java重写，
这是丧心病狂，既不现实也不负责任。Sun和他的追随者似乎觉得为了对付微软罪恶的"帝国
时代"，就必须如此自吹自擂。但是侮辱和欺诈只会把那些喜欢使用不同编程语言的程序员�
频轿⑷碚笥锶ァ�
Java并非平台无关，它本身就是平台。跟Windows一样，它也是一个专有的商业平台。也就�
撬担憧梢晕猈indows/Intel编写代码，也可以为Java/JVM编写代码，在任何一种情况下，
你都是在为一个属於某个公司的平台写代码，这些代码都是与该公司的商业利益扯在一起的
。当然你可以使用任何一种语言，结合操作系统的机制来编写可供JVM执行的程序，但是JVM
之类的东西是强烈地偏向于Java语言的。它一点也不像是通用的 公平的
语言中立的VM/OS。
私下里，我会坚持使用可移植的C++作大部份工作，用不同的语言作余下的工作。
（"Java is not platform-independent, it is the platform"，B.
S的这句评语对於C++用户有
很大的影响，译者在国外的几个新闻组里看到，有些C++高手甚至把这句话作为自己的签名�
担员砻鞫訨ava的态度和誓死捍卫C++的决心。实际上有很多程序员不光是把自己喜爱的语
言当成一种工具，更当成一种信仰。--译者）
11. 您怎麽看待C#语言？
就C#语言本身我没什麽好说的。想让我相信这个世界还需要另外一个专有的语言可不是一件
容易的事，而且这个语言还是专门针对某一个专有操作系统的，这就更让我难以接受。直截
了当地说，我不是一个专有语言的痴迷者，而是一个开放的正式标准的拥护者。
12. 在做大项目时，您是不是真的推荐Ada，而不是C++？
当然不是。我不知道这是谁传出来的谣言，肯定是一个Ada信徒，要麽是过份狂热，要麽是�
换澈靡狻�
13. 你愿不愿意将C++与别的语言比较？
抱歉，我不愿意。你可以在The Design and Evolution of C++的介绍性文字里找到原因。
有不少书评家邀请我把C++与其它的语言相比，我已经决定不做此类事情。在此我想重申一�
鑫液芫靡岳匆恢鼻康鞯墓鄣悖河镅灾涞谋冉厦皇谗嵋庖澹还健Ｖ髁饔镅灾涞暮侠
肀冉弦姆押艽蟮木Γ嗍瞬换嵩敢飧冻稣怊岽蟮拇邸Ａ硗饣剐枰诠惴旱挠τ昧煊
蛴谐浞菥椋３忠恢植黄灰� 客观独立的立场，有
公正无私的信念。我没时间，而且作为C++的创造者，在公正无私这一点上我永远不会获得�
耆男湃巍�
人们试图把各种语言拿来比较长短，有些现像我已经一次又一次地注意到，坦率地说我感到
担
。作者们尽力表现的公正无私，但是最终都是无可救药地偏向于某一种特定的应用程序，某
一种特定的编程风格，或者某一种特定的程序员文化。更糟的是，当某一种语言明显地比另
一种语言更出名时，一些不易察觉的偷梁换柱就开始了：比较有名的语言中的缺陷被有意淡
化，而且被拐弯抹角地加以掩饰；而同样的缺陷在不那麽出名的语言里就被描述为致命硬伤
。类似的，有关比较出名的语言的技术资料经常更新，而不太出名的语言的技术资料往往是
几年以前的，试问这种比较有何公正性和意义可言？所以我对於C++之外的语言的评论严格�
拗圃谝话阈缘奶乇鹛囟ǖ姆冻肜铩�
换言之，我认为C++是大多数人开发大部份应用程序时的最佳选择。
14. 别人可是经常拿他们的语言与C++比来比去，这让你感到不自在了吗？
当这些比较不完整或者出於商业目的时，我确实感觉不爽。那些散布最广的比较性评论大多
是由某种语言，比方说Z语言的拥护者发表的，其目的是为了证明Z比其它的语言好。由於C+
+被广泛地使用，所以C++通常成了黑名单上的头一个名字。通常，这类文章被夹在Z语言的�
┗跎烫峁┑牟分校闪似涫谐【赫囊桓鍪侄巍Ａ钊苏鹁氖牵嗟倍嗟拇死嗥缆垡
媚切┰诳语言的公司中工作的雇员的文章，而这些经不起考验文章无非是想证明Z是最�
玫摹Ｌ乇鹗窃谡庑┍冉现腥肥涤幸恍┝懔闵⑸⒌氖率担ㄋ愿咂燮�--译者），毕竟�
挥幸恢钟镅栽谌魏吻榭鱿露际亲詈玫摹++当然不完美，不过请注意，特意选择出来的事实
虽然好像正确，但有时是完全的误导。
以後再看到语言比较方面的文章时，请留心是谁写的，他的表述是不是以事实为依据，以公
正为准绳，特别是评判的标准是不是对於所引述的每一种语言来说都公平合理。这可不容易
做到。
15. 在做小项目时，C优于C++吗？
我认为非也。除了由於缺乏好的C++编译器而导致的问题之外，我从没有看到哪个项目用C会
比用C++更合适。（不过现在C++编译器导致的问题还是不可忽略的，当你看到同样功能的C+
+程序可执行代码体积比C大一倍而且速度慢得多时，会对此有所感触的。--译者）
以下内容来自Visual C++ Developer's Journal主编
Elden Nelson 2000年3月对B. S的专访
16. 如果您现在有机会从头设计C++语言，您会做些什麽不同的事情？
当然，你永远都不可能重新设计一种语言，那没有意义，而且任何一种语言都是它那个时代
的产物。如果让我今天再设计一种语言，我仍然会综合考虑逻辑的优美 效率 通用性
实现的复杂程度和人们的喜好。要知道人们的习惯对於他们的喜好有 巨大的影响。
现在，我会寻找一种简单得多的语法，我会把类型系统的冲突问题限制在很少的几种情况里
，而且你能很容易的发现这些问题。这样就能够很容易的禁止不安全的操作。（B.
S的原则是：对於糟糕的代码，就算是不能完全禁止，至少也要让它大白于天下，而不是藏�
谝醢档慕锹淅锇导巳恕++实际上已经提供了这样的机制，例如如果你使用象reinterpre
t_cast<int>(pointer)这样的很明显是非常糟糕的表达式进行造型，别人会很容易地找到问
题所在。只不过C++仍然允许你使用传统的
C风格的造型机制，而又有不少人一直使用这种老式的风格，所以才引来麻烦多多。B.
S的意思是说，要是现在能够禁止老式的风格该有多好
作为语言设计者的他，恐怕是没有这个机会了，但是作为语言使用者的我们，却还有很大的
希望去改进自己的代码。何去何从，应该是我们深思的时候了。--译者）
我还会把核心语言的体积尽可能搞得小一些，包括类和模板的关键的抽象特性，而把很多其
它的语言特性放在库里来解决。当然我也会保证核心语言足够的强大，使得那些库本身也足
以用这个核心语言来产生。我可不希望标准库的创建需要用到什麽不属於该语言本身的神秘
机制。另外我会让这个核心语言的定义更加精确。（有不少新的语言在建库时就使用了一些
"不属於该语言本身的神秘机制"，比如VB和JAVA。从理论上讲，这是近乎无赖的行径，所以
B. S不以为然。不过从实用出发倒也无伤大雅。--译者）
最重要的是，我会在该语言被广泛使用之前尽可能维持一个很长的酝酿期，这样我可以以其
他人的反馈为基础进行改进。这可能是最困难的，因为一旦有什麽东西是明显出色和有前途
的，大家就会蜂拥而至的来使用它，此後作任何不兼容的修正都会是非常困难的。
我相信这些思想与我当初设计C++时的理念是非常类似的，同样也是这些思想指引
一二十年来C++的不断演化。当然，我认为现在还没有什麽东西能让我觉得像是"完美的语言
"。
17. 您预期C++做哪些增强，会不会删掉一些东西？
很不幸，虽然有一些东西很应该扔掉，但恐怕很难真的删掉任何东西。第一个应该抛弃的东
西就是C风格的造型机制和类型截断转换。就算不禁止，编译器的作者们至少也应该对这种�
形肭苛业木妗Ｎ蚁Ｍ苡美嗨苬ector的东西彻底取代数组，但这显然是不可能的。�
还绻绦蛟泵悄苤鞫褂胿ector来代替数组，就会立刻受益匪浅。关键是你不必再使用C
++中最复杂难缠的技巧了，现在有优秀得多的替代方案。
至於主要的特性，我没想去掉任何东西。特别是那些把C++与C区别开来的主要特性恐怕没法
风平浪静的被抛掉。通常问这些问题的人是希望我挑出诸如多继承 异常
模板等机制来接受批判。所以在这我想大声讲清楚，我认为多继承机制对於静态类型语言实
现继承性来说是必需的，异常机制是在大系统中对付错误的正确方法，模板机制是进行类型
安全的
精致的和高效的程序设计的灵丹妙药。我们可以在小的细节上对於这些机制挑挑刺，但在大
的方面，这些基本的概念都必须坚持。
现在我们仍在学习标准C++，也正在标准所提供的特性基础上发展出更新的
更有趣的编程技术。特别是人们刚刚开始使用STL和异常机制，还有很多高效强大的技术鲜�
酥源罂刹槐丶贝掖业呐苋ピ黾邮谗嵝碌幕啤�
我认为当前的重点是提供很多新的 比以前更加精致的
更有用的库，这方面潜力巨大。例如，如果有一个能被广泛使用的
更精致的支持并发程序设计的库，那将是一大福音--C风格的线程库（例如Pthread--译者）
实在不够好。我们也就可以与各种其他的系统，例如SQL以及不同的组件模型更好地契合起�
础Ｊ导扑懔煊虻娜嗣窃谡夥矫婧孟褚丫咴诹饲懊妫嗨葡馚litz++ POOMA
MTL之类的高效而精致的库的开发已经取得了非凡的成就。（译者在Internet上造访了Blitz
++和POOMA的主页，前者是一个高性能数学库，据称其性能与Fortran
77不相上下，同时又支持大量的C++特性。我想凡是对於数值计算领域有所了解的人都知道�
庥卸圜嵛按蟮囊庖濉OOMA则是一个专门研究C++并行数学算法的项目，它的前景更加不可�
蘖俊Ｒ胝叻浅Ｈ贤珺. S的这个观念。--译者）
有了足够的经验之後，我们就能更好的决定应该对标准做些什麽调整。
18. 显然，这几年世界变了，正在走向一个以Web为中心
分布式计算为主流的时代。那麽您觉得C++还能维持其地位吗？程序员们可不可能把若干种�
ㄓ糜镅裕ū热鏟erl
Javascript）综合运用以彻底取代某一种通用语言？（C++就是这样的通用语言--译者）为�
伺浜闲碌募扑隳Ｊ剑珻++及其标准库应该做怎样的调整？
从来没有哪一种语言能适合所有的工作，我恐怕以後也不会有。实际系统通常是用多种语言
和工具构造起来的。C++只是想成为若干语言和工具中的一个，当某些专用语言在其领域里�
乇鹜怀鍪保强梢杂隒++互为补充。也就是说，我觉得如果大多数现在的专用语言能借助
特定领域的C++库共同工作的话，它们会表现得更出色。脚本语言通常导致难以维护的代码�
乙裁挥懈绦虻慕峁� 可扩展性和可维护性的优化留下什麽余地。
我不敢肯定未来的代码是否真的会是以Web为中心的。就算是直接处理Web的系统也主要是由
处理本地资源，如IP连接之类的程序模块构成的。
地理上的分布性以及服务器软件对於并发机制的高度依赖对於系统的建造者来说的确是个挑
战。有些针对上述问题的库已经出现，也许我们将会看到它们最终得以标准化。当然，一些
原操作和保证规则应该被加到核心语言中以提供对这些库的更佳支持。
总的来说，对於Web和网络，我们非常需要一个真正的系统/网络级的安全模型。指望JavaSc
ript之类的脚本语言实现这个模型无异于白日做梦。
注意，我也没说C++提供了这个问题的解决方式。C++的重心是高效的访问系统资源，而不是
反欺诈。
19.
您看C++未来的走向如何？在接下来的10年里它会衰落吗？或者是基本保持现在的形式？或�
叻⒄贡浠什煌男问剑�
C++有
最美好的未来。用它你能写出伟大的代码。除了故意进行恶意欺诈，C++仍将是开发高性能
高复杂度系统的最好语言。据我所知，没有那种语言能在通用性
效率和精致三方面的统一上可与C++相题并论。
我没看到C++有衰落的徵兆。在我能预见的未来里，它的用途还会不断增长。当然，在未来�
氖昀镂颐腔峥吹揭恍┍浠换嵯衲阆氲媚趋嵯宰拧８恳恢钟镅砸谎珻++也会发展
变化。"语言专家们"要求改进的喧嚣声震耳欲聋，但是系统开发者们的基本请求是保持稳定
。
C++会改进，但是这些改进将主要是为了反映从实践中得来的经验教训，而不会是为了追风�
懈鲜摈帧Ｎ烁咝У厥褂靡恍┬碌谋喑碳际酰热缤ㄓ帽喑碳际酰赡芑嵩黾右恍┬〉奶
匦浴；嵊写罅康目庥肯郑以て诨岢鱿忠恢终感碌�
更出色的库支持机制。我希望新的扩展主要集中在支持抽象方面的一般特性，而不是为支持
某些特殊任务的特定机制。
例如，"属性"这个概念是很有用的，但我不认为在一种通用编程语言中有它的容身之地。用
标准C++的一组类可以很容易地支持这一概念。如果我们感觉那族类对於"属性"这一概念的�
С植痪∪缛艘猓膊换崃⒖膛苋ピ谟镅岳镌黾邮粜曰疲亲邢缚悸侨绾胃慕嗪湍０逡
园镏馍杓迫嗽本】赡芙咏�"属性"这个概念。也许通过改进函数对象的机制能够给这个问�
庖桓雎獾拇鸶础�
为了使C++在接下来的十几年中保持灵活可变，很基本的一点就是不要让标准C++赶什麽学术
或者商业的时髦。人们要求增加的特性中很大一部份通过使用现有的标准C++开发新库的方�
蕉伎梢允迪帧；褂校率瞪先嗣强释玫降暮芏嗵匦砸丫话ㄔ诒曜糃++中，并且被最新
的编译器支持。
对许多程序员来说，提高代码质量的最佳途径不是追求什麽语言扩展，而是好好地
慢慢地品味最新的C++技术书籍（可惜我们到目前为止连这种机会都没有--译者）。
20.
您怎麽看待脚本语言的兴旺态势？特别是Python，似乎提供了一种学习OO技术的更简单的途
径
有些语言很不错。比如Python，我很喜欢。但是我认为你从不同的语言中学到的OO技术是不
完全相同的。当然，每一个专业的程序员都需要通晓几门语言，并且了解各种语言在编程和
设计技术上的不同。
在我看来，用脚本语言建造的系统与用C++那样的通用语言建造的系统大不相同。从两类语�
灾醒У降募际跚鹈飨浴Ｔ贠O技术里也不存在什麽通用部份对於各种系统的高效建造来说�
际侵凉刂匾摹�
21. 有没有计划往标准C++里增加一些新的特性以支持分布式计算？
没有，我也不认为有这个必要。用更好的库就差不多能解决问题了。最多，为了支持这类的
库，我们可能会增加一些低级的原操作和规则
22. 未来C++有没有可能定一个可移植的二进制接口？
如果你说的"可移植"是指跨硬件和块操作系统的可移植，我想回答是不会。我们当然可以设
计一个解释器或者虚拟机（如同Java的做法--译者），但这样一来，由於无法以最优的方式
访问系统资源，C++的能力就会受到削弱，。我真正希望在不远的将来能够看见的东西是pla
tform ABIs（ABI， Application Binary Interface）
。例如，有人正在努力为Intel新的IA64体系定义C++
ABI，我想这些努力会得到用户们的巨大支持。能够把不同编译器产生的代码编译在一起将�
崾且幌钍钟幸庖宓氖虑椤�
23.
在不少流行领域，C++正在渐渐失去光芒，因为它要求人们花很大的精力去对付一些很基本�
墓ぷ鳎热绻芾砟诖妫ㄒ蛭挥欣占疲芾砟？橹涞囊览敌裕ㄒ蛭挥邪
疲芾碜榧陌姹尽++缺乏一些现代语言已经视为标准的特性。比如传言中最酷的Java
语言就特别重视这些问题。那麽在解决这些问题是否会导致C++的发展背离其根本宗旨呢？C
++应该怎样发展以保证我们在这种语言上的投资能有合理的回报，而不是被迫去重新使用另
一种语言？
我倒还没有注意到C++比以前用的少了。相反，我看到的指标表明C+的使用还在稳定地增长
。只不过这种基数很大的稳定增长以及在标准性
移植性和库方面的不断提高并没有造成什麽具有欺骗性的新闻效应而已。我认为你所说的"�
ス饷�"只不过是市场推销和新闻意义上的现象。
如果你需要垃圾收集机制的话，你可以在C++应用程序中插入一个垃圾收集器。有不少自由�
暮蜕桃档睦占饕丫谥匾氖导斜恢っ魇呛艹錾摹�
如果你不想使用垃圾收集机制，也没关系。你可以使用标准容器类，它们大大减少了对於显
式分配和回收内存的需要。这样，使用现代的库和现代的编程风格，你能够避免大部份的内
存管理问题。
同样的技术还能够用来避免一般资源的管理问题。并不是只有内存才会泄漏，线程句柄
文件 互斥锁
网络连接等都是重要的资源，为了建立可靠的系统，这些资源必须被正确的管理。如果你觉
得有了垃圾收集机制就可以解决所有的资源管理问题，那麽你最好赶快从美梦中醒来。
C++提供了很多机制来管理一般性的资源。关键的手段--"Resource Acquisition is
Initialization"(这是著名的RAII惯用法，阅读原文时会经常遇到，其意义是说将所有的资
源分配申请放在对象初始化过程中进行，而将资源释放动作放在对象销毁过程中——译者)�
梢允褂煤韵罄垂芾砩嫫谖侍狻Ｓ镅灾泄仂抖韵蟮木植抗乖旌鸵斐；贫哉庀罴际跆峁
┝酥С帧�
某些语言的狂热支持者总是用讽刺漫画的笔法描述C++，然而C++实际上要好得多。特别是我
觉得很多其他的特性已经泛滥不堪了，在C++中，通常这些特性能够很容易的被模拟出来。�
喾吹模碌挠镅栽谕乒愕墓讨凶苁遣欢系卦黾有碌奶匦裕饩褪俏谗岽右恢钟镅缘
奖还惴菏褂茫涮寤ǔ；嵩黾痈隽饺丁�
目前，最为个人和组织，对於C++的最好投资就是去更好地理解标准C++和现代的C++设计编�
碳际酢４蠖嗍耸褂肅++的方式实际上停留80年代中期的水平，甚至比那更陈旧。
至於模块依赖性问题，我的观点是，在编程语言的工作和系统的工作之间应该有一个明显的
界线，依赖关系应该尽可能地与编程语言分开，而由系统来支持。
我不认为组建版本的问题应该由编程语言来解决，这是一个系统范畴里的问题，在语言里应
该通过提供相应的库来解决。C++有这样的机制。
解决这样的问题不会使C++偏离轨道。但是给C++增加很多特殊的特性就会使C++偏离轨道，�
以诒３挚梢浦残院推教ǘ懒⑿苑矫嬉不崾且桓龅雇恕�
24.
标准C++推出有段时间了，Java也大踏步地往前走而且取得了显着的进步，您现在怎麽比较J
ava与C++？您觉得Java想要变成像C++一样"好"的语言还需要做些什麽？您举的C++从Java身
上学到了什麽经验吗？有没有什麽Java的特性您认为是可以被C++吸纳的？
我不比较语言。做好这项工作是十分困难的，而且很少具有专业水准。
我认为C++的进步会是主要以它的用户在使用中遇到的问题以及其自身逻辑为基础。当然，�
渌镅灾械哪承┧枷胍不岜豢悸牵荒鼙患虻サ囊苹ń幽竟础Ｄ惚匦肷笫幽切┗圃诩
际跎虾退枷肷系谋尘埃⑶艺业皆贑++中支持这些技术的最佳方案。
有时最好的选择是综合使用几种语言。毕竟没有任何一种语言是放之四海而皆优的。C++现�
谑牵匆布绦崾窃诠惴河τ昧煊蛑凶詈玫挠镅灾弧５牵颐遣荒鼙焕滤荒馨
阉锌赡艿奶匦远技拥紺++里面来向大众献媚。我认为Java和C++现在和将来都会是十分不�
挠镅裕锓ㄏ嗨疲翅岬亩韵竽Ｐ兔飨圆煌�
对於我来说，一个很重要的区别是C++有一个ISO标准，而Java则是一个专有语言。
25.
在Java刚刚出现的那几年，有很多欺骗性的言论说它将会是终极语言，会取代C++。您觉得�
诠チ饺昀颙ava对C++的追随者们有什麽影响？
到现在关於Java的不实之辞也还随处可见。暂且不提Java在过去5年间的创纪录的发展，狂�
鹊拇笾谒坪跞衔狫ava将最终取代的不仅仅是C++，而且还有所有其他的编程语言。但在另一
方面，C++的使用仍在继续增长。我不认为Java对於C++的影响已经使得人们转而把本来打算
用来创造更好的C++工具库的资源调过去开发Java工具库。Java对於学习编程的人来说没有�
嗟男露鳎远造禖++的定义也没什麽影响。在那个领域，Java还得努力追赶。例如，
我认为为Sun迟早会往Java里加入类似模板的机制。
人们应该认识到C++和Java的目标是何等的不同。
以C++的设计理念来衡量Java，或是以Java的设计理念来衡量C++，得出的结论都不会很好。
在访谈即将结束时，或许我该再次表明态度：C++仍然是我喜爱的语言，在写代码时你会发�
置挥心侵钟镅阅芟袼茄谌绱斯惴旱挠τ昧煊蚝推教ㄉ贤贝锍扇绱说母咝в刖隆�
myan 译
-- "这一千多年没写诗了?"
"写了, 不过只写了两句." "千年得两句, 一定是万古丽句了. 念来听听."
"好吧, 我现丑了" 太白星清了清嗓子, 浑厚的男中音在天庭响起:大海啊, 都是水;
骏马啊, 四条腿;
※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: 202.118.230.201]
--
※ 转载:．哈工大紫丁香 bbs.hit.edu.cn．[FROM: DnC.hit.edu.cn]
Powered by KBS BBS 2.0 (http://dev.kcn.cn)
页面执行时间：202.767毫秒