Programming 版 (精华区)

发信人: armstrong (小小), 信区: Programming
标  题: 专访Bjarne Stroustrup
发信站: 哈工大紫丁香 (2001年11月27日21:29:52 星期二), 站内信件

 专访Bjarne Stroustrup(from 《C++ View》)

编者按：在C++ View第1期中我们介绍了这位C++之父，相信大家都很熟悉了。这次，小
编对这位大人物进行了专访，非常感谢Stroustrup博士的精彩回答和耐心的解释。感谢
cber添补的问题，和对小编中国式英语的纠正。同时还要感谢ALNG精彩的中文翻译，这
能方便大家更好地理解Stroustrup博士的深邃思想。关于翻译的一些细节问题，小编与
ALNG争吵了整整一天，大体上达成了一致。有些需要说明的地方，都在文中以楷体注明
。不过小编还得声明，Stroustrup博士回答的内容均以英文为准。
　
The English version of this interview can also be found at http://www.resear
ch.att.com/~bs/01chinese.html.
　
C++的ANSI/ISO标准化标志着C++的成熟。能告诉我们在标准化过程中，您感到最难忘、
最快乐以及最遗憾的事分别是什么吗？
The ANSI/ISO standardization of C++ indicates that the C++ language has matu
red. Would you please tell us the most unforgettable, the happiest and the m
ost regrettable things you felt in the course of standardization?
　
标准化是一个极其有价值的重要活动，它在很大程度上被低估，困难重重。通过标准化
，C++变得更好了，还获得了有着惊人表达力的标准库。编译器提供商总是想锁定用户，
正式的标准化则是用户拥有的为数不多的防御手段之一。
Standardization is an extremely valuable, most important, largely underestim
ated, and most frustrating activity. C++ became a better language through st
andardization and acquired a standard library of surprising expressive power
. Formal standardization is one of the few defenses that a user has against 
the interests of compiler suppliers, who always try to lock in their users.
　
很难挑出特定的事。委员会的大多数工作形式上都是发现、提练、建立信任的过程，要
花时间。不过最重要的事一定是1990年对以The C++ Programming Language第二版（其
中引入了模板和异常机制）作为参考手册来标准化C++的初次投票或1998年批准ISO标准
的最终表决，两者之一。
It's hard to pick out specific events. Most of the work in the committee has
 the form of a process of discovery, refinement, and building of trust. Such
 things take time. However, the single most important event must be either t
he initial 1990 vote to standardize C++ based on the reference manual of the
 2nd edition of "The C++ Programming Language" (that is, with templates and 
exception handling) or the final 1998 vote ratifying the ISO standard. In be
tween those events, the vote to accept the STL as part of the standard libra
ry standard stands out as a most happy event.
　
没有任何负面或遗憾的事可以与这些积极的投票相提并论。所谓“遗憾”的事，要么是
细微的技术细节，要么是（暂时）分化了委员会而使进一步的进展更加困难的讨论。我
本来是反对C风格的cast，也不想引入仅允许整型的静态常量成员在类中初始化的机制。
不过这些只是无关大局的细节。【注：cast翻译成什么好呢？其本意是铸造、打型，诸
位以为，“映射”、“转换”、“型铸”哪一个翻译更贴切呢？或者有其他更好的翻译
？】
There is no negative/regrettable event of a magnitude to match these positiv
e votes. All "regrettable things" are either very minor technical details or
 discussions that (temporarily) polarized the committee so as to make furthe
r progress harder. I would have liked to deprecate C-style casts and not to 
introduce in-class initialization of static const members of integral types 
(only), but these are minor details.
　
我期待着另外一次重要表决。明年某个时间委员会将决定ISO C++的未来方向，这可是头
等大事啊！
I am looking ahead to yet another key vote. Sometime over the next year, the
 committee will decide on the future directions for ISO C++. That will be an
 event of the first magnitude.
　
