C++代码设计与重用
2012-7
人民邮电出版社
Martin D.Carroll,Margaret A.Ellis
267
371000
陈伟柱
无
一切事物都将得到检验并因此被称为问题。 Edith Hamilton 这本书的主要目的在于：展示如何以C++编程语言编写可重用代码—就是说，根据不同的需要，在不经过修改，或者经过很少修改的前提下，可重用代码可以很容易地应用到5个、50个甚至500个程序当中，而且这些程序往往是不同程序员编写的，可能运行在不同的系统上。在整个阐述的过程中，我们的目的并不在于争论是否所有的代码都是可重用的，也不在于说明可重用代码能够解决所有的程序问题。显然，不论是对程序员而言，还是对可重用代码本身而言，提高代码的重用性都是需要代价的；通常只有当我们有理由相信所给代码在将来有可能会被重用时，我们才会付出这些重用的代价。因此，本书的目的在于详细分析重用性的这些代价，于是当你面对是否编写可重用代码的选择时，可以从容地做出明智的决定。 关于本书 本书主要面向的读者是：那些希望从书中包含的许多深层C++编程见解中受益的读者，或者是那些需要或希望学习如何编写可重用代码的读者。在论述过程中，我们假设读者已经知道如何编写正确的C++代码。 C++语言至今还没有经过标准化（译注：本书写作于1995年，C++于1997年标准化），任意两个不同的编译器实现支持的语言几乎都是不同（稍微不同或者相差很大）的。当我编写这本书的时候，并没有一个编译器实现可以完全支持ANSI/ISO C++标准中最终定义的整个语言特性；而且，就算对同类型的编译器而言，前后版本实现的语言特性也不尽相同。于是，编写一本对所有编译器都适用的书是很困难的，或者是不可能的。因此，当我们讨论或使用一些不能被主流C++编译器所实现的特性时，我们将会另加说明。 当声明本书中的代码例子被认为合法时，我们所指的合法性是以1994年9月份ANSI/ISO C++的工作文件（有时候也称为“标准草案”）［ANS94］为依据的。而且，在我们的代码例子里，我们将尽量避免使用那些我们认为在最终ANSI/ISO C++标准公布之前，很有可能会被删除或者进行重大修改的语言特性。 要跟踪C++语言的演化，有几个资源是可以利用的。Internet讨论组comp.lang.c和comp. std.c++主要致力于C++的讨论。互联网中还有一个关于C++的主页。 而由纽约SIGS出版社定期发行的C++ Report，也经常会刊登许多C++程序员感兴趣的文章。至于学习C++的书籍，Lippman的[Lip91]和Stroustrup的[Str91]是最佳的学习教材。 任何关于重用性的完整讨论都会涉及软件开发的一些其他主题，如接口的设计、实现的效率、可移植性、冲突等。在书中的论述中，我们假设读者对软件开发已经有所了解；因此，我们只注重于那些应用于可重用代码的主题，而不是那些应用于一般软件开发的主题。 “每本教材都会撒谎”，这是我们老师非常喜欢的一句谚语。在这里，她实际要表达的意思是：每本教材为了教学的简化性和明确性，都必须简化书中的内容，从而都会歪曲所要表达的信息。显然，即使在需要简化的前提下，我们还是应该用抓住众多细节间的本质信息的方法来表述每个主题，这本书也不例外。于是，对于某些主题，即使有些读者已经对这个主题的方方面面都有所了解，我们还是希望他们能够和我们一起共同探讨该主题的内容。而且，对于一些主题内容的省略，我们也希望能够得到这些读者的谅解。 选择与建议 设计和编写可重用代码将会涉及许多选择（即在多种实现方案中选定某种方案），而某些选择的决定又是左右为难的。通常，对于这些选择，并没有完全确定或者正确的答案—无论你做出哪个选择，每个选择都是有代价的。我们将讨论各种不同选择方案的优点和缺点，从而让将来可重用代码的编写者可以从容地做出明智的决定。 有时，对于某个给定的决定，我们会认为某种风格或者方法要优于其他所有的风格或者方法。于是，当遇到这种情况时，我们会明确地建议采用这种风格或者方法，并给出支持这种风格或者方法的详细理由。然而，在大多数情况下，只有C++程序库的设计者，才能决定哪种方法对程序库用户而言是最好的。 这本书的一个目的在于：详细并且清楚地给出编写可重用代码的大多数重要选择。如果我们忽略了某些重要的选择，那么我们愿闻其详。 书中大多数关于选择的讨论都会提到效率。虽然我们并不认为效率是所有可重用C++代码最重要的设计目标，因为对于许多程序库设计而言，譬如扩展性、灵活性等其他特性将会比效率更加重要；但我们在文章中又处处提到效率，这是因为效率将会和可重用C++代码的其他每个可取的特性都相互制约。既然对效率已经花费了这么多笔墨，我们也希望可以给出所有和效率相互制约的因素。 代码例子 我们希望这本书的价值在于：与刚开始读这本书之前相比，当你读完这本书的时候，你将知道更多关于如何编写可重用代码的知识。因此，我们使用了大量的例子，而且许多例子的代码是来自于现实中已经存在的代码，因为，那些不是取材于真实代码的例子，不足以阐明实际编程中会出现的问题，也不足以说明实际编程中使用的各种技术。在这里，我们只是为了阐明重用性的目的而利用这些代码。 为了节省篇幅，成员函数的主体通常都是在类的声明中给出；即使在重用性的代码设计中，这些函数也不会被实现为内联函数。例如，读者不应该从下面的类定义语句中得出：函数f是内联函数（就是说实际上f不是内联函数）的结论。 class Z { void f() { //... } }； （关于如何决定某个函数是否应该实现为内联函数，我们将在4.4.1节讨论这个问题） 当提到模板成员函数的时候，在不致引起混淆的前提下，我们通常都会省略模板参数。例如，我们将把下面代码中的成员函数f： template class X { void f()； }； 表示为X：：f，而不是X：：f。 通常，现实程序库例子中给出的类大多是模板，而在书中，为了能够使阅读更加容易，并且有利于更加清楚地表述每个主题，我们就进行了简化。相似地，现实程序库中的嵌套类也并不都如嵌套语法所定义的那样，但是，当我们在书中给出一个嵌套类的时候，我们将不使用前置声明语法。例如，我们将如下编写嵌套类： class X { class Y { //... }； //... }； 而不是如下编写嵌套类： class X { class Y； //... }； class X：：Y { //... }； 虽然前置声明语法能够提高可重用代码的可读性，但是许多C++编译器都不能实现这种语法。 现今，任何我们可用的编译器，都还没有实现新的强制转型（cast）语法。这个语法是一个很新的C++特性（针对于编写这本书的时候），我们也还不具备应用这个语法的充分经验，因此，我们在书中没有使用这个语法。 术语 在本文中，我们将使用程序库概念来表示可重用代码的集合。我们也经常互换地使用程序库和可重用代码这两个概念。另外，当我们说“编写”代码段的时候，我们的意思是“设计和实现”这段代码。 我们将使用编译程序来指代任何程序或者任何把源代码翻译成可执行代码的程序集合。翻译将包括：预处理C++使之成为另一种语言，然后把这种语言编译或者汇编成可执行代码。 为了行文简洁，我们在文章中使用的基类，不仅用来表述其他类的基类，而且还表述这个类可让其他类派生自该类。 C++操作符 ostream& operator(istream& i，T＆ t)； （对于某个给定的类型T）提供了T类型的流插入和流输出操作符。为了和通常的使用习惯保持一致，我们把它们分别叫做T的输入操作符和输出操作符。 关于模板和模板实例化的术语，C++社区仍然有许多不一致的意见。不同的人可能会使用术语模板类、类模板、实例化、实例、特化等中的一个，来描述不同（或者相似）的事物。这些术语准确而且标准的定义最后将由ANSI/ISO C++委员会来决定。下面说明了我们在此书中如何使用这些概念： 类模板：形如templateX的模板，其中X为类的定义。 函数模板：形如templatef的模板，其中f为函数的定义。 类模板特化：当类模板的参数被实际参数替代时，而得到的类。 函数模板特化：当函数模板的参数被实际参数替代时，而得到的函数。 实例化：产生特化的过程。 模板类：我们不使用这个术语。 模板函数：我们不使用这个术语。 例如，考虑下面的类模板： template class X { //... }； 类X和类X就是这个模板的两个特化。另外，特化通常是隐式定义的，如： template class X { /*...*/}； X x； //X就是隐式定义的。 偶尔，某些C++程序员也会显式定义特化，例如： templateclass X { /*...*/ }； class X {/*...*/}； //X在这里显式定义。 x x； 而许多人把特化这个术语仅仅看成是显式特化，这是不正确的。虽然我们定义的这些术语都是非常相似的，但我们相信，ANSI/ISO很快将会给出这些术语很好的定义。 通常，在不会引起混淆的前提下，我们会使用“类”来代替“类模板”，“函数”来代替“函数模板”。 致谢 在这本书的创作过程中，许多人通过多种方式支持过我们。我们在这里对他们表示衷心的感谢。 这本书的评审者所做出的贡献和该书的价值几乎是等同的。我们特别感谢那些对我们要求严格的评论者，他们总是相信我们可以做得更好。这其中包括Tom Allocco、Manuel Bermudez、James Coggins、Keith Gorlen、Tony Hansen、Chris Hornick、Peter Juhl、Brian Kernighan、Andrew Koenig、Eason Kung、Rao Kuimala、Doug Lea、Stan lippman、Tom Lyon、Glen McCluskey、Barbara Moo、Rob Murray、Jishnu Mukerji、Scott Myers、Steve Pendergrast、Ed Schiebel、Jonathan Schilling、Jonathan Shopiro、Bjarne Stroustrup、Steve Vinoski、Jedy Ward和Clay Wilson。 我们也收到了许多读者很有用的反馈信息，他们是Dag Bruck，Rich Kempinski，Josee Lajoie，Deborah McGuinness，David C.Oliver，Jeffrey Persch，Ellia Weixelbaum和两个分别叫做Lars和Steve的网友。 这本书的许多观点首次来自于我们设计C++标准组件库的实践，这个组件库最初是由贝尔实验室开发的。因此，我们要感谢我们的同事们关于这个项目的许多有深度的讨论。他们是John Tsner， Andrew Koenig， Dennis Mancl， Rob Murray， Jonathan Shopiro，Alex Stepanov， Terry Weitzen和Nancy Wilkinson。 如果没有C++，那么这本书（也包括其他的许多书）肯定是不会存在的。因此我们非常感谢Bjarne Stroustrup给我们带来了这样一个我们最喜欢的编程语言。另外也感谢ANSI/ISO C++标准委员会的所有成员，正是因为他们孜孜不倦的工作（往往都是自愿而且无功利的），才能使整个C++社区生机焕发。 感谢在我们这本书的编写过程中，我们这本书的审订者—Marha Currie，Barbara Moo和John Spicer—感谢他们的支持和鼓励。也感谢我们的雇主—贝尔实验室和UNIX系统实验室（现在是Novell UNIX系统小组）—感谢他们给了我们编写这本书的机会，而且还感谢他们为我们提供的时间、硬盘空间、打印纸等。 我们非常感谢来自Addison-Wesley的大力支持。其中，充满活力的Tom Stone和生性乐观的Debbie Lafferty都是很好的合作伙伴。另外，Lyn Dupre给了我们最好的编辑指导，书的设计者Juliet Silveri的工作总是一丝不苟，Pat Daly是一个很专业的编辑，Roberta Clark对我们的草稿进行了校对。我们还要感谢John Wait，正是因为他一贯坚持让Martin编写一本关于C++和重用的书，才会有这本书的诞生。然后，也很感谢Jim DeWolf，他为我们提供了暖气和空调，这笔支付也是不菲的，从而给我们带来了一个很好的环境和开端。 衷心感谢Tom Reinhardt，他可以说是世界上最好的外科临床医学家。也感谢我们的朋友Paul Lustgarten，他是我们以前的房东，很慷慨地允许我们时时占用他的电话线。还感谢David Wooley，正是他让Martin在大学中进入到BASIC编程领域中来的。真诚地感谢Marybeth为我们拍了书背面的那张照片。 最后，但也是很重要的，我们真诚感谢我们的家人和朋友，他们和我们度过了这本书编写过程中的许多酸甜苦辣的日子，并且时时刻刻给予我们支持与关怀。
《C++代码设计与重用》全面展示如何使用C++编写可重用的代码，从而提高程序员的开发效率。全书分为12章。包括重用性基本概念、类设计、扩展性、效率、错误、冲突、兼容性、继承、移植性、程序库等和重用相关的诸多话题。每一章的最后，通过总结和练习帮助你巩固概念、加深理解，参考文献和相关资料为你指明了深入学习的方向。
《C++代码设计与重用》适合有一定C++经验的程序员阅读，也可供以提高代码重用性为专门学习方向的读者参考。
Martin Carroll是AT&T贝尔实验室的技术人员，他曾经用好几年的时间致力于设计和实现可重用的C++程序库，包括AT&T标准组件库（Standard Components Library）。他在Rutgers大学获得计算机科学博士学位。
Margaret Ellis 是The Annotated C++ Reference Manual的合著者（另一个作者是大名鼎鼎的C++之父Bjarne Stroustrup），她主要致力于AT&T贝尔实验室、UNIX系统实验室和美国Novell公司的编译器开发。她曾获得加州大学计算机专业的硕士学位。
第1章 重用性介绍 1
1.1 什么是重用性 1
1.1.1 提取代码来作为重用 2
1.1.2 可重用代码的基本特性 2
1.2 重用的神话 3
1.3 重用的障碍 4
1.3.1 非技术障碍 4
1.3.2 技术障碍 5
1.4 希望是否尚存 6
1.5 这本书能给我们带来什么 7
l.6 练习 8
1.7 参考文献和相关资料 9
第2章 类的设计 11
2.1 抽象性 11
2.2 正规函数 12
2.3 Nice类 14
2.4 存在最小标准接口吗 15
2.4.1 缺省构造函数 16
2.4.2 赋值运算符 17
2.4.3 拷贝构造函数 18
2.4.4 相等运算符 18
2.4.5 析构函数 18
2.5 浅拷贝和深拷贝 19
2.6 接口一致性 22
2.7 转型 25
2.7.1 多重所有权(Multiple Ownership) 26
2.7.2 敏感转型 26
2.7.3 不敏感转型 28
2.7.4 转型数目(Fanout) 28
2.8 const关键字的使用 29
2.8.1 抽象const对比位元const 29
2.8.2 最大限度地使用const 31
2.8.3 对const不安全的解释 32
2.9 总结 33
2.10 练习 34
2.11 参考文献和相关资料 37
第3章 扩展性 39
3.1 扩展性的权衡 39
3.2 扩展性和继承 40
3.2.1 只继承基类的接口 41
3.2.2 只继承基类的实现 42
3.2.3 同时继承基类的接口和实现 43
3.3 继承语义(Semantie) 43
3.4 继承的障碍 45
3.4.1 非虚成员函数 45
3.4.2 过度保护 47
3.4.3 模块化不足 48
3.4.4 friend关键字的使用 51
3.4.5 成员变量过多 52
3.4.6 非虚(Nonvirtual)派生 52
3.4.7 妨碍继承的成员函数 53
3.5 派生赋值问题 55
3.6 允许入侵(用户修改源代码)继承 57
3.7 总结 58
3.8 练习 58
3.9 参考文献和相关资料 60
第4章 效率 61
4.1 效率和重用性 61
4.2 程序创建时间 62
4.2.1 编译时间 62
4.2.2 实例化时间 64
4.3 代码大小 69
4.3.1 源文件分割 69
4.3.2 外联的(outlined)inline 71
4.3.3 模板特化大小 71
4.4 运行时间 72
4.4.1 内联(inlning) 72
4.4.2 虚函数 74
4.4.3 返回引用 76
4.5 空闲存储空间(free-store)和堆栈空间(stack space) 78
4.5.1 使用高效的算法 79
4.5.2 尽可能快地释放空闲资源 80
4.5.3 静态对象 81
4.5.4 庞大的对象 82
4.6 效率的权衡 83
4.6.1 实现更加困难 84
4.6.2 使用更加困难 86
4.7 总结 86
4.8 练习 87
4.9 参考文献和相关资料 89
第5章 错误 91
5.1 可重用代码中的错误 91
5.2 错误检测 92
5.2.1 函数前提条件 93
5.2.2 表示不变性 93
5.3 处理错误 95
5.3.1 程序库变量 95
5.3.2 解决问题 95
5.3.3 程序退出或者程序终止(Exit or Abort) 96
5.3.4 抛出异常 96
5.3.5 返回错误值 97
5.3.6 创建Nil值 98
5.3.7 把无效的数据解释为有效的数据 99
5.3.8 允许不确定的行为 99
5.4 资源限制(Resource-Limit)错误 100
5.4.1 堆栈溢出 100
5.4.2 用完空闲存储空间 101
5.4.3 文件系统限制 102
5.5 异常安全性 103
5.5.1 不一致的状态 104
5.5.2 资源泄漏 105
5.6 总结 106
5.7 练习 107
5.8 参考文献和相关资料 110
第6章 冲突 111
6.1 全局名称 111
6.1.1 翻译单元 112
6.1.2 类的定义 112
6.1.3 函数和数据的定义 114
6.1.4 程序库的蕴涵意义 114
6.1.5 命名约定 115
6.1.6 namespace(名字空间)结构 117
6.2 宏名称 118
6.2.1 宏名称冲突 118
6.2.2 去掉宏 119
6.2.3 宏的命名约定 121
6.3 环境名称 121
6.4 Unclean程序库 122
6.5 Good-Citizen程序库 123
6.6 总结 123
6.7 练习 124
6.8 参考文献和相关资料 125
第7章 兼容性 127
7.1 向后和向前兼容性 127
7.2 兼容性的形式 128
7.3 理论源代码兼容性 129
7.4 实际源代码兼容性 130
7.5 链接兼容牲 131
7.6 运行兼容牲 133
7.7 进程兼容性 134
7.8 文档化不兼容性 135
7.9 非文档化特性 135
7.10 总结 136
7.11 练习 137
7.12 参考文献和相关资料 142
第8章 继承体系 143
8.1 根数目、深度和扇出数 143
8.2 体系类型 146
8.2.1 直接体系 146
8.2.2 接口体系 147
8.2.3 对象工厂(Object Factory) 149
8.2.4 句柄体系 151
8.3 模板还是继承 154
8.3.1 指针操纵 155
8.3.2 派生要求 156
8.3.3 实现不需要的函数 157
8.4 总结 158
8.5 练习 159
8.6 参考文献和相关资料 161
第9章 移植性 163
9.1 有编写可移植代码的必要吗 163
9.1.1 可移植性的优缺点 163
9.1.2 目标代码和创建过程的可移植性 164
9.2 不断发展的语言定义 165
9.2.1 冲突 165
9.2.2 实现的完整性 166
9.3 不确定的行为 166
9.3.1 排列方式和补全(padding) 167
9.3.2 地址操纵 168
9.4 合法但不可移植的代码 169
9.4.1 实现性定义的行为 169
9.4.2 未经指定的行为 170
9.5 实现依赖性 171
9.6 可移植的数据文件 172
9.7 模板实例化 173
9.7.1 自动的实例化器 173
9.7.2 人工实例化 177
9.8 运行期程序库 179
9.9 其他移植性问题 180
9.10 总结 181
9.11 练习 182
9.12 参考文献和相关资料 184
第10章 使用其他程序库 185
10.1 为何要重用其他程序库 185
10.2 使用其他程序库的缺点 186
10.2.1 获得可重用程序库 186
10.2.2 效率 187
10.2.3 冲突 187
10.2.4 版本同步 188
10.3 自含式(Self-Contained)程序库 190
10.3.1 实现困难 190
10.3.2 使用困难 191
10.3.3 效率 192
10.3.4 隔离 192
10.4 总结 193
10.5 练习 193
第11章 文档编制 195
11.1 文档编制和重用性 195
11.2 设计文档 196
11.3 使用指南 196
11.3.1 对读者的背景知识了如指掌 197
11.3.2 用抽象的观点来编写 197
11.3.3 先解释普通用法 198
11.3.4 一次只解释一个事物 198
11.3.5 解释用法，不解释设计思路 199
11.3.6 简单清楚地编写 199
11.3.7 准确地使用语言 199
11.3.8 使用普遍接受的术语 200
11.3.9 深刻理解重载的术语 200
11.3.10 给出合法的、无错误的代码 201
11.3.11 保持简短的代码段 201
11.3.12 避免使用太大的函数 201
11.3.13 提供在线实例 202
11.4 参考手册 203
11.4.1 抽象化 203
11.4.2 语法接口 203
11.4.3 函数语义 205
11.4.4 模板参数约束 206
11.5 总结 207
11.6 练习 207
11.7 参考文献和相关资料 208
第12章 其他话题 209
12.1 静态初始化问题 209
12.1.1 构造和析构的时刻 210
12.1.2 程序库的蕴含意义 211
12.1.3 初始化函数 213
12.1.4 初始化检查 214
12.1.5 初始化对象 216
12.1.6 双构造 217
12.2 局部化开销原则 218
12.2.1 局部化开销和C++ 219
12.2.2 局部化开销和程序库 219
12.3 内生类和外生类 220
12.4 迭代器 222
12.5 类耦合 224
12.6 推迟决定 226
12.7 总结 229
12.8 练习 229
12.9 参考文献和相关资料 232
中英文术语对照表 233
参考文献 261
最早知道这本书，是在Scott Meyers著名的More Effective C++ 书籍推荐列表里。在谈到这本书的时候，Meyers说：“有意撰写程序库的人，若没有读过此书，那只能是匹夫之勇。”而Francis Glassborow则说，大多数程序库设计者应该搬过小板凳来，像小学生那样学习这本书。 用C++的人，历来以能撰写出重用性好的程序库而引以为傲。然而，撰写可用的程序库已属不易，撰写可重用的程序库更是专家级任务，以至于有人感叹道，重用是C++程序员们的“圣杯”—总在嚷嚷着，却始终得不到。其实何止C++如此，在其他语言中，重用又何尝不是令人胆怯的挑战！只不过C++编译语言的本质与人们对C++程序性能的严苛要求，使得用C++编写可重用组件更为困难。这样一个艰难的主题，敢于涉足已经是非常有勇气了，而能得到Meyers等人如此高的评价，则非C++中的顶尖人物倾力而为不可。事实上，作者Martin Carroll和Margaret Ellis正是这样的顶尖人物。他们是AT&T实验室的研究人员，从20世纪80年代中期开始就处于C++演化和发展的中心，长期从事编译器和基础库的开发工作，积累了普通程序员无法比拟的经验。特别值得一提的是，Margaret Ellis曾与Bjarne Stroustrup合作撰写了C++早期的经典著作ARM（The Annotated C++ Reference Manual），是C++社群里最受尊敬的巾帼英雄之一。在这本书中，两位作者把自己多年来撰写可重用库的经验和教训高浓度地总结起来，给出了很多具有深刻洞察力的建议。虽然从此书英文版出版至今已有几年的时间，但是书中的真知灼见仍然值得我们一再学习体会。我甚至认为，即使你不打算撰写程序库，甚至不是C++程序员，认真阅读这本书都是很有好处的。毕竟这本书来自具有丰富实战经验的顶尖专家之手，而这样的书实在是太少了。 译者陈伟柱是我的好朋友，在C++、Java、模式和重用等方面都有比较深刻的理解。他对待此书翻译工作的态度极为认真，正是这一点令我对这本书的翻译质量很有信心。原书作者是以技术扎实而谦恭简和著称的，他们的文字也是平实简练而深富内涵的，我认为伟柱的为人和他的文字也具有这样的特点。因此，我衷心希望读者也能以平实谦和的心态认真、扎实地阅读和学习此书，并祝愿大家能有满意的收获。 ——孟岩
Scott Meyers与Francis Glassborow鼎力推荐的顶尖图书，“大多数程序库设计者应该搬过小板凳来，像小学生那样学习这本书”。在这本书中，两位作者把自己多年来撰写可重用库的经验和教训高浓度地总结起来，给出了很多具有深刻洞察力的建议。认真阅读吧，因为这本书来自具有丰富实战经验的顶尖专家之手，而这样的书实在是太少了。
无
全面展示如何使用C++编写可重用的代码，从而提高程序员的开发效率。
C++代码设计代码与重用，真的不错，质量挺好，发货速度挺快。
本书以质量要素为基本线索，讲述C++的程序库应该如何设计和实现。这是一本需要一定经验才读得懂的书：粗看起来讲了很多技巧，而且过于繁复，不实用；只有真正经历过这些问题的人才会感觉到背后的精彩。最喜欢的章节有：类的设计，错误处理、使用其它程序库，以及文档编制。
C++方面买书我一向肯花钱，本书由effictive c++系列的作者推荐，我看了看目录，发现确实是一本好书，可以和《重构：改善既有代码的设计》一书联合起来看，相信对于我们提升功力有非常明显的效果
通过C++代码学习软件设计之道。
好书，写得深入浅出，适合一般的c++程序员。
适合C++中级开发工程师学习。
值得好好学习呀~推荐各位大家大家都看看吧
非常好的一本书，建议有一定c++经验的人阅读
经典书籍，值得反复看。同事推荐的。
买这本书，主要用来提高我的C++基础，不错。
要有一定的基础才能看懂，正在学习中。
想找一本能深入学习C++的书，不知道是否找对了书。。。
包装很好，纸张质量也不错，有时间的时候慢慢学习 ：）
本书很不错，适合入门人士
值得认真学习拜读
C++图书
暂时还没时间看，只是稍稍翻了一下，不好说。
对于刚入门的可能不太适合，适合有点基础的
很喜欢这本书，受益匪浅！
本书内容没的说，英文好的建议看原版
本书较为实用。
研究中，很基础，不错地一本书
书不错，但我目前的水平还看不懂，等把基础打牢了再看
还没仔细看过，C++怎么会越学越难呢？
在书店看了一会就决定买了
水水水水死死死死死死死死死死死死
看了几页，虽然是老书籍了，还不错吧
再次认识一下C++，有很多不知道的东东。值得看一下
非常不错的书，对自己要求较高的朋友可以选择入手
写得很好——只可惜能力不够，看不太懂
书不错！当当送货速度相当给力！！顶当当！
还没有细看，看了下目录，感觉还不错
物流很快啦。
待斟酌
期待大师的作品
内容给力，包装给力，快递给力
推荐人，搞程序的人应该不会没听说过吧。可以一读。
内容不错，值得学习，理论较深，需要掌握一定的基础再看，适合基础较好的人去读
这本书买了，但还没读完。整体上觉得不错，很有深度，讲解很细致、很全面，介绍的功力、阐述的能力均属一流，是本难得的好书
虽然有点老，但是依然经典。值得已读。
很不错，帮助很大。
还没开始研读，希望得到实际有用的知识
还在看，感觉还不错，有点深
可惜比较老
一些思路和想法值得借鉴
看过电子版的感觉还可以
对学业有用
总体来说，还算可以，就是书有点薄，书的纸张4还是不错的，内容也挺好的
看了几页还可以字体清晰
从目录来看，应该还不错，希望能提升一下编程进阶，呵呵
这本对高级程序员很有价值，买需要的书才好
读起来没哪么流畅
高深看不懂了
跟想象中的有点儿距离，没有想象中的使用，不过将的也挺好的
个人来说没什么用，失望了，翻了翻都是自己知道的东西，也许对别人有用，对我来说可以放书架上了...也许用到的时候会翻一翻吧。
挺不错的书，值得一看，入门用
装订的太差了!
c++的新书，很好很实用
很不错 送货快 包装很不错
先囤着，慢慢看。包装不错。
老书重印
这本，慢慢看