Bjarne Stroustrup's homepage(页 1) - 培训认证行业入门 - LoveUnix 最强AIX小机技术论坛,UNIX,Linux,存储,数据库,中间件,开发,管理

LoveUnix » 培训认证行业入门 » Bjarne Stroustrup's homepage

2004-6-20 22:31 sky-walker

<a href='http://www.research.att.com/~bs/homepage.html' target='_blank'>http://www.research.att.com/~bs/homepage.html</a> <a href='http://akpublic.research.att.com/~bs/homepage.html' target='_blank'>http://akpublic.research.att.com/~bs/homepage.html</a> <html> <base href="http://www.research.att.com/~bs/homepage.html"> <head> <meta name="DESCRIPTION" content="This is the homepage of Bjarne Stroustrup, the designer and original implementor of C++"> <meta name="KEYWORDS" content="The C++ Programming Language,Bjarne Stroustrup,C++,homepage,books, papers,biography"> <title>Bjarne Stroustrup's Homepage</title> <style> div.day { padding:0.5em; border-style:solid; border-width:2px; background-color:rgb(252,221,163); width:250px; float:right } </style> </head> <body bgcolor="FFFBFB"> <center> <a href="homepage.html">homepage</a> | <a href="C++.html">C++ links</a> | <a href="bs_faq.html">FAQ</a> | <a href="bs_faq2.html">technical FAQ</a> | <a href="glossary.html">glossary</a> | <a href="compilers.html">compilers</a> | <a href="papers.html">publications</a> | <a href="3rd.html">TC++PL</a> | <a href="dne.html">D&E</a> | <a href="bio.html">bio</a> | <a href="interviews.html">interviews</a> | <a href="applications.html">applications</a> | <a href="talks.html">talks</a> | <a href="http://www.cs.tamu.edu">TAMU CS</a> | <a href="http://www.research.att.com">AT&T Research</a> </center> <center> <h1>Welcome to Bjarne Stroustrup's homepage!</h1> <img src="Bjarne.jpg""> </center> <div class=day> <h3>Advice of the day (from <a href="3rd.html">TC++PL</a>)</h3> E.7[1] Be clear about what degree of exception safety you want; secE.2. <h3>FAQ of the day</h3> <a href="http://www.research.att.com/~bs/bs_faq.html#called-C++">Why is the language called C++?</a> <h3>Article of the day</h3> <a href="oopsla.pdf">Why C++ isn't just an Object-Oriented Programming Language</a>. Addendum to OOPSLA'95 Proceedings. OOPS Messenger. October 1995. </div> I'm the College of Engineering Professor in Computer Science at <a href="http://www.cs.tamu.edu">Texas A&M University</a>. I also retain a link to <a href="http://www.research.att.com">AT&T Labs - Research</a> as a member of the <a href="http://akpublic.research.att.com:9000/info/Lab/33">Information and Systems Software Research Lab</a>. I designed and implemented <a href="C++.html"> the C++ programming language</a>. Over the years, I have written a few <a href="books.html"> books</a> (including <a href="3rd.html"> The C++ Programming Language</a> and <a href="dne.html"> The Design and Evolution of C++</a>.), written a lot of <a href="papers.html">papers</a>, and given some <a href="interviews.html">interviews</a>. Here is some <a href="bio.html">biographical material</a>, some <a href="bs_faq.html">frequently asked questions</a>, some <a href="bs_faq2.html">frequently asked questions about C++ style and technique</a> and a <a href="glossary.html">C++ glossary</a>. These pages are permanently under construction. Constructive comments are most welcome. I can be reached by email at bs at cs.tamu.edu or bs at research.att.com, and by paper mail at Department of Computer Science, TAMU 3112, College Station, TX 77843-3112 or AT&T Research, 180 Park Ave., Florham Park, NJ 07932-0971, USA. <center> <a href="homepage.html">homepage</a> | <a href="C++.html">C++ links</a> | <a href="bs_faq.html">FAQ</a> | <a href="bs_faq2.html">technical FAQ</a> | <a href="glossary.html">glossary</a> | <a href="compilers.html">compilers</a> | <a href="papers.html">publications</a> | <a href="3rd.html">TC++PL</a> | <a href="dne.html">D&E</a> | <a href="bio.html">bio</a> | <a href="interviews.html">interviews</a> | <a href="applications.html">applications</a> | <a href="talks.html">talks</a> | <a href="http://www.cs.tamu.edu">TAMU CS</a> | <a href="http://www.research.att.com">AT&T Research</a> </center> </body> </html>

2004-6-22 15:11 sky-walker

者按：在C++ View第1期中我们介绍了这位C++之父，相信大家都很熟悉了。这次，小编对这位大人物进行了专访，非常感谢Stroustrup博士的精彩回答和耐心的解释。感谢cber添补的问题，和对小编中国式英语的纠正。同时还要感谢ALNG精彩的中文翻译，这能方便大家更好地理解Stroustrup博士的深邃思想。关于翻译的一些细节问题，小编与ALNG争吵了整整一天，大体上达成了一致。有些需要说明的地方，都在文中以楷体注明。不过小编还得声明，Stroustrup博士回答的内容均以英文为准。 　 The English version of this interview can also be found at <a href='http://www.research.att.com/~bs/01chinese.html' target='_blank'>http://www.research.att.com/~bs/01chinese.html</a>. 　 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的访谈录，内容相当激进，心脏不好的人请做好一切必要准备<img src='style_emoticons/default/happy.gif' border='0' style='vertical-align:middle' alt='happy.gif' />。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 <a href='http://www.stlport.org/resources/StepanovUSA.html' target='_blank'>http://www.stlport.org/resources/StepanovUSA.html</a>. 　 我试验过在不使用语言扩展的情况下约束模板参数的多种方式。我早期的想法在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.

2004-6-22 15:12 sky-walker

