作者: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:将文件间的编译依存关系降到最低

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

本文固定链接: http://www.js-code.com/cpp/cpp_58732.html