可以把这本书重命名为<<C++设计模式>>，也可以重命名为<<C++编程思想>>，甚至还可以叫它<<C++语言的设计和演化>>，总之，Koening谈到了以上所有方面，并且首先是编程思想和设计原则，其次才是C++，而其与Bjarne Stroustrup高度一致的思想，可以让人领略或者叹服一下C++社团的核心文化
基本上没什么可摘录的，因为除了包含很多代码的章节，剩下的几乎可以通篇摘录；很多代码都在标准库中有对应版本，但无论如何，如果能手工重新实现这些代码，一定会获益匪浅
用类来表示概念
识字最多的人一定是最好的作家吗？能演奏最多音符的人一定是最好的音乐家吗？最勤于挥舞画笔的人一定是最好的画家吗？显然不是，这些观点及其荒谬；然而，我们却经常认为，那些了解语言特性最多的人就是最好的程序员；这一看法同样是荒谬的：编程中最困难的部分并不是去学习语言细节，而是理解问题的解决之道
抽象是有选择的忽略，选择忽略什么和何时忽略
类设计者的核查表：你的类需要一个构造函数吗？你的类需要一个无参的构造函数吗？你的类需要一个复制构造函数吗？你的数据成员是私有的吗？是不是每个构造函数都初始化所有的数据成员？类需要析构函数吗？类需要虚析构函数吗？你的类需要赋值操作符吗？你的赋值操作符能正确的将对象付给本身吗？你的类需要定义关系操作符吗？记得在赋值操作符和复制构造函数的参数类型中加上了const吗？如果函数参数有引用参数，它们应该是const引用吗？记得适当的声明成员函数为const了吗？
设计一个成功的容器不可能是自然而然的；如果真有唯一正确的方法来做这件事，那么倒不如把它内建到语言中罢了
软件工程基本定理：引入一个额外的中间层，我们能够解决任何问题
函数对象适配器所解决的问题之一，是把信息从使用该函数对象的部分通过程序的另一部分（这一部分对要传递的信息一无所知）传递到第三部分中
所有这些改进都得益于数据抽象的概念：如果对某个类对象的所有单个操作都将对象置于一种合理的状态，那么对象的状态就会始终保持合理
我们不知道到底哪种策略正确：只要作出决定并写出文档就可以了
设计一个好程序库的要求之一就是彻底隔离接口和实现：构造函数和析构函数，成员函数和可见度控制
复杂度的守恒：C++采取了折中办法，为了更加灵活，它付出的代价是比我们希望的更庞大－－但这就使生活
专家就是那种不仅理解你所试图掌握的东西，还能给你解释清楚的人；不能清楚的回答你提出的问题的人，并不是你所想的专家；还有人能清楚的解释事情，但却是完全错误的，幸亏这种人很少
继承是关联类型的一种方法，但迭代器不属于类型的范畴，所以这里需要的并不是继承，即使看起来是；可能我们应该称为概念继承，它和迭代器的那些需求一样，都不包含在C++语言和C++库中；相反，它们是构建C++库的概念框架的一部分（在标准库中实际上为了方便和一致，提供了几种迭代器的traits，并且有的实现采用了继承；概念检查是当前讨论的话题，boost提供了通过库来进行概念检查的试验，而对模板参数的约束则可能需要扩展语言来实现）
...
注：
个人感觉Java的成功主要是工程上的，对编程语言的理论方面作出的贡献不是很大，在编程语言发展史上的地位应该不如LISP，C语言之类，只能作为一种“类C语言”存在；工程上的成功主要决定于功能丰富的标准库，和能够快速形成应用方面的各种标准的机制；C++有意保持了标准库的基础层次，而将应用相关的库留给了开发者；造成的后果就是确实出现了很多高质量的库，然而也造成了资源的巨大巨大巨大的浪费；如果你是C++程序员，数一下你待过的公司、团队、项目中，有多少个socket封装类，多少个dao封装类就知道了
Bjarne Stroustrup一直抱怨C++的教育，认为当前的教育培养了使用C++编译器的C程序员，看到Koening实现后缀++操作符时 想到了这件事，揣测了一下原因，呵呵：
Bjarne Stroustrup（苦恼的）：为什么我做了那么多努力，人们还是把C++当成C来用？
Dennis Ritchie ：因为你把这门语言命名为了C++，而不是++C
