编者按：在C++ View第1期中我们介绍了这位C++之父，相信大家都很熟悉了。这次，小编对这位大人物进行了专访，非常感谢Stroustrup博士的精彩回答和耐心的解释。感谢cber添补的问题，和对小编中国式英语的纠正。同时还要感谢ALNG精彩的中文翻译，这能方便大家更好地理解Stroustrup博士的深邃思想。关于翻译的一些细节问题，小编与ALNG争吵了整整一天，大体上达成了一致。有些需要说明的地方，都在文中以楷体注明。不过小编还得声明，Stroustrup博士回答的内容均以英文为准。
The English version of this interview can also be found at http://www.research.att.com/~bs/01chinese.html.
C++的ANSI/ISO标准化标志着C++的成熟。能告诉我们在标准化过程中，您感到最难忘、最快乐以及最遗憾的事分别是什么吗？
The ANSI/ISO standardization of C++ indicates that the C++ language has matured. Would you please tell us the most unforgettable, the happiest and the most regrettable things you felt in the course of standardization?
标准化是一个极其有价值的重要活动，它在很大程度上被低估，困难重重。通过标准化，C++变得更好了，还获得了有着惊人表达力的标准库。编译器提供商总是想锁定用户，正式的标准化则是用户拥有的为数不多的防御手段之一。
Standardization is an extremely valuable, most important, largely underestimated, and most frustrating activity. C++ became a better language through standardization 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 the 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 between those events, the vote to accept the STL as part of the standard library standard stands out as a most happy event.
没有任何负面或遗憾的事可以与这些积极的投票相提并论。所谓“遗憾”的事，要么是细微的技术细节，要么是（暂时）分化了委员会而使进一步的进展更加困难的讨论。我本来是反对C风格的cast，也不想引入仅允许整型的静态常量成员在类中初始化的机制。不过这些只是无关大局的细节。【注：cast翻译成什么好呢？其本意是铸造、打型，诸位以为，“映射”、“转换”、“型铸”哪一个翻译更贴切呢？或者有其他更好的翻译？】
There is no negative/regrettable event of a magnitude to match these positive votes. All "regrettable things" are either very minor technical details or discussions that (temporarily) polarized the committee so as to make further 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 diverse technical cultures to agree. Also people representing very different organizations (or just themselves) need to collaborate productively. The C++ committee is not an organization that is happy with a vote being "won" by a 60% to 40% margin. Such a vote would be considered a failure. We aim for consensus, 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 incredibly large community, rather than being just perfect for any one use or any one individual. In the end, we managed to get unanimous votes (43-0 in ANSI and 22-0 in ISO) for the standard. I have been told that this degree of agreement has never before been achieved for a programming language standard.
首先委员会要弄清真正的问题和可行的技术解决方案。我称之为“发现”。接着我们把解决方案提炼成标准文本中精确描述的东西。参加标准过程的个人总是必须学会相互协作以及相信他人的善意和专业才能。我称之为“建立信任” ──这非常可能是标准进程中最重要的一部分，没有互信我们将一事无成。
First the committee has to figure out what the real problems are and what kind of technical solution is feasible. This, I referred to as "discovery". Next we have to refine that solution into something precisely described in standards 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 professional 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 overloading 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 before templates became part of C++. He was - in my opinion - at the time overly 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 dislike 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 efficiency. In particularly, I was - and am - very suspicious of attempts to limit 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 led to the STL, and to the current emphasis on generic and generative programming. Alex is always fun to argue with! For an impression of his style, see http://www.stlport.org/resources/StepanovUSA.html.
我试验过在不使用语言扩展的情况下约束模板参数的多种方式。我早期的想法在The Design 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 language 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 than 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#constraints).
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 Standard 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 original streams library was a very simple and very efficient library. I designed 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 decisions after discussions with my colleague Doug McIlroy at AT&T Bell Labs. I chose << and >> after experiments showed alternatives, such as < and >, comma, and = not to work well. The type safety allowed compile-time resolution of some things that C-style libraries resolve at run-time, thus giving excellent 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 aggressive optimization techniques will allow us to regain the efficiency of the original in the many common cases where the full generality of iostreams is not used. Note that much of the complexity in iostreams exist to serve needs that my original iostreams didn't address. For example, standard iostreams with locales can handle Chinese characters and strings in ways that are beyond the scope of my original streams.
有人说Java是纯粹面向对象的，而C#更胜一筹。而还有很多人说它们纯粹是面向金钱的。以您之见呢？
It's said that Java is purely object-oriented, while C# is even more. And many 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 "buzzword-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 of C++ is exactly that it supports several effective styles of programming (several paradigms, if you must), and combinations of these styles. Often, the most elegant, most efficient, and the most maintainable solution involves more than one style (paradigm). If you must use fancy words, C++ is a multi-paradigm programming language. Given the wide variety of demands in the huge area of software development, there is a need for at least one general-purpose language supporting a range of programming and design styles, and probably 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 application 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 with other languages.
不被语言所有者操纵的开放进程所产生的正式标准是无可替代的。如果用户不想看到这种语言因为其所有者或者所谓“一般用户”的利益，不顾经济上无足轻重的“少数派”的反对而改来改去，像ISO这样正式的标准进程，则是唯一的希望。
There is no substitute for formal standards, generated by an open process that 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 objections 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 still supporting users with "unusual" demands. I am personally very concerned to support people building systems with demands for reliability, run-time performance, and maintainability that are far greater than the industry average. My conjecture is that over the span of a decade most programmers will face "unusual" technical requirements that will benefit from C++'s multi-paradigm 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 mechanisms 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 also cause problems. Automatic garbage collection is a valid implementation technique for C++. Good garbage collectors exist for C++ (both commercially supported 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 unsuitable, such as hard real time applications, aren't burdened by it. See my comments about GC in "The C++ Programming Language (3rd Edition)" and on my home pages.
我期望下一个C++标准中能大体上对我上面和其他地方说的内容做出明确的声明。
I expect that the next C++ standard will explicitly state roughly what I just 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 techniques for handling resources in general, and not just memory. In particular, the "resource acquisition is initialization" technique (see D&E, TC++PL3, and my technical FAQ) supports simple, exception-safe management of arbitrary resources. 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 maintaining their proprietary GUIs. Also, users cannot easily change from what they 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 committee decided on an alternative. Their owners and their users would - often for good reasons - simply ignore a new standard. Worse: some company or group of people might actively oppose such a standard because they considered it inferior 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 doesn't adequately serve its intented user, then those users will simply ignore 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 technical breakthrough. It wasn't simply "yet another container library", so it didn't have to compete directly against the many existing container libraries (several 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 the 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 the current library (e.g. hash_map and regular expressions) and support for distributed computing through more extensive (optional) run-time type information and concurrency libraries.
有时大家忘了，库不是非得成为标准的一部分才有用。有成千上万有用的C++库。例如，参C++库FAQ（我的C++网页有链接）
People sometime forget that a library doesn't have to be part of the standard to be useful. There are thousands of useful C++ libraries. For example, see 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 future? 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 combinations of the two. That is, it is wrong to think of OOP and GP as completely distinct paradigms. They are techniques that should be used in combination, and 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 be careful to extend the language only where extensions provide major advantages in what can be expressed. For example, I don't support ideas of direct language support for template argument constraints checking. We can already do more with constraints/concept checking templates than could be done with the 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 ideas and our techniques. Ideally, language facilities should support very general ideas efficiently so that people can use those facilities to write code in a variety of styles. I think that it remains to be seen what patterns ideas can and cannot be supported elegantly through a combination of styles already supported in C++. I suspect that very few new language concepts are needed specifically to support patterns.
今后C++会支持分布开发吗？对RTTI和多线程的进一步支持呢？
Will C++ support the disturbed development later? And what about further support for RTTI and multi-thread?
对。如果事情进展能如我所愿，C++标准的下一次修订会通过提供扩展的类型信息和并发支持库来支持分布计算。我觉得这不需要特别的语言扩展。不过在存在并发的情况下现有语言设施实作需要做出额外的保证。
Yes. If things progress as I hope they will, the next revision of the C++ standard 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 the implementation of existing language facilities in the presence of concurrency 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 view is that C++ need a standard library that seemlessly support threads (within a single address space), processes (with separate address spaces), and remote processes (where communication delays can be significant and where a network may become separated for a while). Supporting this will require facilities beyond simple Unix or Windows threads. However, I don't think it need involve new language primitives.
最近一个叫做YASLI的项目启动了。YASLI代表“又一个标准库实作”，其目的是成为新一代的C++标准库实作。您对此有何感想？【注：这个项目最初的想法来自于今年5月份Andrei Alexandrescu在news://comp.lang.c++.moderated上的讨论，详细信息可以在http://www.stlport.org上查找，也可参考http://www.stlport.com/cgi-bin/forum/dcboard.cgi?az=list&forum=DCForumID10&conf=DCConfID2。】
Recently a new project called YASLI which stands for "Yet Another Standard Library Implementation" has been started, that intents to be the new generation 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 when they are young. So what differences did you show when studying in the universities?
我不清楚是否有人认为我显著得与众不同。我猜想，我可能比多数人天真和理想主义那么一点点。另外比之多数人，我花在解决现实问题的时间会多一点吧──我要挣钱以免陷入债务。我可不能债台高筑，因为我家不算富有，我一直被要求努力工作。另一方面，我倾向于学习我感兴趣的多种东西（包括哲学和历史），而不仅只是那些直接有助于我取得学位和提高成绩的东西。
I'm 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 more time working of practical problems than most - to earn money to avoid getting into debt. Not building up debt was important for me because I don't come from a rich family. I have been told that I worked hard. On the other hand, I tended to work on a variety of things that interested me (including philosophy and history) rather than just on things that directly helped me finish 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 to 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 created that "China" to be able to make universal points about countries and their rulers.
很难对象中国这么巨大的概念有一个印象。我遇到的中国人大都是程序员或工程师，因此我对中国人民的视野可能过于狭窄，有误导之嫌。哪怕是象我的本国丹麦这样的小国和文化体，其复杂程度也不是某个人可以完全理解的──只有500万丹麦人。我对历史很感兴趣，因此也看了几本中国历史和文化题材的书。不过这可能意味着我头脑里的中国古多于今。我在台湾讲过一个星期的学，喜欢呆在那里，不过还没有机会访问大陆。
It is hard to have *one* impression about something as huge as China. The Chinese that I have met are mostly programmers or engineers, so I probably have a misleadingly narrow view of Chinese people. Even a small country and culture as my native Denmark is too complex for any individual to fully comprehend - and there are only 5 million Danes. I have a strong interest in history, so I have read several books on Chinese history and culture. However, that implies that ancient China may loom larger in my mind than it should compared to modern China. I lectured in Taiwan for a week and enjoyed my stay there, 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 length 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 been for the last ten or 20 years. I know from the news and from Chinese friends that major changes have happened and that my ignorance of current-day China is immense (though probably not as immense as most people's ignorance about far-away countries). For example, I have no idea of current Chinese literature or music. Thus, when I think of China, some of what I think may be seriously 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 games 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 'The C++ Programming Language'. I am aware that my books have been available to 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 language. I am therefore very happy that this authorized translation makes C++ much more accessible to Chinese students, programmers, and other computer professionals.
|
专访Bjarne Stroustrup