C++的标准化为何会困难重重？另外可以再谈谈委员会里的工作进程吗？
Why is the standardization of C++ frustrating? And would you please tell us 
more about the process of the work in the committee?
　
标准化是个缓慢的进程，常常聚焦在琐细的技术细节上。你要让几十个来自不同国家、
受过不同技术教育的人达成一致，并需要代表着各种组织（或仅仅本人）的委员富有成
果地合作。C++委员会不是一个满足于60%对40%的差距“获胜”的组织。我们认为这样的
表决结果就是失败。我们的目标是一致同意，意思是“基本人人赞同”。我们为达成一
致不懈努力。很艰难，差不多每个人──起码是有时候──都希望有一个快捷一点的方
式。当然，我们的成果是一个公认能很好地满足一个大得难以置信的群体的需求的语言
，而不是对某一用途或某个人来说的完美语言。最终我们达成了标准的一致通过（ANSI
中43-0， ISO中22-0）。有人告诉我，对编程语言标准而言，这一赞成度前所未有。
Standardization is a slow process, often focused on minute technical details
, and you need to get dozens of people from many countries and from very div
erse technical cultures to agree. Also people representing very different or
ganizations (or just themselves) need to collaborate productively. The C++ c
ommittee is not an organization that is happy with a vote being "won" by a 6
0% to 40% margin. Such a vote would be considered a failure. We aim for cons
ensus, meaning "almost everybody agrees" and work until we reach that. That'
s hard, and everybody - at least sometimes - wish for a faster way. However,
 the result is a language that is acknowledged to be good enough for an incr
edibly large community, rather than being just perfect for any one use or an
y one individual. In the end, we managed to get unanimous votes (43-0 in ANS
I and 22-0 in ISO) for the standard. I have been told that this degree of ag
reement has never before been achieved for a programming language standard.
　
首先委员会要弄清真正的问题和可行的技术解决方案。我称之为“发现”。接着我们把
解决方案提炼成标准文本中精确描述的东西。参加标准过程的个人总是必须学会相互协
作以及相信他人的善意和专业才能。我称之为“建立信任” ──这非常可能是标准进程
中最重要的一部分，没有互信我们将一事无成。
First the committee has to figure out what the real problems are and what ki
nd of technical solution is feasible. This, I referred to as "discovery". Ne
xt we have to refine that solution into something precisely described in sta
ndards text. And always the individuals taking part in the standards process
 must learn to work with each other and to trust the good intent and the pro
fessional abilities of others. That, I referred to as "building of trust" - 
it is quite possibly the most important single part of the standard process;
 without mutual trust nothing can be achieved.
　
Alexander Stepanov说有一次他曾和你争论。因为他认为C++的模版函数应该象Ada通用
类一样显式实例化，而你坚持认为函数应使用重载机制隐式实例化。由于你的坚持，这
一技术后来在STL中发挥了重要作用。能和我们讲讲这个故事吗？
Alexander Stepanov said that once he had argued with you because he thought 
C++ template functions should be explicitly instantiated like Ada generics, 
while you insisted that functions be instantiated implicitly using an overlo
ading mechanism. Thanks to your insistence, this particular technique later 
plays an important part in STL. Could you tell us more about this story?
　
我没有多少可补充的。在模版成为C++的一部分之前，Alex和我花时间讨论过一些语言特
性。在我看来，那时Ada上的经验给了他过分的影响，而他有着我很大程度上缺乏的宝贵
的泛型编程的实践经验。他加强了我对不牺牲效率和内联的偏爱。我们都讨厌宏而喜欢
类型安全。他本来想要更强的模板参数的静态类型检验。我也这么想，不过找不到可以
不限制表达能力或牺牲效率的实现方法。尤其是，我过去是，现在还是，对把模板参数
限制在继承层次的努力持怀疑态度。
I can't add much. Alex and I spent some time discussing language features be
fore templates became part of C++. He was - in my opinion - at the time over
ly influenced by his experience with Ada, but he also had valuable practical
 experience with generic programming that I largely lacked. He reinforced my
 bias in favor of uncompromising efficiency and inlining. We both shared a d
islike of macros and a liking for type safety. He would have liked stronger 
static type checking of template arguments. So would I, but didn't see a way
 of getting that without limiting what could be expressed or compromising ef
ficiency. In particularly, I was - and am - very suspicious of attempts to l
imit template arguments to inheritance hierarchies.
　
后来，Alex创造性地使用了我设计的模板特性，这导致了STL的产生，使得目前人们开始
重视泛型（generic）及生成（generative）编程。和Alex争论很有意思！关于我对他风
格的印象，参看http://www.stlport.org/resources/StepanovUSA.html【注：这是一篇
STL之父Alexander Stepanov的访谈录，内容相当激进，心脏不好的人请做好一切必要准
备^_^。Alex在GP上有极深的造诣，这篇访谈颠覆性不小，甚至可以看到他对OO的批判！
也许彻底抛弃OO很难，但Alex的话极富启发性，值得一看】。
Later, Alex used the template features I designed in innovative ways that le
d to the STL, and to the current emphasis on generic and generative programm
ing. Alex is always fun to argue with! For an impression of his style, see h
ttp://www.stlport.org/resources/StepanovUSA.html.
　
我试验过在不使用语言扩展的情况下约束模板参数的多种方式。我早期的想法在The De
sign and Evolution of C++一书中有叙述，其后期的变体成了现在普遍使用的约束和概
念检查的一部分。这些系统在表现力和弹性上比常见于其他语言的内建设施要强太多。
如果要举例的话，可以参看我的C++ Style and Technique FAQ（http://www.research
.att.com/~bs/bs_faq2.html#constraints）。
I experimented with ways of constraining template arguments without using la
nguage extensions. My early ideas are described in "The Design and Evolution
 of C++" and later variations are part of the now common uses of constraints
 and concept checking. These systems are far more expressive and flexible th
