【读书笔记】Effective C++（05）实现

作者：LogM

本文原载于 https://segmentfault.com/u/logm/articles，不允许转载~

5. 实现

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

  • std::string encryptPassword(const std::string& password) {
        using namespace std;
        string encrypted;   //bad，过早定义，如果下一句出异常，这个变量其实没有用到，导致无谓的构造和析构
        if (password.length() < MinimumPasswordLength) {
            throw logic_error("Password is too short");
        }
        ...   //加密过程
        return encrypted;
    }
    
    std::string encryptPassword(const std::string& password) {
        using namespace std;
        if (password.length() < MinimumPasswordLength) {
            throw logic_error("Password is too short");
        }
    
        string encrypted;   //ok，要用到时再定义
        ...  //加密过程
        return encrypted;
    }

  • //循环内的变量怎么定义？
    
    //方法A：定义于循环外
    Widget w;
    for (int i=0; i<n; ++i) {
        w = ...;
        ...
    }
    
    //方法B：定义于循环内
    for (int i=0; i<n; ++i) {
        Widget w(...);
        ...
    }
    
    //方法A：1个构造函数、1个析构函数、n个赋值操作，变量w作用域覆盖到循环以外
    //方法B：n个构造函数、n个析构函数，变量w作用域仅在循环内
    //具体使用哪个视情况而定。
    
    //我自己想了一个非常小众的写法，虽然可以兼得方法A和方法B的长处，但是代码可读性降低
    for (int i=0, Widget w; i<n; ++i) {
        w = ...;
        ...
    }

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

  • C++的新式转型：

    • a. const_cast<...>(...)。移除对象的常量性。
    • b. dynamic_cast<...>(...)。在继承体系中进行安全的向下转型，效率低。
    • c. reinterpret_cast<...>(...)。低级转型，结果取决于编译器，不可移植。
    • d. static_cast<...>(...)。强迫执行隐式转换，类似于C中的旧式转换。
  • 作者提醒，只有明确知道转型后的结果是什么时才使用转型，自以为是地猜测转型的结果往往导致错误。

• 5.3 条款28：避免返回值是指向 private 成员变量的引用或者指针

  • 很容易理解，如果成员函数返回值是指向 private 成员变量的引用或者指针，那么成员变量的 private 不再具有意义，它实际能被修改。
  • 解决方法是将返回的引用或指针设为const类型，禁止修改。
  • 有些特殊情况下，返回的引用或指针指向的成员变量被销毁，导致引用和指针无效（dangling handles），这种情况要在代码中避免。

• 5.4 条款29：保证"异常安全"

  • 异常安全的函数，即使在发生异常的时候也能保证不泄漏资源不破坏数据结构，可以分为三种：

    • a. 基本型：保证资源不泄露，保证数据结构不破坏，但异常发生后程序中的对象的状态是未知的；
    • b. 强烈型：在基本型的基础上，保证如果出现异常，程序中的对象的状态会回复到"调用该函数前"的状态；
    • c. 不抛异常型：承诺所有异常都能被处理，不抛出异常。
  • 实际使用时，要综合考虑效率和安全性来确定使用哪一种类型的异常安全。

• 5.4 条款30：透彻理解inline函数

  • inline函数：编译器用inline函数的本体代码替换程序中的每一次调用。因此，滥用inline函数将导致程序体积过大，进而降低高速缓存命中率等导致效率降低。
  • inline函数的实现应该写在.h头文件中，因为大多数编译器是在编译期处理inline函数的。（与template类似，template的声明和实现也应该放在头文件中，但这不意味着template就一定是inline）
  • virtual函数不能使用inline，因为virtual是运行期才能确定的。
  • inline的缺点：a. inline函数无法随着程序库的升级而升级，必须重新编译；b. inline函数的调试很麻烦。
  • 什么时候用inline：当整个程序的大量运行时间耗费在某段代码的调用过程上时。
  • 即使你写成inline函数，编译器也有权力不编译为inline形式。

• 5.5 条款31：将文件间的编译依存关系降到最低

  • 原因：当改动一个文件后，不需要整个工程都重新编译。
  • 常见的"把类的定义和声明放在两个文件中"，就是减少编译依存关系的一个例子。