Effective C++之实现

5 实现

条款26：尽可能延后变量定义式的出现时间。

请记住：

尽可能延后变量定义式的出现。这样做可增加程序的清晰度并改善程序效率。

除非（1）你知道赋值成本比“构造+析构”成本低，（2）你正在处理代码中效率高度敏感的部分，否则你应该使用做法B。

条款27：尽量少做转型动作。

C++提供四种新式转型：

n  const_cast<T>()通常被用来将对象的常量性转除。

n  dynamic_cast<T>()主要用来指向“安全向下转型”，也就是用来决定某对象是否归属继承体系当中的某个类型。

n  reinterpret_cast<T>()意图指向低级转型，实际动作（及结果）可能取决于编译器，这也就表示它不可移植。例如讲一个int指针转型为一个int。

n  static_cast<T>()用来强迫隐式转换，例如将non-const对象转为const对象，或将int转为double等等。、

请记住：

n  如果可以，尽量避免转型，特别是在注重效率的代码中避免dynamic_casts。如果有个设计需要转型动作，试着发展无需转型的替代设计。

n  如果转型是必要的，试着将它隐藏于某个函数背后。客户随后可以调用该函数，而不需将转型放进他们自己的代码内。

n  宁可使用C++新式转型，不要使用旧式转型，前者很容易辨识出来，而且也有着分分门别类的职掌。

条款28：避免返回handles指向对象内部成分。

避免返回handles（包括references、指针、迭代器）指向对象内部。遵守这个条款可增加封装性，帮助const成员函数的行为像个const，并将“虚吊号码牌”的可能性降至最低。

条款29：为“异常安全”而努力是值得的。

异常安全函数提供以下三个保证之一：

基本承诺：如果异常被抛出，程序内的任何事物任然保持在有效状态下。

强烈保证：如果异常抛出，程序状态不改变。调用这样的函数需要有这样的认知：如果函数成功，就是完全成功，如果函数失败，程序回复到“调用函数之前”的状态。

不掷抛保证：承诺绝不抛出异常，因为它们总是能够完成它们原先承诺的功能。

假设有个class：

从异常安全性的观点来看，这个函数很糟。当异常被抛出时，带有异常安全性的函数会：

不泄露任何资源。上述代码没有做到这一点，因为一旦“new Image(imaSrc)”导致异常，

对unlock的调用就绝不会执行，于是互斥器就永远把持住。

不允许数据败坏。如果newImage(imgSrc)抛出异常，bgImage就是指向一个已被删除的

对象，而imageChanges也被累加了。

根据异常安全性，提供强烈保证，修改上述代码段

请记住：

异常安全函数即使发生异常也不会泄露资源或允许任何数据结构败坏。这样的函数区分

为三种可能的保证：基本型、强烈型、不抛异常型。

“强烈保证”往往能够以copy-and-swap实现出来，但“强烈保证”并非对所有函数都

可实现或具备现实意义。

函数提供的“异常安全保证”通常最高只等于其所调用之各个函数的“异常安全保证”

中的最弱者。

条款30：彻底了解inlining的里里外外。

Inline函数，调用它们不需蒙受函数调用所招致的额外开销。但是它会造成代码膨胀。

编译器通常不对“通过函数指针而进行的调用”实施inlining，这意味对inline函数的

有可能被inlined，也可能不被inlined,取决于该调用的实施方式：

请记住：

将大多数inlining限制在小型、被频繁调用的函数身上。

不要因为funcuiontemplate出现在头文件，就将它们声明为inline。

条款31：将文件间的编译依存关系降至最低。

person定义文件和其含入文件之间会形成编译依存关系。如果这些头文件中有任何一个

被改变，或这些头文件所依赖的其他头文件有任何改变，那么每一个含人person class的文件就得重新编译，任何使用Person class的文件也必须重新编译。

请记住：

n  支持“编译依存性最小化”的一般构想是：相依于声明式，不要相依于定义式。基于此构想的两个手段是Handle classes和Interface classes。

n  程序库头文件应该以“完全且仅有声明式”的形式存在。