an built-in facilities found in other languages. For an example, see my "C++
 Style and Technique FAQ (http://www.research.att.com/~bs/bs_faq2.html#const
raints).
　
Jerry Schwarz在Standard C++ IOStream and Locales一书中的前言中回顾了IOStream
的历史。我想在从经典流到标准IOStream的转变过程中一定有很多趣事，您能不能给我
们讲一些呢？【注：此书由德国Angelika Langer和Klaus Kreft夫妇编著，是迄今为止
该领域最权威和最完整的著作，中文版《标准C++输入输出流与本地化》由人民邮电出版
社出版。】
Jerry Schwarz reviewed the history of IOStream in the preface of the book St
andard C++ IOStream and Locales. I guess that there must be many interesting
 stories in the process of transiting from classic stream into the standard 
IOStream. Can you tell us some?
　
我不想再给Jerry对从我设计的流到目前的IO流转变的叙述添砖加瓦。然而，我想强调原
来的流库简单而高效，我花了两个月的时间来设计和建构。
I do not want to try to add to Jerry's description of the transition from my
 streams to the current iostreams. Instead, I'd like to emphasize that the o
riginal streams library was a very simple and very efficient library. I desi
gned and built it in a couple of months.
　
关键的决定在于格式与缓冲的分离，并使用类型安全的表达式语法（依赖于<<和>>运算
符）。与AT&T 贝尔实验室的同事Doug McIlroy探讨后，我做出了以上决定。实验表明，
诸如<、>、逗号和=都不适合，后来我选择了<<和>>。类型安全允许一些原本在C风格库
中需要在运行时决定的事，可在编译时决定，因而提供了非凡的性能。我刚开始使用流
后不久，Dave Presotto把我的实作的缓冲部分透明地替换成更好的，不过后来直到他告
诉我，我才注意到这点。【注：请注意“透明（transparently）”这个词，也许这个翻
译不是特别好，但是说明一点，Stroustrup设计的这个流库相当出色，结构相当漂亮，
甚至于库的一部分被换掉了，其功能丝毫不受影响，居然连其作者也没有察觉！】
The key decisions was to separate formatting from buffering, and to use the 
type-safe expression syntax (relying on operators << and >>). I made these d
ecisions after discussions with my colleague Doug McIlroy at AT&T Bell Labs.
 I chose << and >> after experiments showed alternatives, such as < and >, c
omma, and = not to work well. The type safety allowed compile-time resolutio
n of some things that C-style libraries resolve at run-time, thus giving exc
ellent performance. Very soon after I started to use streams, Dave Presotto 
transparently replaced the whole buffering part of my implementation with a 
better one. I didn't even notice he'd done that until he later told me!
　
目前的IO流肯定小不了，不过我相信，在许多通常没有使用IO流全部通用性的情形下，
借助于强力的优化，我们可以重获原来的效率。注意，IO流那样的复杂度是为了应付我
原来的经典流没有考虑的需求。例如，带本地化的标准IO流就可以处理经典流力不能及
的汉字和汉字串。
The current iostreams library will never be small, but I believe that aggres
sive optimization techniques will allow us to regain the efficiency of the o
riginal in the many common cases where the full generality of iostreams is n
ot used. Note that much of the complexity in iostreams exist to serve needs 
that my original iostreams didn't address. For example, standard iostreams w
ith locales can handle Chinese characters and strings in ways that are beyon
d the scope of my original streams.
　
有人说Java是纯粹面向对象的，而C#更胜一筹。而还有很多人说它们纯粹是面向金钱的
。以您之见呢？
It's said that Java is purely object-oriented, while C# is even more. And ma
ny people say they are purely money-oriented. What's your opinion?
　
我喜欢“面向金钱”这个词 :-) 还有Andrew Koenig的说法“面向大话”我也喜欢。 C
++可不面向这两个东东。
I like the term "money-oriented" :-) I also like Andrew Koenig's phrase "buz
zword-oriented". C++ is neither.
　
对这点我还想指出，我认为纯粹性并非什么优点。C++显著地强项恰恰在于其支持多种有
效的编程风格（多种思维模型吧，如果你一定要这么说）及其组合。最优雅最有效也最
容易维护的解决方案常常涉及到一种以上的风格（编程模型）。如果一定要用吸引人的
字眼，C++是一种多思维模型的语言。在软件开发的庞大领域，需求千变万化，起码需要
一种支持多种编程的设计风格的通用语言，而且很可能需要一种以上呢。再说，世界之
大，总容得下好几种编程语言吧？那种认为一种语言对所有应用和每个程序员都是最好
的看法，根本就是荒谬的。【注：paradigm的中文翻译似乎没有约定。ALNG偏好“典范
”或者“范式”，小编则喜欢侯捷先生使用的“思维模式”或者“思维模型”。总之，
paradigm的大概意思是an example or pattern，大家理解就好。】
More to the point, I don't think "purity" is a virtue. The signal strength o
f C++ is exactly that it supports several effective styles of programming (s
everal paradigms, if you must), and combinations of these styles. Often, the
 most elegant, most efficient, and the most maintainable solution involves m
