所谓资源就是，一旦用了它，将来必须还给系统。如果不这样，糟糕的事情就会发生。
C++程序中最常使用的资源就是动态分配内存（如果你分配内存却从来不曾归还它，会导致内存泄露），
但内存只是你必须管理的众多资源之一。
其他常见的资源还包括文件描述符（file description），互斥锁（mutex lock），图形界面中的字型和笔刷，数据库连接，以及网络socket。
不论哪一种资源，最重要的是，当你不再使用它时，必须将它还给系统。
尝试在任何运用情况下都确保以上所言，是件困难的事，但当你考虑到异常，函数内多重回传路径，程序维护员改动软件却没能充分理解随之而来的冲击，
态势就很明显了，资源管理的特殊手段还不很充分够用。
1. delete
假设我们使用一个用来塑模投资行为（例如，股票，债券等等）的程序库，
其中各式各样的投资类型继承自一个root class Investment：
// “投资类型”集成体系中的root class
class Investment { ... };
进一步假设，这个程序库通过一个工厂函数供应我们特定的Investment对象：
// 返回指针，指向Investment继承体系内的动态分配对象
// 调用者有责任删除它
Investment* createInvestment();
createInvestment的调用端，使用了函数返回的对象后，有责任删除之。
现在考虑有个f函数履行了这个责任。
void f(){
// 调用factory函数
Investment* pInv = createInvestment();
...
// 释放pInv所指对象
delete pInv;
}
这看起来妥当，但若干情况下，f可能无法删除它得自createInvestment的投资对象。
或许因为“...”区域内的一个过早的return语句，如果这样一个return被执行起来，控制流就绝不会触及delete语句。
类似情况发生在对createInvestment的使用及delete动作位于某循环内，而该循环由于某个continue或goto语句过早退出。
最后一种可能是“...”区域内的语句抛出异常，果真如此控制流将再次不会幸临delete。
无论delete如何被略过去，我们泄漏的不只是内含投资对象的那块内存，
还包括那些投资对象所保存的任何资源。
当然啦，谨慎的编写程序可以防止这一类错误，但你必须想想，
代码可能会在时间渐渐过去后被修改，一旦软件开始接受维护，可能会有某些人添加return语句或continue语句而未能全然领悟它对函数的资源管理策略造成的后果。
更糟的是f的“...”区域有可能调用一个“过去从未抛出异常，却在被‘改善’之后开始那么做”的函数，
因此单纯倚赖“f总是会执行其delete语句”是行不通的。
2. 资源管理对象
为确保createInvestment返回的资源总是被释放，我们需要将资源放进对象内，
当控制流离开f，该对象的析构函数会自动释放那些资源。
把资源放进对象内，我们便可倚赖C++的“析构函数自动调用机制”确保资源被释放。
许多资源被动态分配与heap内而后被用于单一区块或函数内，它们应该在控制流离开那个区块或函数时被释放。
标准程序库提供的auto_ptr正是针对这种形势而设计的特制产品。
auto_ptr是个“类指针（pointer-like）对象”，也就是所谓“智能指针”，其析构函数自动对其所指对象调用delete。
下面示范如何使用auto_ptr以避免f函数潜在的资源泄漏可能性：
void f(){
// 调用factory函数
std::auto_ptr<Investment> pInv(createInvestment());
// 一如既往的使用pInv
...
// 经由auto_ptr的析构函数自动删除pInv
}
实际上“以对象管理资源”的观念常被称为“资源取得时机便是初始化时机”
（Resource Acquisition Is Initialization，RAII），
因为我们几乎总是在获得一笔资源后于同一语句内以它初始化某个管理对象。
有时候获得的资源被拿来赋值（而非初始化）某个管理对象，
但不论哪一种做法，每一笔资源都在获得的同时立刻被放进管理对象中。
不论控制流如何离开区块，一旦对象被销毁（例如当对象离开作用域），其析构函数自然会被自动调用，与时资源被释放。
如果资源释放动作可能导致抛出异常，事情变得有点棘手。（见条款8 P44
3. auto_ptr和shared_ptr
由于auto_ptr被销毁时会自动删除它所指之物，所以一定要注意别让多个auto_ptr同时指向同一对象。
如果真是这样，对象会被删除一次以上，而那会使你的程序搭上“未定义行为”的快速列车上。
为了预防这个问题，auto_ptr有一个不寻常的性质，
若通过copy构造函数或copy assignment操作符复制它们，它们会变成null，而复制所得的指针将取得资源的唯一拥有权。
// pInv1指向createInvestment返回物
std::auto_ptr<Investment> pInv1(createInvestment());
// copy构造函数，现在pInv2指向对象，pInv1被设为null
std::auto_ptr<Investment> pInv2(pInv1);
// copy assignment操作符，现在pInv1指向对象，pInv2被设为null
pInv1 = pInv2 ;
这一诡异的复制行为，附加上其底层条件：“受auto_ptr管理的资源必须绝对没有一个以上的auto_ptr同时指向它”，
意味着auto_ptr并非管理动态分配资源的神兵利器。
举个例子，STL容器要求其元素发挥“正常的”复制行为，因此这些容器容不得auto_ptr。
auto_ptr的替代方案是“引用计数型智慧指针”（reference-counting smart pointer，RCSP），
所谓RCSP也是个智能指针，持续追踪共有多少对象指向某笔资源，并在无人指向它时自动删除该资源。
RCSP提供的行为类似垃圾回收，不同的是RCSP无法打破环状引用（cycles of reference），
例如，两个其实已经没被使用的对象彼此互指，因此好像还处在“被使用”状态。
TR1的tr1::shared_ptr就是个RCSP，所以你可以这么写f：
void f(){
// 调用factory函数
std::tr1::shared_ptr<Investment> pInv(createInvestment());
// 使用pInv一如既往
...
// 经由shared_ptr析构函数自动删除pInv
}
这段代码看起来几乎和使用auto_ptr的那个版本相同，但shared_ptr的复制行为正常多了。
4. delete[]
auto_ptr和tr1::shared_ptr两者都在其析构函数内做delete而不是delete[]动作。
那意味着在动态分配而得的array身上使用auto_ptr或tr1::shared_ptr是个馊主意。
尽管如此，可叹的是，那么做仍能通过编译。
// 馊主意，会用上错误的delete形式
std::auto_ptr<std::string> aps(new std::string[10]);
// 相同问题
std::tr1::shared_ptr<int> spi(new int[1024]);
你或许会惊讶的发现，并没有特别针对“C++动态分配数组”而设计的类似auto_ptr或tr1::shared_ptr那样的东西，甚至TR1中也没有。
那是因为vector和string几乎总是可以取代动态分配而得的数组。
如果你还是认为拥有针对数组而设计，类似auto_ptr和tr1::shared_ptr那样的class较好，看看Boost吧。
在那你会很高兴的发现boost::scoped_array和boost::shared_array class，它们都提供你要的行为。
