资源：动态分配的内存、文件描写叙述器、相互排斥锁、图形界面中的字型与笔刷、数据库连接以及网络sockets等，不管哪一种资源，重要的是，当你不再使用它时，必须将它还给系统。
条款13：以对象管理资源
当我们向系统申请资源后，一定要记得释放，不然就easy发生内存泄漏。可是意识到这样一件事并非非常easy，比方我们是通过一个函数来动态分配内存并返回一个指针。
Investment* ceateInvestment();// 返回指针，指向动态分配对象 void f() { Investment* pInv = ceateInvestment(); // ... delete pInv; }
即使像上面的代码一样，我们在用完指针pInv后，我们调用了delete，可是还是可能出问题，有时候我们可能在...的部分提前return或跳出了循环，甚至在该部分发生了异常，这都导致delete根本运行不到。
解决方法是我们把指针放在一个资源管理的类里，让类对象在生命结束的时候，会自己主动调用析构函数，而析构函数里会运行delete。
两个常被使用的RAII类各自是：shared_ptr和unique_ptr,它们间不同的是shared_ptr同意存在同一内存区域的多个指针拷贝，而unique_ptr仅仅同意一份指针指向对象，当uniuqe_ptr发生赋值操作时，用于赋值的指针将会变成null。
条款14：在资源管理类中小心copying行为
在实际管理资源时，并不是全部的资源都是堆内存（heap），所以unique_ptr或shared_ptr这种智能指针往往不适合作为资源管理者。
比方你须要控制类型为Mtux的相互排斥器对象，共同拥有lock和unlock两函数可用，你须要保证的就是不要忘记将一个被锁住的Mutex解锁，我们的想法的主旨就是：资源在构造期间创建，在析构期间释放。
class Lock { public: explicit Lock(Mutex* pm) :mutexPtr(pm){ lock(mutexPtr;) }// 获得资源 ~Lock(){ unlock(mutexPtr); }// 释放资源 };
这样尽管非常好，可是假设Lock被复制了，就会发生故障。它可能会引起对了一Mutex解锁两次。
常见的解决方式有2种：一种是禁止复制；另外一种是对底层资源祭出“引用计数法”，这也是shared_ptr实现原理。
条款15：在资源管理类中提供对原始资源的訪问
非常多API接口往往要求訪问原始资源，所以每个RAII class应该提供一个“取得其所管理之资源”的办法，比方提供一个get函数。
对原始资源的訪问可能经由显式转换或隐式转换。一般而言显式转换比較安全，但隐式转换对客户比較方便。
条款16：成对使用new和delete时要採用同样形式
假设你在new表达式中使用[]，必须在对应的delete表达式中使用[]。假设你在new表达式中不使用[],一定不要在对应的delete表达式中使用[]。
string* stringPtr1 = new string; string* stringPtr2 = new string[100]; delete stringPtr1; // 删除一个对象 delete[] stringPtr2; // 删除一个由对象组成的数组
条款17：以独立语句将newed对象置入智能指针
如果我们有个函数用来控制程序的优先权，还有一个函数用来在某个动态分配所得到的Wieget上进行某些带有优先权的处理：
int priority(); void processWidget(shared_ptr<Widget>pw, int priority);
如今假如我们这样调用它：
processWidget(share_ptr<Widget>(new Widget),priotrity());
在调用processWidget之前，编译器必须创建代码，做下面三件事：
- 调用priority
- 运行”new Widget”
- 调用shared_ptr构造函数
C++编译器并不保证上次代码运行的次序，但有一点能够保证，那就是new Widget肯定发生成share_ptr构造函数之前。
假如priority发生在第二步，而且运行过程中发生了异常，那就有可能资源不能正常的释放。
避免这样的情况，就须要使用分离语句，先创建Widget，然后再将它置入一个智能指针内，然后再把那个智能指针传给processWidget。