ore than one style (paradigm). If you must use fancy words, C++ is a multi-p
aradigm programming language. Given the wide variety of demands in the huge 
area of software development, there is a need for at least one general-purpo
se language supporting a range of programming and design styles, and probabl
y for more than one such language. Also, there is room for many programming 
languages in the world. The idea that a single language is best for every ap
plication and every programmer is absurd.
　
Java和C#的主要强项是从其所有者那里得到的支持。这意味着低价（为取得市场份额免
费发放实作和库），强力到无耻的营销（欺骗宣传），以及由于缺乏替代提供商产生的
标准表象。当然，就Java的情形而言，当其他供应商和修改版出现后，版本、兼容性和
移植问题也会像其他语言一样重新冒出来。
Java and C#'s main strengths are the support they receive from their owners.
 This implies a low price (implementations and libraries given away for free
 to gain market share), intensive and unscrupulous marketing (hype), and an 
appearance of a standard due to lack of alternative suppliers. However, when
, as in the case with Java, other suppliers and revised versions eventually 
appear, versioning, compatibility, and portability problems re-emerge, as wi
th other languages.
　
不被语言所有者操纵的开放进程所产生的正式标准是无可替代的。如果用户不想看到这
种语言因为其所有者或者所谓“一般用户”的利益，不顾经济上无足轻重的“少数派”
的反对而改来改去，像ISO这样正式的标准进程，则是唯一的希望。
There is no substitute for formal standards, generated by an open process th
at is not manipulated by a language owner. A formal standards process, such 
as ISO's, is a user's only hope for a language that isn't jerked around for 
the benefit of it's owner or for the benefit of "average users" over the obj
ections of "minorities" deemed economically unimportant.
　
C++本可以简单点或容易使用点（更纯粹，如果你一定要这么说），不过这样就无法支持
那些有着“不同寻常” 的需求的用户了。我个人很关注这么一些人，他们要构建可靠性
、运行效率以及可维护性远高于行业平均水准的系统。我的猜测是在10年的跨度中大多
数程序员都将面临“不同寻常”的技术要求，他们可以从C++的多思维模型结构受益，而
Java和C#之类“简化”语言则爱莫能助。
C++ could be simpler and easier to use (purer, if you must), but not while s
till supporting users with "unusual" demands. I am personally very concerned
 to support people building systems with demands for reliability, run-time p
erformance, and maintainability that are far greater than the industry avera
ge. My conjecture is that over the span of a decade most programmers will fa
ce "unusual" technical requirements that will benefit from C++'s multi-parad
igm structure while not being well served by "simplified" languages such as 
Java and C#.
　
我认为模板和泛型编程是现代C++的核心，是无损效率、类型安全代码的关键。然而它们
并不适合经典的面向对象编程思维模型。
I consider templates and generic programming central to modern C++. They are
 the keys to uncompromisingly efficient, type-safe code. However, they don't
 fit the classical object-oriented paradigm.
　
Ian Joyner在C++??: A Critique of C++ and Programming and Language Trends of 
the 1990s一书中比较了C++和Java并批评了C++的许多机制。你赞成他的观点吗？尤其是
多数新语言都有垃圾收集机制，C++中会加入吗？
In the book C++??: A Critique of C++ and Programming and Language Trends of 
the 1990s, Ian Joyner compared C++ to Java and Eiffel and criticized many me
chanisms of C++. Do you agree with him? Especially, most new languages has a
 garbage collection mechanism. Will it be added to C++? 【注：Ian Joyner这本
