[16] 切记precision 描述只对所后所的浮点数输出操作有效。
[17] 用字符串流做内存里的格式化。
[18] 你可以描述一个文件流的模式。
[19] 在扩充I/O 系统时，应该清楚地区分格式化（iostream）和缓冲（streambuf）。
[20] 将传输值的非标准方式实现为流缓冲。
[21] 将格式化值的非标准方式实现为流操作。
[22] 你可以利用一对函数隔离和封装其对用户定义代码的调用。
[23] 你可以在读入之前用in_avail()去确定输入操作是否会被阻塞。
[24] 划分清楚需要高效的简单操作和实现某种策略的操作（将前者做成inline，将后者做成virtual）。
[25] 用locale 将“文化差异”局部化。
[26] 用sync_with_stdio(x)去混合C 风格和C++风格的I/O，或者离解C 风格和C++风格的I/O。
[27] 当心C 风格I/O 的类型错误。
第22 章数值
[1] 数值问题常常和微妙。如果你对数值问题的数学方面不是100%有把握，请去找专家或者做试验。
[2] 用numberic_limits 去确定内部类型的性质。
[3] 为用户定义的标量类型描述numberic_limits。
[4] 如果运行时效率比对于操作和元素的灵活性更重要的话，那么请用valarray 去做数值计算。
[5] 用切割表述在数组的一部分上的操作，而不是用循环。
[6] 利用组合器，通过清除临时量和更好的算法来获得效率。
[7] 用std::complex 做复数算术。
[8] 你可以把使用complex 类的老代码通过一个typedef 转为用str::complex 模板。
[9] 在写循环从一个表出发计算某个值之前，先考虑一下accumulate()、inner_produce()、partial_sum()和adjacent_difference()。
[10] 最好使用具有特定分布的随机数，少直接用rand()。
[11] 注意是你的随机数充分随机。
第23 章开发和设计
[1] 知道你试图达到什么目的。
[2] 心中牢记软件开发是一项人的活动。
[3] 用类比来证明是有意的欺骗。
[4] 保持一个特定的实实在在的目标。
[5] 不要试图用技术方式去解决社会问题。
[6] 在设计和对待人员方面都应该有长期考虑。
[7] 对于什么程序在编码之前先行设计是有意义的，在程序规模上并没有下限。
[8] 设计过程应鼓励反馈。
[9] 不要将做事情都当做取得了进展。
[10] 不要推广到超出了所需要的、你已有直接经验的和已经测试过的东西。
[11] 将概念表述为类。
[12] 系统里也存在一些不应该用类表述的性质。
[13] 将概念间的层次关系用类层次结构表示。
[14] 主动到应用和实现中去寻找概念间的共性，将由此得到的一般性概念表示为基类。
[15] 在其他领域中的分类方式未必适合作为应用中的继承模型的分类方式。
[16] 基于行为和不变式设计类层次结构。
[17] 考虑用例。
[18] 考虑用CRC 卡。
[19] 用现存系统作为模型、灵感的源泉和出发点。
[20] 意识到视觉图形工程的重要性。
[21] 在原型成为负担时就抛弃它。
[22] 为变化而设计，将注意力集中到灵活性、可扩展性、可移植性和重用。
[23] 将注意力集中到组件设计。
[24] 让每个界面代表在一个抽象层次中的一个概念。
[25] 面向变化进行设计，以求得稳定性。
[26] 通过将广泛频繁使用的界面做得最小、最一般和抽象来使设计稳定。
[27] 保持尽可能小，不为“特殊需要”增加新特征。
[28] 总考虑类的其他表示方式。如果不可能有其他方式，这个类可能就没有代表某个清晰的概念。
[29] 反复评审、精化设计和实现。
[30] 采用那些能用于调试，用于分析问题、设计和实现的最好工具。
[31] 尽早、尽可能频繁地进行试验、分析和测试。
[32] 不要忘记效率。
[33] 保持某种适合项目规模的规范性水平。
[34] 保证有人负责项目的整体设计。
[35] 为可重用组件做文档、推介和提供支持。
[36] 将目标与细节一起写进文档里。
[37] 将为新开发者提供的教许材料作为文档的一部分。
[38] 鼓励设计、库和类的重用，并给予回报。
第24 章设计和编程
[1] 应该向数据抽象和面向对象设计的方向发展。
[2] （仅仅）根据需要去使用C++的特征和技术。
[3] 设计应与编程风格相互匹配。
[4] 将类/概念作为设计中最基本的关注点，而不是功能/处理。
[5] 用类表示概念。
[6] 用继承（仅仅）表示概念间的层次结构关系。
[7] 利用应用层静态类型的方式给出有关界面的更强的保证。
[8] 使用程序生成器和直接界面操作工具去完成定义良好的工作。
[9] 不要去使用那些与任何通用程序设计语言之间都没有清晰界面的程序生成器或者直接界面操作工具。
[10] 保存不同层次的抽象相互分离。
[11] 关注组件设计。
[12] 保证虚函数有定义良好的意义，每个覆盖函数都实现预期行为。
[13] 公用界面表示的是“是一个”关系。
[14] 成员表示的是“有一个”关系。
[15] 在表示简单包容时最好用直接成员，不用指向单独分配的对象的指针。
[16] 设法保证使用依赖关系为易理解的，尽可能不出现循环，而且最小。
[17] 对于所有的类，定义好不变式。
[18] 显式地将前条件、后条件和其他断言表述为断言（可能使用Assert()）。
[19] 定义的界面应该只暴露初尽可能少的信息。
[20] 尽可能减少一个界面对其他界面的依赖性。
[21] 保持界面为强类型的。
[22] 利用应用层的类型来表述界面。
[23] 将界面表述得使请求可以传递给远程得服务器。
[24] 避免肥大的界面。
[25] 尽可能地使用private 数据和成员函数。
[26] 用protected/private 区分开派生类的设计者与一般用户间的不同需要。
[27] 使用模板去做通用型程序设计。
[28] 使用模板去做算法策略的参数化。
[29] 如果需要在编译时做类型解析，情使用模板。
[30] 如果需要在运行时做类型解析，请使用层次结构。
第25 章类的作用
[1] 应该对一个类的使用方式做出有意识的决策（作为设计师或者作为用户）。
[2] 应注意到涉及不同种类的类之间的权衡问题。
[3] 用具体类型去表示简单的独立概念。
[4] 用具体类型去表示那些最佳效果及其关键的概念。
[5] 不要从具体类派生。
[6] 用抽象类去表示那些对象的表示可能变化的界面。
[7] 用抽象类去表示那些可能出现多种对象表示共存情况的界面。
[8] 用抽象类去表示现存类型的新界面。
[9] 当类似概念共享许多实现细节时，应该使用结点类。
[10] 用结点类去逐步扩充一个实现。
[11] 用运行时类型识别从对象获取界面。
[12] 用类去表示具有与之关联的状态信息的动作。
[13] 用类去表示需要存储、传递或者延迟执行的动作。
[14] 利用界面类去为某种新的用法而调整一个类（不修改这个类）。
[15] 利用界面类增加检查。
[16] 利用句柄去避免直接使用指针和引用。
[17] 利用句柄去管理共享的表示。
[18] 在那些能预先定义控制结构的应用领域中使用应用框架。
附录B
[1] 要学习C++，应该使用你可以得到的标准C++的最新的和完全的实现。