荔园在线
荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀
[回到开始]
[上一篇][下一篇]
发信人: tang (独孤九剑〖玄铁重剑〗), 信区: Program
标 题: [转载] B. Stroustrup言论(2)(转寄)
发信站: BBS 荔园晨风站 (Sun Feb 4 18:07:02 2001), 站内信件
【 以下文字转载自 tang 的信箱 】
【 原文由 tang.bbs@smth.org 所发表 】
发信人: immy (smilewolf), 信区: Programming
标 题: B. Stroustrup言论(2)
发信站: BBS 水木清华站 (Sun Feb 4 17:24:47 2001) WWW-POST
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语言的公司中工作的雇员的文章，而这些经不起考验文章无非是
想证明Z是最好的。特别是在这些比较中确实有一些零零散散的事实，（所以更具欺骗性
——译者），毕竟没有一种语言在任何情况下都是最好的。C++当然不完美，不过请注意
，特意选择出来的事实虽然好像正确，但有时是完全的误导。
以后再看到语言比较方面的文章时，请留心是谁写的，他的表述是不是以事实为依据，以
公正为准绳，特别是评判的标准是不是对于所引述的每一种语言来说都公平合理。这可不
容易做到。
15. 在做小项目时，C优于C++吗？
我认为非也。除了由于缺乏好的C++编译器而导致的问题之外，我从没有看到哪个项目用C
会比用C++更合适。
（不过现在C++编译器导致的问题还是不可忽略的，当你看到同样功能的C++程序可执行代
码体积比C大一倍而且速度慢得多时，会对此有所感触的。——译者）
以下内容来自Visual C++ Developer’s Journal主编Elden Nelson 2000年3月对B. S的
专访
16. 如果您现在有机会从头设计C++语言，您会做些什么不同的事情？
当然，你永远都不可能重新设计一种语言，那没有意义，而且任何一种语言都是它那个时
代的产物。如果让我今天再设计一种语言，我仍然会综合考虑逻辑的优美、效率、通用性
、实现的复杂程度和人们的喜好。要知道人们的习惯对于他们的喜好有着巨大的影响。
现在，我会寻找一种简单得多的语法，我会把类型系统的冲突问题限制在很少的几种情况
里，而且你能很容易的发现这些问题。这样就能够很容易的禁止不安全的操作。
（B. S的原则是：对于糟糕的代码，就算是不能完全禁止，至少也要让它大白于天下，而
不是藏在阴暗的角落里暗箭伤人。C++实际上已经提供了这样的机制，例如如果你使用象
reinterpret_cast<int>(pointer)这样的很明显是非常糟糕的表达式进行造型，别人会很
容易地找到问题所在。只不过C++仍然允许你使用传统的、C风格的造型机制，而又有不少
人一直使用这种老式的风格，所以才引来麻烦多多。B. S的意思是说，要是现在能够禁止
老式的风格该有多好！作为语言设计者的他，恐怕是没有这个机会了，但是作为语言使用
者的我们，却还有很大的希望去改进自己的代码。何去何从，应该是我们深思的时候了。
——译者）
我还会把核心语言的体积尽可能搞得小一些，包括类和模板的关键的抽象特性，而把很多
其它的语言特性放在库里来解决。当然我也会保证核心语言足够的强大，使得那些库本身
也足以用这个核心语言来产生。我可不希望标准库的创建需要用到什么不属于该语言本身
的神秘机制。另外我会让这个核心语言的定义更加精确。（有不少新的语言在建库时就使
用了一些“不属于该语言本身的神秘机制”，比如VB和JAVA。从理论上讲，这是近乎无赖
的行径，所以B. S不以为然。不过从实用出发倒也无伤大雅。——译者）
最重要的是，我会在该语言被广泛使用之前尽可能维持一个很长的酝酿期，这样我可以以
其他人的反馈为基础进行改进。这可能是最困难的，因为一旦有什么东西是明显出色和有
前途的，大家就会蜂拥而至的来使用它，此后作任何不兼容的修正都会是非常困难的。
我相信这些思想与我当初设计C++时的理念是非常类似的，同样也是这些思想指引着一二
十年来C++的不断演化。当然，我认为现在还没有什么东西能让我觉得像是“完美的语言
”。
17. 您预期C++做哪些增强，会不会删掉一些东西？
很不幸，虽然有一些东西很应该扔掉，但恐怕很难真的删掉任何东西。第一个应该抛弃的
东西就是C风格的造型机制和类型截断转换。就算不禁止，编译器的作者们至少也应该对
这种行为给与强烈的警告。我希望能用类似vector的东西彻底取代数组，但这显然是不肯
能的。不过如果程序员们能主动使用vector来代替数组，就会立刻受益匪浅。关键是你不
必再使用C++中最复杂难缠的技巧了，现在有优秀得多的替代方案。
至于主要的特性，我没想去掉任何东西。特别是那些把C++与C区别开来的主要特性恐怕没
法风平浪静的被抛掉。通常问这些问题的人是希望我挑出诸如多继承、异常、模板等机制
来接受批判。所以在这我想大声讲清楚，我认为多继承机制对于静态类型语言实现继承性
来说是必需的，异常机制是在大系统中对付错误的正确方法，模板机制是进行类型安全的
、精致的和高效的程序设计的灵丹妙药。我们可以在小的细节上对于这些机制挑挑刺，但
在大的方面，这些基本的概念都必须坚持。
现在我们仍在学习标准C++，也正在标准所提供的特性基础上发展出更新的、更有趣的编
程技术。特别是人们刚刚开始使用STL和异常机制，还有很多高效强大的技术鲜为人知，
所以大可不必急匆匆的跑去增加什么新的机制。
我认为当前的重点是提供很多新的、比以前更加精致的、更有用的库，这方面潜力巨大。
例如，如果有一个能被广泛使用的、更精致的支持并发程序设计的库，那将是一大福音—
—C风格的线程库（例如Pthread——译者）实在不够好。我们也就可以与各种其他的系统
，例如SQL以及不同的组件模型更好地契合起来。数值计算领域的人们在这方面好象已经
走在了前面，类似像Blitz++、POOMA、MTL之类的高效而精致的库的开发已经取得了非凡
的成就。（译者在Internet上造访了Blitz++和POOMA的主页，前者是一个高性能数学库，
据称其性能与Fortran 77不相上下，同时又支持大量的C++特性。我想凡是对于数值计算
领域有所了解的人都知道这有多么伟大的意义。POOMA则是一个专门研究C++并行数学算法
的项目，它的前景更加不可限量。译者非常认同B. S的这个观念。——译者）
有了足够的经验之后，我们就能更好的决定应该对标准做些什么调整。
--
※ 来源:·BBS 水木清华站 smth.org·[FROM: 202.114.80.102]
--
※ 转载:·BBS 荔园晨风站 bbs.szu.edu.cn·[FROM: 166.111.215.107]
[回到开始]
[上一篇][下一篇]
荔园在线首页 友情链接：深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店