书的中文翻译就是本刊连载的“C++批评系列”。】
　
Ian Joyner对C++的观点，我不敢苟同。撇开这点，垃圾收集可能算是有价值的技术，不
过并不是万能丹，它也会带来问题。对C++而言，自动垃圾收集是一个有效的实作技术，
有许多为C++设计的不错的垃圾收集器（商业支持和免费的都有），而且也被广泛地使用
（参看我的C++页面上的链接）。然而C++中垃圾收集机制应该是可选的，这样在不适合
垃圾收集的地方，如严格的实时应用程序，可以免受其累。关于垃圾收集，我的The C+
+ Programming Language一书和我的主页上都用评注，可以参看。
No. I don't agree with Ian Joyner about C++. Independently of that, garbage 
collection can be a valuable technique, but it is not a panacea and it can a
lso cause problems. Automatic garbage collection is a valid implementation t
echnique for C++. Good garbage collectors exist for C++ (both commercially s
upported and free) and are widely used (see links on my C++ page). However, 
garbage collection is optional in C++ so that applications for which GC is u
nsuitable, such as hard real time applications, aren't burdened by it. See m
y comments about GC in "The C++ Programming Language (3rd Edition)" and on m
y home pages.
　
我期望下一个C++标准中能大体上对我上面和其他地方说的内容做出明确的声明。
I expect that the next C++ standard will explicitly state roughly what I jus
t said above and elsewhere.
　
就此而论，C++可以优雅地处理一般的资源，而不仅仅局限于内存。尤其是“resource 
acquisition is initialization（资源获得就是初始化）”技术（参看D&E、TC++PL3和
我的技术FAQ）支持对任意资源进行简单并且符合异常安全（exception-safe）要求的管
理。没有析构函数的Java不可能支持这一技术。
In this context, it is worth noting that C++ has support for elegant techniq
ues for handling resources in general, and not just memory. In particular, t
he "resource acquisition is initialization" technique (see D&E, TC++PL3, and
 my technical FAQ) supports simple, exception-safe management of arbitrary r
esources. Since Java lacks destructors it cannot support that technique.
　
STL是一个超凡脱俗的跨平台架构。有没有考虑在其他方面，比如GUI（图形用户接口）
，设计这样的标准架构？
STL is an excellent cross-platform framework. Have you considered designing 
such standard frameworks on other aspects, GUI for example?
　
很自然地，很多人会想如何在其他领域借鉴STL的成功。比如在数值运算和图论方面都有
了许多有趣的工作。相关链接可以参看我的网页。
Naturally. Many have wondered how to replicate STL's success in other areas.
 For example, interesting work has been done in numerics and for graphs. See
 my C++ page for links.
　
标准GUI价值极大，不过我怀疑其政治上的可行性。太多有钱的大公司在维持其专有GUI
上有着重大的商业利益，而且要求用户放弃现在所使用的GUI库也殊非易事。【注：有朋
友可能奇怪，一个GUI库怎么扯出“政治（politically）”来了？西方人口中的“政治
”，在中文里并没有真正对应的词语。这里的意思是of concerning public affairs，
跟中文里的“政治”无关。下一段就是对这个所谓“政治上的可行性”的详细解释。】

A standard GUI would be of immense value, but I doubt that it is politically
 feasible. Too many rich companies have serious commercial interests in main
taining their proprietary GUIs. Also, users cannot easily change from what t
hey are currently using.
　
这里我所说的可行性是就商业和技术而言。现在有好几种广泛使用的GUI，即使标准委员
会提供一个替代方案，它们也不会就此退出。其所有者和用户──常常有充分理由──
会只是忽略新标准。更糟的情况：某些公司或群体会积极反对这样的标准，因为他们认
为标准不如他们已有的库，或者因为差异太大而使得转换到新GUI不可行。必须理解，如
果标准不能充分服务于其目标用户，用户会视而不见。许多ISO标准因为无人理会而变得
无关紧要。C++标准可不想成为其中一员──把现有实作拉近到一起，标准就功德无量了
──我们不希望将来ISO C++标准被人忽略。
What I refer to is what is commercially and technically feasible. There are 
several very widely used GUIs. They won't just go away if a standards commit
tee decided on an alternative. Their owners and their users would - often fo
r good reasons - simply ignore a new standard. Worse: some company or group 
of people might actively oppose such a standard because they considered it i
nferior to what they already had or simply too different for a switch to the
 new GUI to be feasible. It is important to understand that if a standard do