Slashdot对Bjarne Stroustrup的采访 hoping（收藏） 出處﹕ <a href='http://www.csdn.net/develop/article/18/18659.shtm' target='_blank'>http://www.csdn.net/develop/article/18/18659.shtm</a> 关键字 Bjarne Stroustrup OO C++ C 注：前段时间Myan在CSDN上贴了一个对各大语言，以及OO和模块化的评价的文章。下面这篇对C++之父的采访中，Bjarne Stroustrup谈到了自己的看法。通过大师们思维的碰撞，我们能从中学到什么呢？ Slashdot对Bjarne Stroustrup的采访 荣耀马皓明译 1．OO的发展已呈颓势了吗？（由Rambone提问） 20多年过去了，显而易见，面向对象编程并非包治百病的“万能药”，请问您对OO范型（OO paradigm）的未来有什么看法？您认为有什么别的范型对它形成了挑战？ Bjarne：哦，20多年以前我就明白OOP的确不是“万能药”，这也正是C++支持好几种设计和编程风格的原因。 假如你喜欢罗里罗嗦的词语，你可以说C++是一门“multi-paradigm language”，不过，简单地说C++是一门“OOPL”的确是不准确的。为此，我撰写了一篇论文《为什么C++不仅仅是一门面向对象的编程语言》（可以到我的“论文页面”下载）。我在OOPSLA（Object Oriented Programming Systems，Languages， and Applications）会议上展示了它，并且它幸运地得以存留。 在《The C++ Programming Language》第一版中，我并没有使用“面向对象编程”这个术语，因为我不想对那些大肆的宣传推波助澜。OOP的问题之一正在于肆无忌惮的人们宣扬它是一贴“万能药”。什么东西一吹过头了，最终必然会导致对它的失望。 换句话说，虽然OOD和OOP是我钟爱的设计和编程方式，但它们并非对所有程序所有细节来说都是恰当的风格。一些优秀的抽象例子并没有使用类层次结构，同样也被极佳地表达了出来。试图将类层次结构尤其是单根层次结构应用到所有问题之上，很可能会导致的确畸形的程序。 我大量使用了简单的数据抽象（没有继承关系的类）和泛型编程（模板和参数化类型的算法）。然而，我并不将此举视作“泛型挑战OOP”，它们是互补的技术。“寻找适合目标问题的设计方案”以及“在代码中使用最佳语言结构来表达设计方案”，永远才是关键。 组合运用各种风格可以写出非常优雅的代码。例如： void draw_all(list< Shape*>& lst) { for_each(lst.begin(),lst.end(),mem_fun(&Shape::draw)); } 在这段代码里，list和for_each()是C++标准库中泛型设施的例子，它们被用来调用一个传统类层次结构中的一个基类的一个虚函数。 你甚至可以编写一个适用于“任何具有Shape*元素”的标准容器的draw_all()版本： template< class Container> void draw_all(Container& c) { for_each(c.begin(),c.end(),mem_fun(&Shape::draw)); } 我选择这个例子来唤醒那些依旧“生活在黑暗时代”并且认为C++不过是对C做了一些无趣的扩充的人们。 当然，这个版本的draw_all()所产生的代码与列表遍历代码（list traversal code）具有同等的效率，用于调用Shape::draw()的多态机制可以归结为“通过一个函数指针数组来调用每一个函数”，此一机制已经应用于设备驱动程序的调用之中。 每一年都会有新“范型”被吹捧出来，但它们多数都不具有基础性的意义，而且大都缺乏新意。最有意思的可能是那些基于“组件”的模型，例如COM和CORBA。但我不能确定这些东西能否构成一种“新范型”，抑或它们不过是一套新的系统级的“构建模块”而已 — 我们难道说Unix进程（processes）是一种新范型吗？总之，我对此类组件的基本观点是：它们仍然不能和编程语言（如C++）以及形形色色的“传统”的编程范型（如OOP和泛型编程）完美地集成。 2．使用C++进行系统编程（systems programming）（由ajs提问） 长期以来，C一直是UNIX世界系统编程语言，而且仍将如此。我知道您不愿意对语言进行比较，所以我只问问您，是否有什么本质的原因，使得C++无法成为一门优秀的系统编程语言，或者说，不能引起C系统程序员的兴趣？ Bjarne：让“老家伙”学习新技术是件难事儿。 Unix是25年前编写的（我第一次用它是在1973年）。它所有的接口都定义为C函数调用、数组以及结构（structs）。到C++可用的时候，C语言几乎唯我独尊的传统已经持续了10多年了。 Unix程序员没有什么合理的借口避免使用C++，相反，倒是有一些很好的理由去使用它。然而，有数不清的“不使用C++”的借口被提了出来，让我来列出几条： C++速度慢 C++产生“臃肿的”代码 缺乏优秀的C++编译器 C++太复杂 C++没有为系统程序员提供很多便利条件 C++的高级特性不适于系统编程 C++代码不可移植 C++没有ABI（application binary interfaces，应用二进制接口） 这些借口要么荒谬至极，要么很大程度上无关紧要。其中一些原因对于某些系统（比如缺少合适的C++工具的微型嵌入式系统）来说有一点道理，但对于Unix/Linux绝非如此，我将简要地解释一下原因。当然了，完整的讨论需要几百页纸头，因为单单举反例是不可能的，换句话说，想证明“对某人来讲没有什么问题不可以解决”是不可能的。 对于同样的程序，C++可以产生与C同样优秀的代码，尽管去试吧！ C++就是被设计用来做那些事情的，当前交付的编译器都遵守这个承诺。 当然了，使用任何语言你都能写出糟糕的程序。C++虽然是一个强大的工具，但对它的误用也会产生明显畸形而臃肿的代码。这可以和那些拙劣的程序员使用C语言编写的“传统的意大利面条”相“媲美”。要注意，一名优秀的C程序员并不会自动成为一名优秀的C++程序员。许多问题都是这么冒出来的：某些优秀的C程序员总是想当然地以为自己随便学点C++语言特性，一周之内摇身一变就成了C++高手。 在一周之内C程序员的确可以从C++中获益，但这仅局限于C++功能的一个子集和库。 C++支持许多威力强大的技术，而这些技术在C中顶多只有微弱的支持，它们学起来是需要时间的。C程序员或许还清楚地记得成为“大师级”C程序员花了他们多少时间。为什么成为一名“大师级”的C++程序员花费的时间就要短一些？我想不出任何理由。 当前一代的C++编译器在符合标准方面远胜于几年前的编译器，但优化器（optimizers）却与C共享。这可能会导致问题，因为它排除了某些不适合C语言的有意义的优化，不过，至少与C共享编译器的大部分，却也能使那些怀疑C++是否可以产生与C等价的代码的人们打消疑虑。 我将在对问题9的回答中探讨语言复杂性的根源。在此，我想指出的是，C++的许多功能可以直接帮助人们编写出高效、可靠且可维护的代码，假如你不去用这些功能，你很可能最终需要利用低阶语言结构模拟实现它们。 甚至那些“新的”或者“高级的”C++特性，例如模板、异常以及运行时类型信息（RTTI），也遵从“零开销”设计原则。假如你需要这些特性，在一个现代的编译器中使用它们比使用C语言来仿造这些功能更加高效（在运行时间和内存空间两方面皆然）。我还没有听说任何C++语言功能在某些系统或嵌入式应用中“没有用”或“负担不起”。 当然了，如果你不需要某种特性（RTTI往往用不着），或某种特性在特定情境下不适用（我可以想出一些不适用异常（exceptions）的程序），你不用它们就是了。“零开销”原则允许你做出这样的决策。这和“在一个给定的应用中不使用某种不适当的C语言特性（例如在一些嵌入式系统中禁止使用malloc()）”没什么两样。 C++具有和C一样的移植性。两种情况下，你都需要对“系统依赖性”进行封装以便移植。大型程序可以在Unix平台之间而移植，某些程序还可以跨越其他平台进行移植。这些技术广为人知，而且当它们应用情况良好时，C++在“将无痛移植的系统概念进行正式化”的方面，甚至具有一个优势。要想看一个例子，你可以参考“定义ACE平台”的C++库（我的C++网页上有链接）。 C++缺乏二进制接口（ABI），最难解决的技术问题可能非此莫属了。C也没有ABI，但在绝大多数（或者全部？）Unix平台上，都有一个“占支配地位”的编译器，其他编译器要想“有用”，都必须遵守它的调用约定和结构布局规则。在C++中，则有更多的“变数”，例如虚函数表（virtual function table）的布局，因此没有任何厂商被批准为C++创建“所有竞争厂商都必须遵守”的ABI。同样道理，以前连接（link）由两台不同PC上的C编译器所产生的代码也是不可能的，所以通常也不可能连接两个不同Unix C++编译器产生的代码 — 除非有兼容性开关。 目前的解决方案通常是将“使用单一的编译器”与“提供C级别的接口”二者结合使用，这并不理想，请参考我对问题10的回答。 也就是说，我认为最主要的问题在于“教育”。对于“C++是什么”以及“它能用来做什么”，很多人的看法严重错误。错误的看法往往累积成学习的严重障碍。现在的C++与1985年的第一版相比已经大相径庭，C++的ISO标准于1998年被批准。对我来说，目前的编译器已足够接近标准。我可以将那些利用较新功能的程序，在编译器之间进行移植，以便在多种平台上进行性能测试，这其中标准库功不可没。 3．您会有什么不同的设计？（由spiralx提问） 假如时光可以倒流到您设计C++之初，您会做出哪些改变？为什么？ Bjarne：我们永远不能回到从前。不过，我想我最明显的失误有：没有在引入多重继承（multiple inheritance）之前引入模板；没能在C++编译器第一版中搭配一个规模较大的库。这两个失误在一定程度上是相关的。 我没能交付一个库的原因在于我不知道如何编写一个足够好的库。要想使容器高效而且类型安全，我们需要用到模板，而直到1988或1989年我才得到一个支持模板的编译器。但只有模板还是不够的，我们还需要一个针对容器和容器用法的“可以带来安全性”的设计。直到Alex Stepanov带来了STL，我们才有了这样的一个架构。如果你想领教这些有趣的思想和睿智的观点的“激情展现”，可以阅读这篇对Alex的采访。STL是C++标准库的核心，它提供了标准容器和算法，还提供了它们的用法以及“以用户自定义容器和算法进行扩充”的框架。自然而然，《The C++ Programming Language》对此进行了详尽地讨论。 先于模板引入MI所导致的一个后果是怂恿了对类层次结构的进一步滥用。对于某些使用继承机制的较为畸形的应用来说，模板提供了一个简单而高效的替代方案。 让我说说即使时光倒流我也不会修改的东西 — 兼容性。即便C语言不是最佳兼容人选，我也会选择与某种其他语言兼容。“创新”应该重点着眼于“改进”，那些行得通的东西应该尽可能保持不变。这样的话，人们便可以继续使用现有的工具和技术，也可以在功能业已完备的基础上进行开发，还可以避免“重新发明轮子”，也不用重复教授那些与老内容雷同的“新”内容。因此，C++尽可能地接近于C — 但不能更接近了。 这个问题的另一面是：你必须处理那些老错误以及兼容性的问题。例如，我认为C的声明语法就是一种失败，不过，在C++中我还是采纳了它。当是时，我考虑的变通方案以及改进方法并不能使情况好转。不过我认为这是一个次要问题，更严重的问题是，随着C的发展演化，C++如何保持与之“接近”。 还有，即便反思过去，我也不会从标准C++中删除任何大的语言特性。添加新的大的语言特性也必须慎重。人们认为需要改变语言才能实现的功能，往往利用库就可以实现。 我认为C++标准委员会做了很了不起的工作。对一项规范达成共识并非易事。商业竞争的公司之间要达成一致意见，还要让标准传统冲突的国家感到满意。然而，我认为所有时间和努力都没有白费。标准C++比以前任何版本都更加接近我的理想，并且它还伴有一个很棒的标准库。这些时间和努力是不可或缺的 — 除非你想被“事实上的标准”和“专有语言”所支配。我的第三版《TC++PL》讲述了ISO标准C++，目前的C++编译器接近这个标准。 4．为什么没有templated typedefs？（由Venomous Louse提问） 哦，真不可思议，这正是今上午我想找来讨论的家伙！ typedef templates（或是template typedefs？天啊！）有时候的确能带来便利，如下所示： template< class T > typedef bool (* func)( const T &r ); ……但这似乎并不合法，我不能回想起曾经在《The Design and Evolution of C++》中看到关于此类问题的任何东西。那该怎么办呢？ Bjarne：我，还有标准委员会，低估了templated typedefs的重要性，我猜想将来会添上它。 实际上，D&E （第357页）已经讨论了templated typedefs，并提出了一项常用的替代技术： 这种扩充在技术上微不足道，但我并不能确定引入另外一种重命名特性有多么明智。 在定义一种新类型时，也可以使用派生机制对模板参数进行部分特化（partial specification）： template< class U, class V> class X { /* ... */ }; template< class U> class XX : public X< U,int> { }; 我猜想，在这种情况下，“我不愿添加无明确实际应用需求的新特性”导致了问题，但我却更常因相反的错误（过于积极地添加特性）而受到指责。可是，在人们学会已有特性的用法之后，基于新经验的新需求又开始涌现。 顺便说一句，你的例子 — 接受参数T并返回一个bool值的函数，往往可以通过一个函数对象（function object）来表现。而函数对象天生就是模板： template< class T > struct Predicate { bool operator()(const T &r) { /* ... */ }; }; 如此一来，你就不需要typedef了，只要这样写就可以了： Predicate< Mytype>* p; 函数对象在内联（inline）方面也要优于函数指针，因此使用它们可以编写干净而快速的代码。 通常来说，我推荐那些有着“在C++中它为什么是或不是这样”的疑问的人们阅读《The Design and Evolution of C++》一书。 5．问题……（由MrHat提问） 我（可能还有我们大多数人）了解您只是通过您对C++语言的创建工作，以及您对编写C++语言ANSI标准的协助工作。 除了这项工程以外（虽然非常巨大），您日常还做了哪些工作？目前您在进行什么项目？您还有更多的正在进行中的语言定义或标准吗？ Bjarne：C++相关工作是我日常工作的一大组成部分。虽然C++标准目前处于“维护模式”，但仍然需要投入一些注意力。我做了一些跟库和编程技术相关的工作（今年晚些时候，我将会在《The C++ Report》上发表一篇关于“包装器（wrappers）”的论文）。C++的教育以及“被误导的程序员往往严重误用C++”也让我担心。请参阅我写的《把标准C++当作一门新语言来学习》一文（可从我的论文页面下载）。如你所见，我还进行一些写作、演讲并接受采访。 在标准委员会里，我将大部分时间花在性能工作组（performance working group）中。成立这个组的目的是为了调查效率低下的根源，并且研究“拯救”劣质代码的实现和编程技术。这项工作的需求场合之一是嵌入式系统。目前的语言使“近于最优化的解决方案”成为可能，但并非所有编译器都能达到那种程度的效率，而且并非每个程序员都通晓编写紧凑而高效的代码的基本技术。 一如既往，在网上仍然有很多关于语言扩充和新库的讨论，但C++社群仍然没有学会如何充分利用新的便利设施。我想我们可以从优秀的库中获得很多好处。标准库和STL分别从一般角度和特殊角度展示了一些可以做的事情。最终，某些新库将被标准化。 我正努力提高对分布式计算的认知水平。为此，我阅读了大量的东西，并试验了一些小玩意儿。我关注的内容包括迁移性、可靠性、容错能力以及安全性。这些研究领域也在“导致我设计C++”的研究领域之列，因此从某种意义上说，我回到了“系统（systems）”老家。作为AT&T实验室的一名管理者也要花费一定的时间，但可能不象你想象的那么多，而且它看起来也不像是真正的工作 — 在那个职位，我既不写代码也不写技术文献。 6．多重继承（由MosesJones提问） 有三个相互关联的问题： 您认为多重继承是一门真正的OO语言所必需的吗？ 在使用多重继承设计系统时，您认为需要避免哪些陷阱（尤其在可维护性方面）？ 您认为有哪些措施，可以简化多重继承的可读性，以减少新手可能做的危险动作？ Bjarne：假如你依赖于静态（编译期）类型检查，你将需要MI。如果没有MI的话，许多程序将被“扭曲”，并且你将不得不过于频繁地使用显式转型操作（explicit type conversion (casting)）。我不会声称自己知道什么是“一门真正的OO语言” （即使果真有这么一门语言），但是，假如你本质上必须始终使用显式类型查询（explicit type inquiry）的话，你使用的就不是一门真正的OO语言。 我并不认为MI是一个特别严重的陷阱来源。MI与单继承以及任何其他强大的语言特性所共有的明显的问题，就是被滥用。我倾向于在简单的聚合（aggregation）中以及实现多个接口时使用MI，例如： class network_file_error : public network_error, public file_error { // ... }; 还有 class interface { // abstract class // pure virtual functions }; class base_implementation { // useful functionality // data, functions, virtual functions }; class my_implementation : public interface, protected base_implementation { // data, functions // override some base_implementation functions // override all interface functions }; 在后一个例子中，你可以让用户仅仅通过指向接口的指针或引用来访问my_implementation。这使得用户代码可以不依赖于“实现类（implementation class）”，而且系统不会遭遇所谓的“脆弱的基类”这个问题。“实现类”可被更换为一个改进版，而无需重新编译用户代码（除了my_implementation自身）。 遵循这两种风格可以避免绝大多数问题。当然，你可以在《The C++ Programming Language》第三版和特别版中找到更加广泛的讨论。（如需了解详细情况、样章或评论等，请访问我的个人主页。） 实际上，关于MI的问题通常意味着提问者已迷失于技术细节之中。对于几乎所有程序来说，使用抽象类、模板、异常以及标准库的所带来益处远远超过其招致的问题。在一门带有继承的静态类型的语言中，MI必不可少，但它并不属于那些应该频繁使用的特性。 定义具体类（concrete classes）以表示简单的类型，定义抽象类（abstract classes）以表示主要的接口，如果你将重点集中于此，可能会产生一个良好的设计。所以说，完成某个程序可能需要也可能不需要用到MI，但当真正需要的时候，它显然是个优美的解决方案。 7．问题（由Edward Kmett提问） “constrained templates”有希望被引入C++吗？对程序员来说，当前使用模板是件磨炼毅力的事。我听说在模板引入之初，“constrained genericity”就在标准委员会出现了，有没有什么重新思考那个决定的想法呢？ 另一个问题在于“从Eiffel社群获得了大量动力”的“Design by Contract”，我很希望看到它逐步被纳入C++标准，但我怀疑能不能心想事成。 最后，Bjarne先生，您说过“当可以在C++中使用引用计数（reference counting）时（而不是“假如可以......”），它将是一种可选的技术”，有一本关于面向对象编程语言的书曾引用了这句话（但此刻我在Amazon上贴出ISBN也没能找到这本书）。在引用计数对象技术的前沿有没有取得重大进展呢？自从您的话被引用后，您的观点是否发生了什么变化？ Bjarne：事实上，我当时说的大意是“当自动垃圾回收机制（auotmatic garbage collection）成为C++的一部分时（而不是“假如自动垃圾回收机制......”），它将是一种可选的技术”。 对于使用频率不太高的资源来说，“引用计数”可能会非常有用，但我并不提倡将它作为一项“跟踪内存”的通用机制。C++拥有良好的内存管理机制（比如构造器、析构器以及标准库容器），但如果你需要更加“自动”的东西，插入（plugging in）一个可用的垃圾回收器（garbage collectors）是个恰当的选择。（可参见《The C++ Programming Language》C.9.1节、我的C++网页或者我的FAQ。） 顺便说几句，精装特别版《TC++PL》的ISBN是0-201-700735，而平装第三版的ISBN是0-201-889544。 对模板进行约束且不使其能力受损，这并不像听起来那么简单。详细讨论请参阅D&E。问题之一在于：如果你根据基类来表达模板参数约束的话，将会使你的系统设计向“每个属性（property）都作为一个基类”的畸形风格发展。这极易导致滥用多重继承和间接表达“本来该直接表达”的东西。例如，说“一个类必须拥有一个<<操作符”比“必须继承自‘Printable’（才能拥有一个<<操作符）”更加清晰。表达更直接的代码，也就更加简短，而且生成的代码比“添加一个基类来表达一种约束”的版本品质更佳。 特化（Specialization）和部分特化（partial specialization）机制为人们提供了许多希望从constraints中获得的表达能力。例如，假如我有一个通用的排序函数模板 template< class Container> void mysort(Container& c); 我还想为vector提供特别的排序算法，那这么写就可以了： template< class T> void mysort(vector< T>& v); 我更欢迎带有类型错误机制的模板（templates with type errors）所提供的错误信息。其中一些可以通过更好的编译器技术而实现（人们正在为此努力），有些信息则需要某种模板参数约束或检查才能做到，但我不知道如何做到这一点。幸运的是，程序员可以帮忙。考虑我在回答问题1时给出的例子： template< class Container> void draw_all(Container& c) { for_each(c.begin(),c.end(),mem_fun(&Shape::draw)); } 如果有一个类型错误，将会在那个相当复杂的for_each()调用决议（resolution）时发生。例如，如果容器内的元素类型为int，那么我们将会得到某种与调用for_each()相关的含糊的错误信息（因为我们不能对int调用Shape::draw()）。 我编写的代码其实如下： template< class Container> void draw_all(Container& c) { Shape* p = c.front(); // accept only Shape*s for_each(c.begin(),c.end(),mem_fun(&Shape::draw)); } 当无用的变量“p”在初始化时，目前绝大多数编译器都将会引发一个容易理解的错误信息。类似这样的技巧在所有的语言中都很常见，并且已经开发用于所有新颖的构造（constructs）。在“产品代码”中，我可能会这样写： template< class Container> void draw_all(Container& c) { typedef typename Container::value_type T; assert_equiv< T,Shape*>(); // accept only Shape*s for_each(c.begin(),c.end(),mem_fun(&Shape::draw)); } 我使用了一个断言以使它更加清晰。我把assert_equiv()的定义作为一个练习留给读者J 这引入了对问题的第二部分 — “design by Contract”的使用。既然“design by Contract”是一种设计风格，那么就你可以在C++中使用它。为此，你需要系统地使用断言。我个人倾向于依靠一些“特化的断言模板（specialized assert templates）”（请参阅《TC++PL》第三版）。我也认为这样的一些模板是“作为库的一部分而标准化”的优秀候选者。 然而，我并不认为语言将会直接支持类似于preconditions和postconditions这样的东西，我也并不认为使用与程序自身本质上相同的语言而编写的preconditions和postconditions是对asserts()的显著改进。还有，我怀疑对类层次结构进行检查（语言支持的conditions已提供）是否值得。通过在目前标准C++中更加系统地使用断言，人们今天可以获得非常显著的好处。 8）一个聪明的问题（哈哈！）（由jd提问） 以软件工程的角度来看，C++是一门基于对象的语言，而不是一门纯粹的面向对象的语言。然而，它仍然以对象概念为中心，而并非以过程（procedures）为中心。 然而，所有现有的处理器都是过程式的（procedural），并不存在真正意义上的OO CPU。 您认为OO语言，例如C++，会在硬件级别上导致OO系统的产生吗？或者总是将OO思想限定在抽象层次上，而通过极其复杂的编译器来实现“OO范型”和“过程化范型”之间的翻译，这样是否简单一些？ Bjarne：在设计C++之前，我的工作内容之一是直接支持“高阶”功能的架构。我得出了一个结论：随着硬件迅速降低价格，速度加快，基于软件的方案要优于高阶硬件。这些优越之处遍及费用、弹性、潜在的用户数量以及“软件可以运行于其上”的计算机的寿命方面（设计并构建一台高阶机器比一个传统机器花费时间要长）。 在可以预见的将来，“通过编译器将高阶结构映射为低阶硬件基元”的方式仍将占据支配地位。 9．C++的复杂性 VS. OOP的简单性（由hanwen提问） 首先对本问题中那些可能的“煽风点火”的内容表示歉意J 您怎么解释目前C++的复杂性与面向对象编程大力鼓吹的简单性之间的关系？以下是对本问题的更详细的说明： 近几年来，C++的实现迅速膨胀，假如我没记错的话，您的著作《TC++PL》内容增加了一倍还多。C++已成为一门规模巨大、极其复杂的语言，我怀疑是否有任何个体（除了您之外）能将所有定义熟稔于心，更不用说团队里的程序员了。 这意味着在任何项目里要想全面使用C++是不现实的，而且肯定会为一个项目制定严格的“指导方针”来限制哪些特性可以使用，哪些不可以使用。从这个角度来看，“C++使得软件开发更易管理”是值得怀疑的。因此我认为，作为一种意图更高效地编写更好的软件的工具，C++是一个失败者。 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，那个丑陋且难以控制的“野兽”，才是计算数学的唯一“避风港”。 Bjarne：请看看关于C++数值计算库的链接（例如Blitz++、POOMA、MTL和ROOT），你可能还会跟踪到另外一些C++数值计算方面的网页。 Davorama的评论 这些问题是如此不寻常，使我无法做出定论，或许你们这些人可以提供一些想法？ 您怎么看待模板元编程（template meta programming）？您是否认为它是一种“恩赐”，使得聪明的程序员可以做出像Blitz项目那样酷毙了的东西？抑或是它所带来的便利完全被其“晦涩乃至近乎看不懂”的实现代码给抵消了？ Bjarne：我确实喜欢一些使用C++进行数值计算方面的东西。常见的思路是模板可被用于消除那些伪临时对象（spurious temporaries）。结果往往是以它们自己的游戏规则击败Fortran，同时还保持了规范的数学记号。在我的个人主页上，你可以看到以下链接：来自LANL的POOMA、来自Warterloo U.的Blitz++、来自Notre dame的MTL。《TC++PL》在数值计算一章有关于这方面基本技术的解释。 我认为实现代码的复杂难懂无关紧要。实际上，我认为那些代码比另外一些代码（比如说C核心代码）要好懂多了。在效率头等重要时，你不该过分抱怨优化技术有多么难懂。毕竟如果你是一个真实用户的话，你没必要阅读它们的实现代码。 sethg的评论 在回答中似乎有一个普遍的主题，即“那些抱怨是基于过时的信息，请使用遵从标准的新编译器和STL。” 有没有人为我们这些C++新手维护一个图表，展示目前哪些可用的C++编译器违反了C++标准文件的哪些小节？ Bjarne：一个大致的回答：目前大厂商提供的编译器都已相当符合标准（我使用它们），例如Borland、GNU、 Metrowerks、 Microsoft以及SGI。 更详细的信息请参考LANL的列表（在我的C++网页上有对POOMA站点的链接），或者参考一个试图跟踪这类信息的新西兰站点。一些厂商，例如Borland，在它们的网站上公布Plum Hall评估的结果。 还有，你说的对，我认为针对C++而报告的问题有很大比例可以归结为“误解”和“误用”。“有一个现代的C++编译器”是试验我建议的一些技术的先决条件，但是请不要以为一个新编译器本身就会带来多大帮助。你需要真正地改变你的工作方式，不幸的是，现实世界中有太多因素使得这种改变难以实现（遗留代码、缺少学习新技术的时间、多人协作以及过时的风格规则等等）。我没说过这很容易，我只说过这有可能，而且很多人已经取得了成功。 hanwen的评论 可能如今标准库可以减轻我的一些苦恼，但我不想再学习这么一个大型C++组件，另外还因为我知道即便如此，C++仍然不够好。它究竟会不会支持反射（reflection）、高序函数（higher order functions）、垃圾回收？。 这么看来，我发现您的“C++的入门要比C的入门容易一些”的说法是危险的，您在《把标准C++当作一门新语言来学习》中所举出的例子也是如此，因为它们暗示这两门语言中的任意一门都能够或者应该成为一门“入门”语言。 一门语言，区别对待堆和栈上的非直接对象（non-immediate objects），没有自动垃圾回收机制，允许使用指针，无初始化机制，没有任何“高序（higher-order）”内容，您确实希望人们随着这样一门语言成长吗？ 您教育人们关于C++的内容：和错误的思想斗争，告诉他们哪里适用C++。但是，您未曾告诉过他们哪里不适用C++。C++广为流行，以至人们容易产生这样的误解：这种流行性说明，C++是一门优秀的编程入门语言，或者，C++是一门适用于编写非常巧妙的程序的语言，等等。 Bjarne：实际上，你说的没错。我认为让人们学习一种“当他们毕业后就再也不可能使用”的语言是不妥当的。Lisp和函数型编程语言（functional language）社群并没有使得自动垃圾回收机制和高序（higher-order）的方方面面都成为主流，尽管它们拥有学院派以及教育机构长达20多年的热情支持。很明显，我认为让人们使用像C这样的低阶语言也非理想选择。 鉴于目前编程及设计教学的糟糕情况，C++可能会取得一个大的进步。当然了，人们也可能无法从C++的抽象机制中获益，而是退化到使用C或C++来编写等价于汇编代码的东西。通过STL，C++社群或许已经使更多的人了解函数型编程（functional programming）技术，或许C++社群已经将此类技术应用于现实问题之上，比以前所有语言所做的总和还要多。函数对象（function objects）不是最具弹性的闭包（closures），但这并不影响这样的事实：人们理解、喜欢并且使用它们。 《把标准C++当作一门新语言来学习》（在我的论文网页上有链接）一文清晰地陈述了这些方式的作用范围并探讨了原因。看看1988年的C++，它没有模板、异常、RTTI和标准库，它的确是一门不同的语言 — 一门不支持绝大多数现代C++技术的语言。 如果你需要垃圾回收机制，有很棒的免费的或者商业支持的C++垃圾回收器可供选用（请参考我的C++网页上的链接）。C++垃圾回收器之所以如此高效，原因之一即是C++区别对待配置于栈上的对象和配置于自由存储区的对象。 姓Coward的匿名人士的评论 啊，正是这个家伙，他一度篡用“C”这个名称来为他的新语言命名，还在AT&T到处说K&R的C语言是“old C”……直到Dennis Ritchie叫他住嘴为止。 我想他不得不承认，委员会帮他摆平了这门语言早期版本中的大量的问题，而且我也认为他不会宣称目前的C++是完美无暇的。 鉴于他的成功和知名度，或许我自己有点狂妄自大了J Bjarne：我并不真的认为自己极其缺乏谦逊。 要知道，我与Dennis（虽然不十分密切）还有Brian Kernighan（密切地）共事过十多年。我不认为我盗用过“C”这个名字，即使果真如此，也没有人会向我索赔J 说C语言是“Old C”的人不是我。为了澄清混淆和避免对Dennis名誉造成伤害，为“C with Classes”取名为 “C++”的正是本人。 同样，我在委员会工作非常努力（很少有语言设计者为如此“乏味的细节”烦心），同时我也认为委员会做了出色的工作。 －完－

