所谓Style就是在开销和功能、优雅和可维护性、灵活性和过度设计之间求得平衡。
本书帮助你在C++软件中使用Style进行设计、架构和编码，获得更好的健壮性和性能。
本书是Herb备受欢迎的Exceptional三卷本的终结篇，也是C++ In-depth系列中的又一力作。
本书英文支持网页：http://www.gotw.ca/publications/mxc++.htm
无
“C++设计新思维”丛书前言
自C++诞生尤其是ISO/ANSI C++标准问世以来，以Bjarne Stroustrup为首的C++社群领袖一直不遗余力地倡导采用“新风格”教学和使用C++。事实证明，除了兼容于C的低阶特性外，C++提供的高级特性以及在此基础上发展的各种惯用法可以让我们编写出更加简洁、优雅、高效、健壮的程序。
这些高级特性和惯用法包括精致且高效的标准库和各种“准标准库”，与效率、健壮性、异常安全等主题有关的各种惯用法，以及在C++的未来占据更重要地位的模板和泛型程序设计技术等。它们发展于力量强大的C++社群，并被这个社群中最负声望的专家提炼、升华成一本本精彩的著作。毫无疑问，这些学术成果必将促进C++社群创造出更多的实践成果。
我个人认为，包括操作系统、设备驱动、编译器、系统工具、图像处理、数据库系统以及通用办公软件等在内的基础软件更能够代表一个国家的软件产业发展质量，迄今为止，此类基础性的软件恰好是C++所擅长开发的，因此，可以感性地说，C++的应用水平在一定程度上可以折射出一个国家的软件产业发展水平和健康程度。
前些年国内曾引进出版了一大批优秀的C++书籍，它们拓宽了中国C++程序员的视野，并在很大程度上纠正了长期以来存在于C++的教育、学习和使用方面的种种误解，对C++相关的产业发展起到了一定的促进作用。然而在过去的两年中，随着.NET、Java技术吸引越来越多的注意力，中国软件产业业务化、项目化的状况愈发加剧，擅长于“系统编程”的C++语言的应用领域似有进一步缩减的趋势，这也导致人们对C++的出版教育工作失去了应有的重视。
机械工业出版社华章分社决定继续为中国C++“现代化”教育推波助澜，从2006年起将陆续推出一套“C++设计新思维”丛书。这套丛书秉持精品、高端的理念，其作译者为包括Herb Sutter在内的国内外知名C++技术专家和研究者、教育者，议题紧密围绕现代C++特性，以实用性为主，兼顾实验性和探索性，形式上则是原版影印、中文译著和原创兼收并蓄。每一本书相对独立且交叉引用，篇幅短小却内容深入。作为这套丛书的特邀技术编辑，我衷心希望它们所展示的技术、技巧和理念能够为中国C++社群注入新的活力。
荣耀
2005年12月
南京师范大学
www.royaloo.com
前言
场景：布达佩斯。一个炎热的夏天傍晚，穿过多瑙河望去，一直望见东岸。
在本书封面照片所展示的色彩柔和的欧洲风光中，首先映入你眼帘的是哪一栋建筑？几乎可以肯定是左边的国会大厦。这栋巨大的新哥特式建筑以其优美的圆穹、直插云霄的尖塔、大量的外部雕刻以及其他华丽的装饰在刹那之间抓住了你的目光，不过这更可能是因为它与周围的那些多瑙河畔刻板的实用主义建筑形成了鲜明的对比。
为何有此差异？原因首先在于国会大厦竣工于1902年，而其他刻板的实用主义建筑大都是在二战以后至1989年间建成的。
你可能会想，“啊哈，这解释了为何有此差异，不错，但这与《Exceptional C++ Style》到底有啥关系呢？”
毋庸置疑，对风格的表达与注入的哲学和思想倾向有很大的关系，不管我们是在谈论建筑架构还是软件架构，都是如此。我敢肯定你见过有着国会大厦那般规模和华丽的软件，也见过差劲的实用主义软件。极端地说，我还确信你见过不少过于追求风格华而不实的软件，以及很多只顾交差了事的“丑小鸭”（而且永远都不会变成白天鹅）。
风格抑或实用
哪一个更好？
不要过于自信你知道答案。首先，除非你定出明确的标准，否则“更好”只是一个无意义的术语—针对什么而言更好？在哪些情形下更好？其次，答案几乎总是这两者的平衡并以“这取决于……”开始。
本书就是关于如何在C++软件设计和实现的诸多细节方面找到平衡点，以及很好地了解你手头的工具和原料以便知道它们何时适于使用。
请快速回答：与周围单调乏味的建筑相比，国会大厦是更好的建筑吗？它的建筑风格更好吗？在不假思索的情况下你很容易给出肯定的回答—直到你不得不考虑其建造和维修的代价：
* 建造。在1902年竣工之时，它是世界上最大的国会大厦。人们花费了恐怖的时间、劳动和金钱来建造它，它被很多人认为是“大白象”，意指代价过高的美丽事物。不妨考虑一下：相较而言，花费同样的投资能够建造多少丑陋、单调甚至可能完全令人厌烦的混凝土建筑？别忘了，你工作于这样的一个行业：产品上市的压力远远超过建造该国会大厦所处时代的时间压力。
* 维修。熟悉国会大厦的人会注意到照片中的建筑正处于翻修中，此项工作已经持续好多年了，极有争议性地耗费了可怕的资金。除了最近这轮代价高昂的翻修外，此前已有过多次维修。原因在于—悲哀的是，你看到的这座建筑外部美丽的雕刻是用错误的材料制成的：这种材料太软了。在大厦最初竣工后不久，这些雕刻就成了人们持续维修的主题，它们已逐渐被替换为更坚固、更耐久的材料。始于19世纪早期的大规模维修自那以后一直没间断过，持续了近一个世纪。
软件的情形与之类似，重要的是在建造代价与功能之间、在优雅与可维护性之间、在发展的可能性与过分的华丽之间寻找适当的平衡点。
当使用C++实施软件设计和架构时，我们每天都要处理这些以及类似的权衡。在本书探讨的问题中有这样一些：使你的代码异常安全就会使它变得更好吗？果真如此，这里的“更好”是针对什么而言呢？何时它可能并非“更好”？该问题在书中有着明确的答案。封装又如何呢？它使你的软件变得更好吗？为什么？何时封装效果适得其反？如果你对此心存疑惑，请接着读下去。内联是一种好的优化手段吗？它是何时进行的呢？（回答这个问题时你千万慎之又慎。）C++中的export特性和国会大厦有何相通之处？std::string与多瑙河畔的整体建筑之间又有何共同点？
最后，在探讨许多C++技术和特性之后，我们将花费本书末尾一节考察一些摘自公开发布的代码的真实例子，看其作者在哪些方面做得不错，在哪些方面做得欠佳，以及什么样的替代方案可能在实用性和优秀的C++风格之间取得更好的平衡点。
我希望这本书以及《Exceptional C++》系列的其他书籍对你有何帮助呢？呃，我希望它们能够开阔你的视野，扩大你在技术细节及其相互关系方面的知识，并且增加你对如何找到软件开发平衡点的理解。
请再看一眼封面照片的右上方，对，就是那儿！我们都希望乘坐在那样的热气球中，飘荡在城市的上空，饱览美妙的全景。我们将会看看风格和实用性是如何共存、互动、关联和混合的，了解如何进行权衡并找到适当的平衡点，每一个决策都适得其所，并位于一个生机盎然的有机整体中。
是的，我认为布达佩斯是一个伟大的城市，它具有如此丰富的历史，它充满无尽的隐喻。
非凡的苏格拉底
古希腊哲学家苏格拉底通过向学生提问进行教学。那些问题被设计用于引导他们，并帮助他们从已知的东西得出结论，还向他们展示正在学习的东西是如何相互联系的，又如何与他们已有的知识相互联系。这种教学方式是如此著名，以至于今天我们称之为“苏格拉底教学法”。从我们作为学生的观点来看，苏格拉底传奇性的教学方法能够引起我们的兴趣，促使我们思考，帮助我们联系并应用已知的知识去获取新知识。
本书与其姊妹篇《Exceptional C++》[Sutter00]和《More Exceptional C++》[Sutter02]一样，借鉴了苏格拉底的方法。本书假定你正身处编写产品级C++软件的某些领域，它使用问答的形式教你如何有效地使用标准C++及其标准库，并特别关注于在现代C++中实施健全的软件工程。很多问题都直接来源于我和其他人在编写产品级C++代码时所积累的经验。问题的目标在于帮助你从已知的以及刚学到的东西中得出结论，并展示它们之间是如何相互联系的。而谜题则向你展示如何对C++设计和编程问题进行理性的分析。其中有些是常见的议题，有些则不那么常见；有些问题很简单，有些则比较深奥；还有一些问题只是因为它们有趣才出现于书中。
本书涵盖C++的方方面面。我的意思并不是说它触及了C++的每一个细节（那将需要多得多的篇幅），而是指它从C++语言和库特性的广阔的原料中选取素材，向你展示看似无关的特性是如何被综合使用的，从而形成针对常见问题的新颖的解决方案。本书还展示了那些看似无关的部分是如何相互关联的（即便有时你不希望它们之间有什么关联）以及如何处理这些关联。你将在本书中看到关于模板与名字空间、异常与继承、健壮的类设计与设计模式、泛型编程与宏的使用魔法等内容。它们并非以随意花边新闻的形式出现，而是以具有内在联系的条款的形式，向你展示现代C++中所有这些部分之间的相互关系。
《Exceptional C++ Style》从《Exceptional C++》和《More Exceptional C++》停步的地方继续前行。本书继承了前两本书的传统：它以短小精悍的条款为组织形式，并将这些条款分组为主题明确的章节，从而介绍新知识。读过前两本书的读者会发现一些熟悉的章节和主题，不过现在包含了新内容，例如异常安全、泛型编程以及优化和内存管理技术等。这几本书在结构和主题而非内容上有重叠之处。本书持续了对泛型编程和有效地使用C++标准库的强调，并包括对一些重要的模板和泛型编程技术的讨论。
书中的大多数条款最初出现于杂志专栏和因特网上，尤其出自我为《C/C++ Users Journal》、《Dr. Dobb誷 Journal》、《C++ Report》（已停刊）以及其他出版物撰写的专栏和文章，以及我的“Guru of the Week”[GotW]的议题63到86。与最初的版本相比，本书中的材料经过了重大的修订、扩充、校正和更新，因而本书（连同www.gotw.ca上不可或缺的勘误表）应被视作那些原始材料的最新权威版。
我假定你已经知道的
我期望你已经掌握了C++基础知识，如果你还没有，可以从一本介绍性和概览性的C++好书开始学习。像Bjarne Stroustrup的《The C++ Programming Language》（第3版）[Stroustrup00]或Stan Lippman和Jos巈 Lajoie合著的《C++ Primer》（第3版）[Lippman98]这样的经典著作都是不错的选择。接下来，务必选读一本编程风格指南，例如Scott Meyers的经典著作《Effective C++》系列[Meyers96, Meyers97]。我发现基于浏览器的CD版[Meyers99]方便且实用。
如何阅读本书
书中的每一个条款都以谜题或问题的形式呈现，并带有一个介绍性的头部，如下所示：
##. 本条款的标题 Difficulty: #
对该条款将要讨论的内容的简短介绍。
标题和难度等级提示你将要遭遇到什么。在主要问题（即Guru问题）之前通常是介绍性或回顾性的问题（即“JG问题”，其中JG（junior-grade）意指新来的下级军官）。注意，难度等级只是我自己预期大多数人认为问题有多难的主观猜测，因此，你也许会发现对你而言一个难度等级为7的问题比某个难度等级为5的问题更简单。实际上，自从写作《Exceptional C++》[Sutter00]和《More Exceptional C++》[Sutter02]以来，我就不断收到一些电子邮件，说“条款N比你说的要容易（或困难）！”对于同一个条款而言，不同的人认为“更容易”或“更困难”是很正常的。难度等级因人而异，任何条款的实际难度取决于你的知识和经验，它们对于其他人而言则可能更容易或更困难一些。话虽如此，大多数情况下你应该发现这些难度等级还是对你将要看到的内容（的难度）给出了相当合理的提示。
你也许打算从头至尾按顺序阅读本书，这很好，但你未必非得这样不可。你也许决定阅读某个特定章节中的所有条款，因为你对该章节的主题特别感兴趣，这同样很好。除了被我称为“小型系列”的那些被标以“Part 1”、“Part 2”等条款讨论的是相关的问题外，书中条款通常是相当独立的，因此你可以遵循条款之间的交叉引用以及对前两本“Exceptional C++”系列书籍的引用，自由地跳着读。我唯一要忠告的是，那些“小型系列”要成组按顺序阅读，除此之外，如何阅读全凭你的喜好。
除非我明确指出某段代码是一个完整的程序，否则它很可能不是。记住，代码示例通常只是代码片段或部分的程序，别指望它们能被独立编译。为了从这些代码片段构建出完整的程序，通常你需要补充一些显而易见的边角代码。
最后，关于URL有必要多说一句：在Web上，东西会动来动去。尤其是，我无法控制的一些内容会动来动去。这使得在印刷书籍上刊印随意的Web URL就变成了真正的痛苦：恐怕在该书下厂印刷之前那些URL就已经过时了，更不要说等它在你的书桌上躺上5年之后了。当我在本书中引用他人的文章或Web站点时，我是通过自己的Web站点（www.gotw.ca）上的URL做到这一点的——我自己的Web站点是我所能控制的，它只包含对实际Web网页的重定向链接。几乎所有在书中引用到的其他作品都已列在参考文献中了，而且在我的网站上还提供了一份具有活动超链接的在线版本。如果你发现印刷在本书中的一个链接不再有效，请写邮件告诉我，我将更新该链接，使其指向新的网页位置（如果我还能找到该网页的话），或者告诉你该网页已不复存在（如果我找不到的话）。不管怎么说，本书的URL将会保持为最新，尽管在这个因特网世界中印刷媒体的日子是如此难过。呜呼！
致谢
首先感谢我的妻子Tina，感谢她一贯的爱和支持。感谢我的家人在我写作本书和其他作品期间一直陪伴在我左右。即使当我不得不挑灯夜战写作另外一些文章或修改另外一些条款时，他们也总是表现出无尽的耐心。倘若没有他们的耐心和关爱，本书就绝不会有现在这般模样。
我们的小狗Frankie也付出了宝贵的贡献。当我工作时它常常希望我陪它玩，这强迫我不时出来呼吸一些新鲜空气。Frankie对软件架构或程序语言设计甚至代码微观优化一无所知，但它过得非常快乐。
非常感谢丛书编辑Bjarne Stroustrup、编辑Peter Gordon和Debbie Lafferty，还要感谢Tyrrell Albaugh、Bernard Gaffney、Curt Johnson、Chanda Leary-Coutu、Charles Leddy、Malinda McCain、Chuti Prasertsith以及Addison-Wesley团队的其他成员，感谢他们对这个项目的协助和坚持。很难想象还有比他们更好的共事伙伴，他们的热情和协作精神使我对这本书的所有期望都得到了实现。
还有一群人值得感谢和赞扬，就是许多专家审稿人。他们慷慨地提供了富有洞察力的见解并对书稿中的纰漏提出犀利的批评。他们的努力使得你手中的这本书更完整、更可读、更有用。尤其感谢他们向丛书编辑Bjarne Stroustrup提供的技术反馈。还要感谢在本书写作过程中为它的各个部分提出贡献性建议的以下各位人士：Dave Abrahams、Steve Adamczyk、Andrei Alexandrescu、Chuck Allison、Matt Austern、Joerg Barfurth、Pete Becker、Brandon Bray、Steve Dewhurst、Jonathan Caves、Peter Dimov、 Javier Estrada, Attila Feh巖, Marco Dalla Gasperina, Doug Gregor, Mark Hall, Kevlin Henney, Howard Hinnant、Cay Horstmann、Jim Hyslop、Mark E. Kaminsky、Dennis Mancl、Brian McNamara、Scott Meyers、 Jeff Peil、John Potter、P. J. Plauger、Martin Sebor、James Slaughter、Nikolai Smirnov、John Spicer、 Jan Christiaan van Winkel、Daveed Vandevoorde以及Bill Wade。书中残存的任何错误、疏忽和不谦虚的双关语，与他们无关，责任全在我自己。
Herb Sutter
2004年5月于西雅图
无
Herb Sutter：Herb Sutter: Herb Sutter是广受赞誉的Exceptional三卷本 (《Exceptional C++》、《More Exceptional C++》和《Exceptional C++ Style》)的作者，还曾发表了上百篇软件开发方面的技术文章和论文。他是ISO C++标准委员会的主席、《C/C++ Users Journal》的撰稿编辑和专栏作者。同时，他还担任Microsoft Visual C++架构师，负责C++语言在.NET编程环境扩展 (C++/CLI) 方面的工作。
无
1. Uses and Abuses of vector.
2. The String Formatters of Manor Farm, Part 1: sprintf.
3. The String Formatters of Manor Farm, Part 2: Standard (or Blindingly Elegant) Alternatives.
4. Standard Library Member Functions.
5. Flavors of Genericity, Part 1: Covering the Basis [sic].
6. Flavors of Genericity, Part 2: Generic Enough
7. Why Not Specialize Function Templates
8. Befriending Templates.
9. Export Restrictions, Part 1: Fundamentals.
10. Export Restrictions, Part 2: Interactions, Usability Issues, and Guidelines.
EXCEPTION SAFETY ISSUES AND TECHNIQUES.
11. Try and Catch Me.
12. Exception Safety: Is It Worth It
13. A Pragmatic Look at Exception Specifications.
CLASS DESIGN, INHERITANCE, AND POLYMORPHISM.
14. Order, Order!
15. Uses and Abuses of Access Rights.
16. (Mostly) Private.
17. Encapsulation.
18. Virtuality.
19. Enforcing Rules for Derived Classes.
MEMORY AND RESOURCE MANAGEMENT.
20. Containers in Memory, Part 1: Levels of Memory Management.
21. Containers in Memory, Part 2: How Big Is It Really
22. To new, Perchance to throw, Part 1: The Many Faces of new.
23. To new, Perchance to throw, Part 2: Pragmatic Issues in Memory Management.
OPTIMIZATION AND EFFICIENCY.
24. Constant Optimization
25. inline Redux.
26. Data Formats and Efficiency, Part 1: When Compression Is the Name of the Game.
27. Data Formats and Efficiency, Part 2: (Even Less) Bit-Twiddling.
TRAPS, PITFALLS, AND PUZZLERS.
28. Keywords That Aren't (or, Comments by Another Name).
29. Is It Initialization
30. double or Nothing.
31. Amok Code.
32. Slight Typos Graphic Language and Other Curiosities.
33. Operators, Operators Everywhere.
STYLE CASE STUDIES.
34. Index Tables.
35. Generic Callbacks.
36. Construction Unions.
37. Monoliths "Unstrung," Part 1: A Look at std::string.
38. Monoliths "Unstrung," Part 2: Refactoring std::string.
39. Monoliths "Unstrung," Part 3: std::string Diminishing.
40. Monoliths "Unstrung," Part 4: std::string Redux.
Bibliography.
Index.
