Exceptional C++

（翻译的太差了）

一、语法细节

1. C++不允许修改内置类型的临时变量

2. 缺省参数根据静态类型获得

3. 重载的new和delete操作符永远都是静态的，不管你声明static没有

二、惯用法

1. 选择前置递增，只有打算使用初始值时才使用后置递增，并且使用前置递增来实现后置递增

2. 注意由隐式转换创建的隐藏临时对象；避免这个问题的好办法，是使用explicit构造函数，避免编写转换操作符

3. 永远不要#include不必要的头文件；当前置声明足够时，永远不要#include头文件

4. 明智的使用名称空间：如果将一个类放入一个名字空间内，那么一定也要将所有的辅助函数和操作符放入相同的名字空间中

5. 永远不要多态的处理数组；语言要求传递给delete[]操作符的指针类型必须与它的动态类型保持一致

6. const auto_ptr<>，对特定问题几乎完美的惯用法

三、原则

1. GLSP：泛型的Liskov替换原则：当作模板参数传递的任何类型（或模板）都应当遵守这个参数的需求

2. 需要特别注意赋值操作符的异常安全性，因为它与拷贝构造函数是不一样的

3. 优先选择内聚性，设法使每块代码（每个模块，每个类，每个函数）具有单一的，定义良好的职责；如果一块代码由于内在的设计问题而不能被编写成异常安全的，那几乎总是拙劣设计的表现，例如，带有两个不同职责的函数是难于编写成异常安全的

4. 遵守规范的异常安全性规则：（1），永远不要允许异常逃离析构函数、重载的delete()和delete[]()操作符；（2），设法使用RAII来隔离资源资源所有权和资源管理；（3），在每个函数中，将所有可能抛出异常的代码以及能够安全处理此类工作的代码单独放置到一边，只有确信实际的工作已经完成时，才使用无异常抛出的操作来修改程序的状态

5. 在什么情况下使用公有继承？我们需要公有继承来表示is-a关系，所有被改写的成员函数必须不要求更多，也不要承诺更少；永远不要为了重用基类中的代码而进行公有继承；

6. 在什么情况下使用非公有继承而不是包含？（1），我们需要改写一个虚函数；（2），我们需要访问保护成员；（3），我们需要在另一个基类子对象之前构造被使用类，或者在其之后析构被使用类；（4），我们需要共享共用的虚拟基类，或者改写虚拟基类的构造；（5），我们从空基类优化上获益匪浅；（6），我们需要“受控的多态”，但只是在某种代码中

7. 接口规则：对于一个类X，所有“提及”X和与X“一起提供”的函数（包括自由函数）逻辑上都是X的一部分，因为它们构成了X接口的一部分；成员函数与非成员函数逻辑上都可能是类的一部分，然而，成员函数仍然比非成员函数与类有更强的关系；“一起提供”的一种有用的诠释方式是“出现在相同的头文件和/或名称空间中”，如果出现在相同头文件中，那么它们在依存关系上是类的一部分，如果出现在相同名称空间中，那么它们在名字查找的意义上是类的一部分

四、实践

1. 使用自己最熟悉的技术构造产品的核心部分，在扩展部分试验自己感兴趣的新技术并从中学习

2. 记住计算机科学格言：大多数问题都可以通过增加一个间接层来解决，当然，用奥坎姆剃刀（Occam's Razor）来调和一下是明智的：不要使事情变得比必要的更复杂

五、观点

1. C++标准化工作对C++最重要的贡献是：对“强大的抽象概念”更有力的支持，以降低软件的复杂性；

2. 面向对象编程的最重要的优点：是通过管理代码之间的依存关系来降低软件的复杂性

六、问题

1. 标准库是不是没有提供定长数组的包装类？vector是不是足够用了？

2. 没有auto_array_ptr<>，或者auto_ptr对数组的特化，是不是应该始终用vector来代替动态分配内存的数组？