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

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

  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都适用