esn't adequately serve its intented user, then those users will simply ignor
e them. Many ISO standards are irrelevant because nobody follow them. The C+
+ standard is not one of those - it is doing immeasuable good by pulling the
 implementations closer together - and we don't want the ISO C++ standard to
 be an ignored standard in the future.
　
注意STL成功的一个主要原因在于它是一个技术突破。它可不单是“又一个容器库”，因
此它不需要和许多现有的容器库（其中几个品质卓著）直接竞争。我猜想C++要有一个标
准GUI，我们需要技术突破，加上好运多多。
Note that one major reason that the STL succeeded was that it was a technica
l breakthrough. It wasn't simply "yet another container library", so it didn
't have to compete directly against the many existing container libraries (s
everal of which were of excellent quality). My guess is that for C++ to get 
a standard GUI, we need a technical breakthrough plus a lot of luck.
　
不过我还是怀疑委员会有由必需的专业技术和资源来构建一个可以成为真实世界中真正
标准的GUI.
However, I still doubt that the committee has the technical expertise and th
e resources necessary to produce a GUI that could become a real standard in 
the real world.
　
我对标准库的想法倾向于修补现有库的遗漏（如hash_map和正则表达式），以及通过更
广泛的运行时间类型信息和并发库来支持分布运算（可选）。
My thoughts for the standard library goes more towards filling in gaps in th
e current library (e.g. hash_map and regular expressions) and support for di
stributed computing through more extensive (optional) run-time type informat
ion and concurrency libraries.
　
有时大家忘了，库不是非得成为标准的一部分才有用。有成千上万有用的C++库。例如，
参C++库FAQ（我的C++网页有链接）
People sometime forget that a library doesn't have to be part of the standar
d to be useful. There are thousands of useful C++ libraries. For example, se
e the C++ libraries FAQ (link on my C++ page).
　
泛型编程是C++特殊的编程思维模型。你是怎样看GP（泛型编程）和OO（面向对象）的？
将来C++会提供更强大的机制来支持GP吗？有没有考虑引入其他思维模型，比如面向模式
？
Generic programming is a special paradigm in C++. What do you thinking of GP
 and OO? Will C++ provide more powerful mechanisms to support GP in the futu
re? And have you considering importing other paradigms, pattern-oriented for
 example?
　
我认为，在C++中面向对象和泛型编程相互补充得极好，我所写的许多最优美的代码都依
赖于两者的结合。也就是说，认为OOP和GP水火不容的观点，是错误的。它们是应该组合
使用的技巧，语言应该支持这样的组合──C++正是如此。
I think that object-oriented and generic programming complements each other 
nicely in C++, and many of my most elegant pieces of code relies on combinat
ions of the two. That is, it is wrong to think of OOP and GP as completely d
istinct paradigms. They are techniques that should be used in combination, a
nd a language should support such combinations - as C++ does.
　
我觉得C++相当好地支持了泛型编程，所以只需要细微的增加。模板化的typedef是个显
而易见的例子。我们要谨慎地扩展语言，仅当扩展对要表述的内容提供重大的便利时，
我们才这样做。比如我不支持对模板参数约束检查提供直接语言支持的想法。通过约束
／概念检查模板，我们已经可以比用为C++和相似的语言提议的各种各样的语言扩展做得
更多。
I think that C++ supports generic programming rather well, so that it needs 
only minor additions. An obvious example is templated typedefs. We have to b
e careful to extend the language only where extensions provide major advanta
ges in what can be expressed. For example, I don't support ideas of direct l
anguage support for template argument constraints checking. We can already d
o more with constraints/concept checking templates than could be done with t
he various language extensions proposed for C++ and similar languages.
　
谈起“思维模型”和“新的思维模型”让我很为难，只有很少的想法佩得上这样美妙的
字眼。我也担心对新观念过于直接的支持，可能会限制和跟不上我们的观念和技术的进
一步演化。理想的情况是，语言设施应有效地支持非常通用的观念，这样大家可以使用
这些设施用各种风格来编写代码。至于C++能优雅地支持哪些模式概念，能和不能通过与
已有风格的组合，还有待观察。我认为，只需要很少新的特定语言概念来支持模式。
I'm very reluctant to talk about "paradigms" and "new paradigms" - very few 
ideas deserve such fancy terms. I also worry that too direct support of new 
ideas can be limiting and failing to cater for further evolution of our idea
s and our techniques. Ideally, language facilities should support very gener
al ideas efficiently so that people can use those facilities to write code i
n a variety of styles. I think that it remains to be seen what patterns idea
s can and cannot be supported elegantly through a combination of styles alre
ady supported in C++. I suspect that very few new language concepts are need
ed specifically to support patterns.
　
今后C++会支持分布开发吗？对RTTI和多线程的进一步支持呢？
Will C++ support the disturbed development later? And what about further sup
port for RTTI and multi-thread?
　
对。如果事情进展能如我所愿，C++标准的下一次修订会通过提供扩展的类型信息和并发
支持库来支持分布计算。我觉得这不需要特别的语言扩展。不过在存在并发的情况下现
有语言设施实作需要做出额外的保证。
Yes. If things progress as I hope they will, the next revision of the C++ st
andard will support distributed computing through the provision of extended 
type information and concurrency-support libraries. I do not think this will
 require specific language extensions. Making additional guarantees about th
