条款一十三：以对象管理资源
1.把资源放进对象内，我们便可依赖C++的“析构函数自动调用机制“确保资源被释放。
2.auto_ptr是个”类指针对象“，也就是所谓”智能指针“，其析构函数自动对其所指对象调用delete。
void f() { std::auto_ptr<Investment>pInv(createInvestment());//调用factory函数使用pInv经由auto_ptr的析构函数自动删除pInv ... }
获得资源后立即放进资源管理对象内。管理对象运用析构函数确保资源被释放。
3.由于auto_ptr被销毁时会自动删除它所指之物，所以一定要注意别让多个auto_ptr同时指向同一对象。
4.两个常被使用的RAII class分别是trl::shared_ptr和auto_ptr。前者通常是较佳选择，因为其copy行为比较直观。若选择auto_ptr，复制动作会使它（被复制物）指向null。
条款一十四：在资源管理类中小心coping行为。
条款一十五：在资源管理类中提供对原始资源的访问。
class Font { public: ... FontHandle get() const {return f:} //显示转换函数 ... }; class Font { public: ... operator FontHandle() const //隐式转换函数 {return f;} }
条款一十六：成对使用new和delete时要采取相同形式
1.如果你在new表达式中使用[]，必须在相应的delete表达式中也使用[].如果你在new表达式中不使用[]，一定不要在相应的delete表达式中使用[]。
条款一十七：一独立语句将newd对象置入智能指针
1.以独立语句将newd对象存储于智能指针室内。如果不这样做，一旦异常被抛出，有可能导致难以察觉的资源泄漏。
条款一十八：让接口容易被正确使用，不易被误用
条款一十九：设计class犹如设计type
2.需要考虑对象如何被创建和销毁；对象的初始化和赋值该有什么样的差别；对象如何被pass by value；什么是对象的合法值；你的新类型是否具有一般化。
条款二十： 宁以pas-by-reference-to-const 替换pass-by-value
1.缺省情况下C++以by value方式（一个继承自c的方式）传递对象至函数。
2.尽量以pas-by-reference-to-const 替换pass-by-value。前者通常比较高效，并可避免切割问题。
3.切割问题：当一个derived class对象以by value 方式传递并被视为一个base class对象，base class的copy 构造函数会被调用，而”造成此对象的行为像个的derived class 对象“的那些特性化性质全被切割掉了，仅仅留下一个base class对象。
4.以上规则并不适用于内置类型，以及STL的迭代器和函数对象。对它们而言，pass-by-value往往比较适当。
条款二十一：必须返回对象时，别妄想返回其reference
1.绝不要返回point或reference指向一个local stack对象，或返回reference一个heap-allocated对象，或返回point或reference指向一个local static对象而有可能同时需要多个这样的对象。
条款二十二： 将成员变量声明为private
条款二十三：宁以non-member、non-friend替换member函数
1.这样做可以增加封装性，包裹弹性和机能扩充性。
条款二十四：若所有参数皆需类型转换，请为此采用non-member函数
1.如果你需要为某个函数的所有参数（包括被this指针所指的那个隐喻参数）进行类型转换，那么这个函数必须是个non-member。
条款二十五:考虑写出一个不抛异常的swap函数
条款二十六：尽可能的延后变量定义式的出现时间
//方法A：定义循环外 widget w; for(int i=0;i<n;++i) { w=取决于i的某个值； .... } //方法B：定义于循环内 for(int i=0;i<n;++i) { widget w(取决于i的某个值）; .... }
1.做法A：1个构造函数+1个析构函数+n个赋值操作
做法B:n个构造函数+n个析构函数
2.尽可能延后变量定义式的出现。这样做可增加程序的清晰度并改善程序效率。
条款二十七：尽量少做转型动作
条款二十八：避免返回handles指向对象内部成分
条款二十九：为”异常安全“而努力是值得的
1.当异常被抛出时，带有异常安全的函数应当：不泄漏任何资源；不允许数据败坏。
2.异常安全函数提供一下三个保证之一：
1）基本承诺：如果异常被抛出，程序内的任何事物仍然保持有效状态下。
2）强烈保证：如果异常被抛出，程序状态不改变。
3）不抛掷保证：承诺绝不抛出异常，因为它们总是能够完成它们原先承诺的功能。
3.函数提供的“异常安全保证”通常最高只等于其所调用各个函数的“异常安全保证”中的最弱者。
条款三十：透彻了解inlining的里里外外
1.inline函数背后的整体观念是，将“对此函数的每一个调用”都以函数本体替换之。这样就可能增加目标码的大小。
2.inline只是对编译器的一个申请，不是强制命令。这项申请可以隐喻提出，也可以明确提出。隐喻方式是将函数定义于class定义式内。而明确声明inline函数的做法则是在其定义式前面加上关键字inline。
3.将大多数inlining限制在小型、被频繁调用的函数身上。
条款三十一：将文件间的编译依存关系降至最低