---- 尽可能延后变量定义式的出现。这样做可增加程序的清晰度并改善程序效率。
27、尽量少做转型动作C++规则的设计目标之一是，保证“类型错误”绝不可能发生。理论上如果你的程序很“干净地”通过编译，就表示它并不企图在任何对象上执行任何不安全、无意义、愚蠢荒谬的操作。这是一个极具价值的保证，可别草率的放弃它。
C++ 提供了四种新式转型
const_cast
dynamic_cast
reinterpret_cast
static_cast
各有不同的目的：
const_cast通常被用来将对象的常量性转除。它也是唯一有此能力的C++-style转型操作符
dynamic_cast主要用来执行“安全向下转型”，也就是用来决定某对象是否归属继承体系中的某个类型。它是唯一无法由旧式语法执行的动作，也是唯一可能耗费重大运行成本的转型动作。
reinterpret_cast意图执行低级转型，实际动作（及结果）可能取决于编译器，这也就表示它不可移植。例如将一个pointer to int 转型成一个int。这一类转型在低级代码以外很少见。
static_cast用来强迫隐式转换，例如将non-const对象转为const对象，或将int转为double等等。它也可以用来执行上述多种转换的反向转换，例如将void*指针转为typed指针，将pointer-to-base转为pointer-to-derived。但它无法将const转为non-const-------这个只有cosnt_cast才能办到。
之所以需要dynamic_cast，通常是因为你想在一个你认定为derived class对象身上执行derived class 操作函数，但你的手上却只有一个“指向base”的pointer或reference，你只能靠它们来处理对象。有两个一般性做法可以避免这个问题。
第一、使用容器并在其中存储直接指向derived class 对象的指针（通常是只能指针），如此便消除了“通过base class”接口处理对象的需要。----这种没有办法存储继承体系的所有derived class 指针
第二、就是在base class内提供virtual函数做你想对各个window派生类做的事。这种做法就可以让你通过base class接口处理“所有可能之各种window派生类”
---- 如果可以，尽量避免转型，特别是在注重效率的代码中避免dynamic_cast。如果有个设计需要转型动作，试着发展无需转型的替代设计。
---- 如果转型是必要的，试着将它隐藏于某个函数背后。客户随后可以调用该函数而不需将转型放进它们自己的代码内。
---- 宁可使用C++-style转型，不要使用旧式转型。前者很容易辨识出来，而且也比较有着分门别类的职掌。
28、避免返回handles指向对象内部成分---- 避免返回handles(包括references、指针、迭代器)指向对象内部。遵守这个条款可增加封装性，帮助const成员函数的行为像个const，并将发生“虚吊号码牌”的可能性降至最低。
29、为“异常安全”而努力是值得的当异常被抛出时，带有异常安全性的函数会：
1、源不泄露任何资
2、不允许破坏数据
异常安全函数提供以下三个保证之一：
1、基本承诺：如果异常被抛出，程序内的任何事物仍然保持在有效状态下。
2、强烈保证：如果异常被抛出，程序状态不改变。
3、不抛掷保证，承诺绝不抛出异常，因为它们总是能够完成它们原先承诺的功能。
---- 异常安全函数即使发生异常也不会泄漏资源或允许任何数据结构破坏。这样的函数区分为三种可能的保证：基本型、强烈型、不抛异常型。
---- “强烈保证”往往能够以copy-and-swap实现出来，但“强烈保证”并非对所有函数都可实现或具备现实意义。
---- 函数提供的“异常安全保证” 通常最高只等于其所调用之各个函数的“异常安全保证”中的最弱者。
30、透彻了解inlining的里里外外---- 将大多数inlining限制在小型、被频繁调用的函数身上。这可使日后的调试过程和二进制升级更容易，也可使潜在的代码膨胀问题最小化，使程序的速度提升机会最大化
---- 不要只因为function templates 出现在头文件，就将它们声明为inline
31、将文件间的编译依存关系降至最低---- 支持“编译依存性最小化”的一般构想是：依赖声明式，不要依赖定义式。基于此构想的两个手段是Handle classes 和 Interface classes
---- 程序库头文件应该以“完全且仅有声明式”的形式存在。这种做法不论是否设计templates 都适用。