e implementation of existing language facilities in the presence of concurre
ncy will be needed, though.
　
我没有太多可说，因为围绕下一标准应该和不该包含哪些的讨论才刚刚开始。我的看法
是C++需要一个无缝地支持线程（在同一地址空间内）、进程（在不同地址空间）及远端
进程（可能有重大的通讯延时而且网络可能暂时分离）的标准库。支持这点会需要超越
简单的Unix或Windows线程的设施。但是我并不认为这需要设计新的语言元件。
There is not much that I can add to that now, because the discussions about 
what should and should not be in the next standard have just started. My vie
w is that C++ need a standard library that seemlessly support threads (withi
n a single address space), processes (with separate address spaces), and rem
ote processes (where communication delays can be significant and where a net
work may become separated for a while). Supporting this will require facilit
ies beyond simple Unix or Windows threads. However, I don't think it need in
volve new language primitives.
　
最近一个叫做YASLI的项目启动了。YASLI代表“又一个标准库实作”，其目的是成为新
一代的C++标准库实作。您对此有何感想？【注：这个项目最初的想法来自于今年5月份
Andrei Alexandrescu在news://comp.lang.c++.moderated上的讨论，详细信息可以在h
ttp://www.stlport.org上查找，也可参考http://www.stlport.com/cgi-bin/forum/dc
board.cgi?az=list&forum=DCForumID10&conf=DCConfID2。】
Recently a new project called YASLI which stands for "Yet Another Standard L
ibrary Implementation" has been started, that intents to be the new generati
on of C++ Standard Library implementation. What do you think about it?
　
知之甚少，无从说起。
I don't know enough about that project to have an opinion.
　
据说大人物年轻时就会表现出与常人的差异，请问您在大学就读时表现过什么与众不同
的地方？
It's believed that great men would show their differences against others whe
n they are young. So what differences did you show when studying in the univ
ersities?
　
我不清楚是否有人认为我显著得与众不同。我猜想，我可能比多数人天真和理想主义那
么一点点。另外比之多数人，我花在解决现实问题的时间会多一点吧──我要挣钱以免
陷入债务。我可不能债台高筑，因为我家不算富有，我一直被要求努力工作。另一方面
，我倾向于学习我感兴趣的多种东西（包括哲学和历史），而不仅只是那些直接有助于
我取得学位和提高成绩的东西。
I am not sure anyone considered me as significantly different from others. I 
suspect that I was a bit more naive and idealistic than most. I also spent m
ore time working of practical problems than most - to earn money to avoid ge
tting into debt. Not building up debt was important for me because I don't c
ome from a rich family. I have been told that I worked hard. On the other ha
nd, I tended to work on a variety of things that interested me (including ph
ilosophy and history) rather than just on things that directly helped me fin
ish my degree or improve my grades.
　
喜欢安徒生童话吗？在《夜莺》里他写到了中国。您对中国、中华文化和中国人的印象
如何？以前去过中国吗？2008年来中国看奥运会可能是个不错的主意。
Do you like reading Andersen's fairy stories? He wrote something about China
 in the story of The Nightingale. So what's your impression about China, the
 Chinese culture and the Chinese people? Have you ever been to China before?
 Maybe visiting China for the Olympics in 2008 would be a good idea.
　