2004-6-22 15:13 sky-walker

Rogue Wave对Bjarne Stroustrup的专访 <a href='http://www.royaloo.com/bjarne/interviews/BS_RogueWave.htm' target='_blank'>http://www.royaloo.com/bjarne/interviews/BS_RogueWave.htm</a> 荣耀译 RW： C++在Internet时代还有意义吗？ Bjarne：那是当然。C++代码不适合下载到不安全计算机中，但大多数计算情况并非如此。 对于涉及系统编程和资源受限和/或性能要求严格的许多应用来说，C++是最佳语言选择。Google就是一个例子，支撑小型设备的嵌入系统则是另外一个范例。 此外，还有许多程序并不直接和Internet打交道，对它们而言，世界并无显著变化。 RW：鉴于.NET平台中立的语言已经摆上台面，您认为这对C++将会产生怎样的影响？ Bjarne：对C++社群会有一些影响。一些程序员从事和特定运行环境（例如.NET、某种特定嵌入系统或UNIX变体）密切相关的编程。对于他们来说，和平台平滑地集成，就成了需要考虑的头等大事。 在微软.NET世界里，C++受到了足够重视，它仍将是一门举足轻重的语言，但在很大程度上，重心将不可避免地集中于和平台集成以及同以其它语言编写的代码进行互操作。从更长远的观点来看，人们将会获得某种程度的语言中立，而付出的代价则是严重的平台相依。这将会抑制对C++较新成分的试验，但是，鉴于为数众多的程序员只是不可理喻地使用C++的一个有限子集，所以，从短期来看，.NET可能实际上会成为“更好地使用C++”的一个激励因素。 换句话说，我的内心和那些为平台中立和可移植性而奋斗的程序员紧密相连。对于这些程序员来说，轻巧的接口和平台中立的库至关重要。ISO标准则是纽带，它将各C++社群分支维系在一起，并阻止语言四分五裂为混乱的专有方言。 RW： ISO/ANSI C++标准委员会开始讨论修改和扩充C++语言和库。您最希望看到什么样的扩充，抑或您最反对什么样的扩充？ Bjarne：我的指导思想非常简单：对于语言的扩充，我们应该小心谨慎，深思熟虑，而对于标准库的扩充，我们应该把握时机，积极进取。我的理由几乎同样简单：我们希望提高可移植性和稳定性，而修改语言是做不到这一点的。库就不一样了，假如我们拿到手的是一个烂库，我们可以把它扔在一边，而采用一个更好的替代品，也可以自己创建或购买一个“比从编译器厂商那儿得到的”更好的库。 如今，人们对程序语言期望过高，形形色色的专有语言就泄露了这一点。通过不断扩大标准库的规模，这些期望可以轻而易举地得到满足 — 特别是，假如我们可以“象对iostreams和STL所做的那样”将大量的库组织为一个可扩展的框架的话。 就象扩充标准库核心一样，对语言进行成功的扩充也需要一个正确的方向。在语言领域，我希望集中于小型设施，这些小型设施能使语言更为一致，并因而使语言更加易于学习和使用。这跟那些“对完成他们工作而不是语言细节更感兴趣”的程序员有什么关系呢？最显而易见的影响将会是标准库提供的新东西。一个规模更大的标准库，既节省开发劳动，也会降低对教学技巧的要求。早期C++的一个问题在于，即使对面向对象编程提供了良好支持，但它并没有提供一个优秀的库，以将OOP技术示范给用户看，这导致了大量的混乱和无稽之谈。泛型编程的引入工作做得要好一些，很大程度上是因为STL提供了一个学习和使用的具体范例。我多么希望我们早能有一个同样出色的例子，来展示异常（exceptions）的使用方法！ 我正致力于设计开发一个名叫XTI（eXtended Type Information）的库，它为一般C++类型信息提供接口，用于内省（introspection）和程序转换（program transformation）。我希望看到诸如此类的东西能够进入标准库。一般而言，我希望看到对分布式编程更好的支持，并坚信那种问题应该由库来解决。 RW：您认为C++编程的重要趋势是什么？ Bjarne： C++世界是如此之大，以至于你很难断定你所看到的东西到底是不是一种趋势。我猜想在嵌入社群C++的使用有大幅增长，但我对此不能确定。我知道对模板元编程（template metaprogramming）、泛型编程（generic programming）以及再生式编程（generative programming）感兴趣的人与日俱增，但我不能确定它们的群众基础到底有多么广泛。我猜测这些热门话题为先锋和学者们所津津乐道，其中部分而非全部新技术将会在接下来的几年里成为主流。看起来现在好像还有不少C++开放源码项目，但我也不能肯定。C++世界是如此之大，以至于没有任何个体可以完全理解它。 象泛型编程这样的新技术和模板异常（template exceptions）这样的新语言工具，正慢慢进入开放源码社群（当然了，在我看来，这个进程还是太慢了）。我希望看到一些开放源码项目能够更多地采用现代编程风格。导致这种“保守”的现状的原因在于，开放源码社群无法让开发者们“欢聚一堂”，以确保所有人对工具和技术的看法，类似且跟得上时代。 RW： C++已经成功到这种地步了吗 — 那些需要一种“具有C++设计标准”的语言的程序员会自动投向C++？ Bjarne：不然，世界并非如此简单。和所有人一样，程序员也会受到职业市场的影响。和所有人一样，程序员也易于过高估计新东西的优点而低估（或很少提及）其相应的缺点。当他们做出改变的时候，错误地以为他们不应该拉下什么重要的东西。注意，有时C++是一门“新语言”，人们投奔它的原因，和它技术上的优缺点毫无关系。在理想世界里，人们的选择客观而基于自身需要，但在现实世界中，我们往往流于主观，很少能够明了将来所需。结果，我们时而会萌生一种沮丧感。 RW：和Java、C#以及Visual Basic不同，没有哪个人拥有C++，如此一来，它酷似Linux和其它开放源码项目，但它却没有开放源码运动那么大的诉求力，原因何在？ Bjarne： C++并非以“救世主”自居，它讲究实效，C++也没有什么“政治立场”，除非你蓄意将“非专有，由ISO标准委员会所掌控”划归为一个政治立场。而且，在一些地方，C++的某些替代品的支持者不公正地中伤C++，说它是“一种微软语言”。此外，也许我过于关注性能和规模问题了，我很少去迎合新手和学生的需要。当然了，我对骗局的厌恶，可能也妨碍了对C++进行有效的市场营销。 RW：对于专有库供应者们的未来角色，您怎么看？ Bjarne：作为Addison-Wesley的“C++ In Depth”丛书编辑，我当然设法遴选重要且有意思的主题以及优秀的作者。我喜欢将库作为使思想和技术形象化的手段，这就是为什么你可以在我的编辑丛书中找到关于ACE、Loki和BGL方面的书籍。它们每一本都展示了技术思想 — 这些思想都不大知名且应用的也不象我所期望的那样广泛。然而，这并不意味我认为这套丛书所描述的每一个库都出类拔萃、尽善尽美。我总是期待更优秀的库。特别要指出的是，出版一本ACE图书，并不暗示比起商业库来我更偏爱开放源码库，两者角色都很重要。 我不是商人，也不是经济学家，所以我不会宣称哪儿能赚到钱。不过，我的印象是，真正的基础性技术或真正的新思想并不能赚钱，人们更愿意把钞票花在和他们密切相关的应用上。几乎可以断定，成功的专有库和工具才是商机之所在。 强固的工程、质量、规模、互通性、教学、维护和技术支持，是那些由“不要钱的程序员”所开发的软件需要一段艰苦的时间所要对付的问题。请注意，那些在较大范围内取得了成功的“免费”和开放源码提供者，是凭借“为了盈利”的计划而做到这一点的。就是程序员也有要吃饭的时候！ 我注意到，在过去几年里，C++标准库的一些商业实现已经广为流行，因此，我看不出标准库有什么必要与商业库竞争。我希望C++标准库能够成为更为专门的库（它们大多是专有库）的优秀基础。 RW： C为C++铺设了道路，您想像过C++为“下一种”语言铺设道路了吗？开发人员预期能够看到什么样的“范型转换” — 比方说procedural vs. OO？ Bjarne：我怀疑这个世界已经过于四分五裂了，不会存在什么单一的“下一种语言”，Java和C#都不是。 还有，关于“范型转换”也被谈论过滥。面向对象编程并不是以“在各方面都比过程式编程优越”的姿态而来的。我对技术（techniques）或风格（styles）的思考甚于范型（paradigms）。C++支持好几种风格，它是一门多范型语言。这很重要，因为象“范型”这样的的鬼把戏只是倾向于不互相排斥，而“风格”则可以互相支持。 所以，我宁愿不去猜想什么“下一种范型”的问题，我只预言它是否到来以及何时到来。你将会发现它和过程式、面向对象以及泛型技术互补，并能良好协作。 RW：编译期计算（compile-time computation）能力是模板的设计目标之一，抑或只是意外之喜？ Bjarne：都有一点。我致力于获得“原始权力”，比如允许内联和合并调用与定义的上下文。我将注意力放在某些重要例子的弹性和效率方面，比如对数组元素求和。那么，再加上对一般性甚于专用特性的自然偏爱，以及对不必要的限制的憎恶，这就为我未曾梦想过的技术（比如STL）开辟了道路，其中，模板好比就是C++的另外一个组成部分。我不喜欢创建纯属意料之中的东西。 RW：怎么才能让模板变得更易于开发人员学习呢？ Bjarne：我看不出有什么理由相信模板比类和类层次结构更会引起恐慌或难弄。当我引入类和类层次结构时，关于它们是如何得复杂、不安全、不好管、没有用的喧嚣，曾经震耳欲聋。 可悲的是，很多程序员面对新概念畏缩不前。我想，部分原因是出于“当把它作为关键的工具时”而萌发的谨慎的天性，其它则源于脑力上的懒惰，对新事物可能会破坏舒适的旧时光的忧惧，以及软件业界诽谤竞争者的恶习。 假如这些推断有道理，那么，当更多的人学习很好地使用新技术，当过度的狂热散去，当我们的工具品质改善时，那些噪音就会逐渐消失。和其它方法相比，模板能够以更简单的方式，表达某些重要的技术和解决方案，并能产生更有效率的代码。表达简练且速度快的代码，最终总是赢家。

页: [1]

查看完整版本: Bjarne Stroustrup's homepage