《effective c++》学习笔记（五）

尽可能延后变量定义式出现的时间

对象的声明周期需要经过构造和析构，考虑下面这份代码

void foo(bool flag) {
    string str;
    if (flag) {
        return ;
    }
    // something
}

当flag是true的时候，实际上我们浪费了一次构造string的时间，因为这个string构造了但是根本没有用到，所以我们最好将变量定义到用到它的前一刻最好。

但对于循环来说，比如这份例子

// 方案1
void foo(int n) {
    bar b;
    for (int i = 0;i < n;++i) {
        b.x = i;
        // something
    }
}

// 方案2
void foo(int n ) {
    for (int i = 0;i < n;++i) {
        bar b(i);
        // something
    }
}

方案1中，需要1次默认构造函数 + n次拷贝函数 + 1次析构函数
方案2中，需要n次拷贝构造函数 + n次析构函数

所以在遇到循环时，需要判断拷贝函数和构造 + 析构函数哪个效率更高，如果是拷贝函数效率更高那么使用方案1，如果是构造 + 析构效率更高，那么使用方案2

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

尽量少做转型动作

c++中应该尽量少做转型动作，一是为了避免降低效率，二是为了减少代码出错概率，考虑下面这份代码：

class base {
public:
    void foo() {
        // something
    }
};

class derived : public base{
public:
    void foo() {
        static_cast

(*this).foo(); // 注意这里 } };

上述代码中期望derived中的foo可以调用base中的foo，然而事实是：static_cast会生成一个临时的base对象，然后调用那个临时的base对象的foo成员，而不是调用this对象中base部分的foo成员。正确的写法应该是下面这样：

class base {
public:
    void foo() {
        // something
    }
};

class derived : public base{
public:
    void foo() {
        base::foo();
    }
};

如果可以，尽量避免转型，特别是在注重效率的代码中避免dynamic_cast。如果有个设计需要转型动作， 试着发展无需转型的替代设计 如果转型是必要的，试着将它隐藏于某个函数背后。客户随后可以调用该函数，而不需将转型放进他们自己的代码内 宁可使用c++-style转型，不要使用旧式转型。前者很容易辨识出来，而且也比较有着分门别类的职掌

避免返回handles指向对象的内部成分

考虑下面这份代码：

class foo {
public:
    int& get_x() { return x; }
private:
    int x;
};

很容易可以发现，虽然x的private级别，但可以通过get_x得到这个对象，那么实际上x的级别被提升到public级别了，这个private并没有意义。

对于成员函数，也是同样的道理

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

为“异常安全”而努力是值得的

对于一个函数的异常性，我们有三种方案

基本承诺：如果异常被抛出，程序内的任何事物仍然保持在有效状态 强烈保证：如果异常被抛出，程序状态不改变 不抛掷保证：承诺绝不抛出异常

有一个一般化的设计叫做 copy and swap。原则很简单：为你打算修改的对象复制一份副本，然后再那副本上进行修改，最后再进行一次swap。

异常安全函数即使发生异常也不会泄漏或允许任何数据结构破坏。这样的函数区分三为三种可能的保障：基本型、强烈性、不抛异常型 “强烈保证”往往能够以copy-and-swap实现出来，但“强烈保证”并非对所有函数都可实现或具备现实意义 函数提供的“异常安全保证”通常最高只等于其所调用之各个函数的“异常安全保证”中的最弱者

透彻了解inlining的里里外外

将大多数inlining限制在小型、被频繁调用的函数身上。这可使日后的调试过程和二进制升级更容易，也可使潜在的代码问题最小化，使程序的速度提升最大化 不要只因为function templates出现在头文件，就将它们声明为inline

将文件间的编译依存关系降至最低

考虑下面两份代码：

  class person  {  
    public:  
      person(const std::string& name,const date& birthday,const address& addr);  
      std::string name() const;  
      std::string birthdate() const;  
      std::string address() const;  
      ...  
    private:  
      std::string thename;  
      date thebirthdate;  
      address theaddress;  
    };  

=============================

  namespace std {  
      class string;  
    }  
    class date;  
    class address;  
    class person  {  
    public:  
      person(const std::string& name,const date& birthday,const address& addr);  
      std::string name() const;  
      std::string birthdate() const;  
      std::string address() const;  
      ...  
    };  

当date的定义改变时（接口不改变），第一份代码会重新编译，进而依赖第一份代码的文件也会重新编译，而第二份代码则不会重新编译。

所以为了避免编译依赖，可以使用一种叫做pimpl的手法，即声明和实现分开写，比如上面的代码可以定义两个类person和personpimpl，其中具体实现写在personpimpl中：

class personimpl;

class person {
public:
    string get_name();
private:
    shared_ptr _data;
};

class personimpl {
public:
    string get_name() {
        return name;
    }
private:
    string name;
};

string person::get_name() {
    return _data->get_name();
}

这样便可以将声明和定义分开。

当然也可以使用抽象基类来实现接口和实现的分离：

class person {
public:
    virtual string get_name() = 0;
    virtual ~person() {  };
};

class personimpl : public person {
public:
    string get_name() {
        return name;
    }
private:
    string name;
};

但这样要求使用的时候必须使用person的指针或引用才可以。

支持“编译依存性最小化“的一般构想是：相依与声明式，不要相依于定义式。基于此构想的两个手段是handle classes和interface classes 程序库头文件应以“完全且仅有声明式”形式存在，这种做法不论是否涉及templates都适用