作为丹麦人，我自然知道安徒生童话。我刚好也很喜欢它们。《夜莺》中描绘的中国纯
是虚构，与当时的中国可能有也可能没有任何关系。安徒生创造了那个“中国”来泛指
多个国家及其统治者。
As a Dane, I naturally know Hans Christian Andersen's tales. I also happen t
o like them. The China described in "The Nightingale" is a fiction that may 
or may not have anything to do with the China that then existed. Andersen cr
eated that "China" to be able to make universal points about countries and t
heir rulers.
　
很难对象中国这么巨大的概念有一个印象。我遇到的中国人大都是程序员或工程师，因
此我对中国人民的视野可能过于狭窄，有误导之嫌。哪怕是象我的本国丹麦这样的小国
和文化体，其复杂程度也不是某个人可以完全理解的──只有500万丹麦人。我对历史很
感兴趣，因此也看了几本中国历史和文化题材的书。不过这可能意味着我头脑里的中国
古多于今。我在台湾讲过一个星期的学，喜欢呆在那里，不过还没有机会访问大陆。
It is hard to have *one* impression about something as huge as China. The Ch
inese that I have met are mostly programmers or engineers, so I probably hav
e a misleadingly narrow view of Chinese people. Even a small country and cul
ture as my native Denmark is too complex for any individual to fully compreh
end - and there are only 5 million Danes. I have a strong interest in histor
y, so I have read several books on Chinese history and culture. However, tha
t implies that ancient China may loom larger in my mind than it should compa
red to modern China. I lectured in Taiwan for a week and enjoyed my stay the
re, but I have not yet had the opportunity to visit the mainland.
　
关于中国历史和文化的书我看过不少。因为中国历史悠久、幅员辽阔，主要的焦点集中
于早期的事件、人和传统，几乎没有描绘近10或20年的中国。从新闻和中国朋友那里获
知发生了巨大的变化，我对今日中国的无知是巨大的（尽管可能不象多数人对远方国度
那么无知）。比如我对当今中国的文学和音乐一无所知。因而，想到中国时我想起的很
多东西可能都严重过时──尽管我极其小心地想避免此类错误。顺便说一下，我对主要
从书本上获知的世界其他地区也有类似的问题。【注：Stroustrup博士对中国历史有相
当的了解，在谈论姓“王”的中国人时，我提到世界第二大软件公司CA的总裁王嘉廉（
Charles Wang），他则提及王安石。Stroustrup博士说“对当今中国的文化和音乐一无
所知”，小编就暂时推荐了两首流行音乐。由于Stroustrup博士喜欢安徒生童话，小编
就首先推荐了熊天平的《火柴天堂》，以《卖火柴的小女孩》为背景。另外一首《长城
》，来自取得华语流行音乐最高成就的Beyond乐队（不过随着家驹的离去，这已是永远
的回忆了）。新近的歌嘛，孙燕姿的《风筝》蛮好听的，下次再说吧，呵呵。】
I have read many books about Chinese history and culture. Because of the len
gth of Chinese history and the size of China, most focus on events, people, 
and traditions of earlier times, and hardly any describe China as it has bee
n for the last ten or 20 years. I know from the news and from Chinese friend
s that major changes have happened and that my ignorance of current-day Chin
a is immense (though probably not as immense as most people's ignorance abou
t far-away countries). For example, I have no idea of current Chinese litera
ture or music. Thus, when I think of China, some of what I think may be seri
ously out of date - despite the care I obviously take to avoid such mistakes
. By the way, I have similar problems for other regions of the world that I 
also know of primarily from books.
　
我对大型人群和有组织的群体事件不太热心，因此我会远离2008年奥运会，就象我远离
本可以参加的其它各届奥运会一样。希望能找其他某个时间访问中国。
I'm not keen on huge crowds and organized mass events, so I'll stay far away
 from the 2008 Olympics, just as I stayed away from every other Olympic game
s that I might have attended. I hope to find some other time to visit China.
　
　
编后：Stroustrup博士的经典名著The C++ Programming Language，最新是第3版。同时
，大家还可以看到所谓的“特别版”。特别版与第3版的不同之处在于，封面不同，并且
多了两篇附录：Locales（本地化）和Standard-Library Exception Safety（标准库的
异常安全），可以在Stroustrup博士的主页上下载。第3版的简体中文版由南京东南大学
计算机科学与工程系的徐宝文教授翻译，机械工业出版社出版。据徐教授透露，本书争
取在今年年底或明年年初出版。价钱嘛，呵呵，还得出版社来定。至于特别版比第3版多
出的两篇附录是否加入中文版的问题，仍在与出版社协商中。Stroustrup博士专门为中
文版作了序，限于篇幅，此处仅列出最后一段。
　
I am pleased to write a foreword to Professor Xu's Chinese translation of 'T
he C++ Programming Language'. I am aware that my books have been available t
o Chinese computer professionals for many years, but for most students it is
 a great help to be able to have a textbook available in their native langua
ge. I am therefore very happy that this authorized translation makes C++ muc
h more accessible to Chinese students, programmers, and other computer profe
ssionals.


--
Everybody believes that children are true,
women are beautiful and
men are strong.

※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: 202.118.236.207]