这里的handles指的是引用、指针、迭代器等可以修改对象的传递方法。
假设现在编写一个表示矩形的class，每个矩形有其左上角和右下角表示。先定义平面内的点
class Point{
public:
Point(int x, int y);
……
void setX(int newVal);
void setY(int newVal);
……
};
再定义矩形对象
struct RectData{
Point ulhc;//upper left-hand corner
point lrhc;//lower right-hand corner
};
后面定义使用的类
class Rectangle{
……
private:
std::tr1::shared<RectData> pData;
};
Rectangle客户应该知道矩形的范围，因此扎个class应该提供得到两个坐标点的函数。根据**条款**20的忠告，我们知道by reference方式传递值比by value方式效率更高，如果使用by reference方式传递
class Rectangle{
……
public:
Point& upperLeft()const{return pData->ulhc;}
Point& lowerRight()const{return pData->lrhc;}
};
这样设计，语法上没有问题。但是从逻辑上来看，upperLeft和lowerRight被声明为const成员函数，它们被设计用来给客户提供Rectangle坐标，而不是让客户修改Rectangle。但是返回的引用 的数据是private内部数据，客户可以通过引用修改内部数据。因此我们得到两个教训：
ulhc和lrhc虽然都被声明为private，但实际却是public，因为public函数upperLeft和lowerRight传出了它们的reference。如果把上面的reference换成指针、迭代器等handles，同样适用。返回对象内部数据的handle会带来降低对象封装性的风险。
我们都知道对象的“内部”是指其成员变量，其实非public成员函数（即protected和private）也是对象“内部”数据的一部分。因此要留心不要返回它们的handles。也就是说，不要让成员函数返回一个指针指向“访问级别较低”的成员函数；如果这样做，后者的访问级别会提高到与前者一致。虽然返回成员函数的指针情况不多见，但是也要注意这一点。
下面讨论怎么解决Rectangle class的成员函数upperLeft和lowerRight的问题。我们遇到的问题是客户可能会修改这两个函数的返回值，那么如果其返回值是const，那么就可以解决这个问题。
class Rectangle{
……
public:
const Point& upperLeft()const{return pData->ulhc;}
const Point& lowerRight()const{return pData->lrhc;}
};
这样一来，客户可以读取矩形Points的值，但是不能修改它们。这里，蓄意放松了封装。但是有时即使如此，还是返回了“代表对象内部”的handles，有可能在其他场合带来问题。更明确一点，是可能会 导致dangling handles（空悬的号码牌）：handles所指对象不存在。这种不复存在的对象，最常见的来源就是函数返回值。例如某个函数返回对象外框（bounding box），这个外框采用矩形形式：
class GUIObject{……}；
const Rectangle boundingBox(const GUIObject& obj);//，by value返回，条款3讨论过为什么是const
现在客户这样使用
GUIObject* pgo;
const Point* pUpperLeft=&(boundingBox(*pgo).upperLeft());//取得一个指针，指向外框左上点
调用boundingBox获得一个新的、临时的Rectangle对象，临时对象没有名字，暂且成为temp，随后upperLeft作用于temp身上，返回一个reference指向temp的一个内部成分。于是，pUpperLeft指向这个Point对象。问题出在temp是一个临时对象，当这个语句结束后，临时对象便会析构，这时pUpperLeft指向一个不再存在的对象。pUpperLeft变成空悬、虚吊（dangling）。
所以，“返回一个handle代表对象内部成分”总是危险的，不论这个handle是不是const。问题关键是：handle一旦被传出去，此handle的寿命可能比起所指对象更长。
但这并不意味着你绝对不可以让成员函数返回handle，有时候你还必须这样做。例如重载operator[]，必须返回其reference，但是要牢记，reference所指对象会随着class对象的销毁而销毁。
总结避免返回handles（reference、指针、迭代器）指向对象内部。遵守这个条款可以增加封装性，帮助const成员函数的行为像个const，并将发生“虚吊号码牌”（dangling handles)的风险降到最低。
异常安全（Exception safety）有点像怀孕，但是在完成求偶之前，实在无法确实地讨论生育安全。
假设在多线程环境中，一个class用来表现夹带背景图案的GUI菜单，它应该有个互斥量（mutex）来控制并发（concurrency control）
class PrettyMenu{
public:
……
void changeBackground(std::istream& imgSrc);//改变背景图片
……
private:
Mutex mutex; //互斥量
Image* bgImage; //当前背景图片
int imageChanges; //背景图片改变次数
};
下面是PrettyMenu的changeBackground函数的一个实现方式
void PrettyMenu::changeBackground(std::istream& imgSrc)
{
lock(&mutex);
delete bgImage;
++imageChanges;
bgImage=new Image(imgSrc);
unlock(&mutex);
}
从“异常安全性”来看，这个函数没有满足“异常安全”两个条件中的任何一个：
1.不泄露任何资源。上面，一旦在lock和unlock之间发生异常，unlock的调用就不会执行，互斥量永远被锁住了。
2.不允许数据败坏。上述代码中，如果new Image(imgSrc)抛出异常，bgImage就会指向不存在的对象，但imageChanges已经累加，其实并没有新的图像安装起来。
解决上面第一个问题比较容易，条款**13介绍过以对象管理资源的方法，条款**14页导入Lock class作为一种确保互斥量被及时释放的方法。
void PrettyMenu::changeBacground(std::istream& imgSrc)
{
Lock m(&mutex);
deelte bgImage;
++imageChanges;
bgImage=new Image(imgSrc);
}
这个实现代码更短，一个一般性的规则：较少的代码就是较好的代码，因为出错机会比较少，且一旦有所改变，被误解的机会也比较少。
在解决了资源泄露后，来看看如何解决数据败坏。首先来定义一些术语。
异常安全函数（Exception-safe functions）提供以下三个保证之一：
changeBackground如果抛出异常，PrettyMenu对象应该可以继续使用原背景图像，或令它拥有某个缺省背景图像。异常安全码（Exception-safe code）必须提供三个保证之一（本条款末尾讨论不惧异常安全的传统代码），上面三个保证依次增强，我们需要做的是应该为所写的每一个函数提供哪一种保证。当然nothrow最好，但是C part of C++领域中全部调用完全没有异常的函数不大可能。任何使用动态内存（比如STL容器），如果内存无法开辟，通常会有bad_alloc异常（**条款**49）。所以，我们的选择往往在基本保证和强烈保证之间。
对于changeBackground来说，提供强烈保证并不困难。使用智能指针，改变语句顺序即可
class PrettyMenu{
……
std::tr1::shared_ptr<Image> bgImage;
……
};
void PrettyMenu::changeBackground(std::istream& imgSrc)
{
Lock m1(&mutex);
bgImage.reset(new Image(imgSrc));//用new Image执行结果设定bgImage内部指针
++imageChanges;
}
智能指针使用reset，当new Image(imgSrc)成功后，才会删除旧图像。这些改变几乎让changeBackground提供强烈异常安全保证。美中不足的是参数imgSrc，如果Image构造函数抛出异常，有可能是输入流（input stream）的读取记号（read marker）已被移走，而这样的搬移对程序其余部分是一种可见状态的改变。所以changeBackground在解决这个问题之前只提供异常安全保证。
有个一般化的设计可以很典型的导致强烈保证，这个策略是copy and swap。原则是：为你打算改变的对象（原件）做出一份副本，然后再副本身上做一切必要修改。如果修改动作抛出异常，原对象仍保持未改变状态。当所有修改都成功后，再讲修改过的副本和原对象在一个不抛出异常的操作中置换（swap）。
在实现上，通常将所有“隶属对象的数据”从原对象放进另一个对象内，然后赋予原对象一个指针，指向那个所谓的实现对象（implementation object，即副本）。这种手法叫做pimpl idiom，**条款**31描述了它。对PrettyMenu来说，实现如下：
struct PMImpl{ //PMImpl:Pretty Menu Impl。后面说明为什么是struct
std::tr1::shared_ptr<Image> bgImage;
int imageChanges;
};
class PrettyMenu{
……
private:
Mutex mutex;
std::tr1::shared_ptr<PMImpl> pImpl;
};
void PrettyMenu::changeBackground(std::istream& imgSrc)
{
using std::swap;//**条款**25
Lock m1(&mutex);
std::tr1::shared_ptr<PMImpl> pNew(new PMImpl(*pImpl));
pNew->bgImage.reset(new Image(imgSrc));;//修改副本
++pNew->imageChanges;
swap(pImpl,pNew);
}
上面代码中，PMImpl是一个struct，而不是class，因为PrettyMenu的数据封装性已经有“pImpl是private”而获得保证。当然如果PMImpl是class，虽然一样好，但是有时却不太方便（但也保持了对象纯度）。也可以将PMImpl嵌套于PrettyMenu内，但打包问题（packaging，例如独立撰写异常安全码）是这里所考虑的事。
虽然“copy-and-swap”的策略是改变对象全有或全无的一个好办法，但一般而言，它并不保证整个函数有强烈的异常安全。为了原因，把changeBackground换成一个抽象概念：someFunc
void someFunc()
{
……;//对local状态做备份
f1();//
f2();
……//将修改后的状态置换过来
}
很显然，这个函数的异常安全性和函数f1、f2有关。如果它们异常安全性更低，那么会拉低someFunc()的异常安全性。例如，如果f1只提供基本保证，为了让someFunc提供强烈保证，我们必须写代码获得调用f1之前的整个程序状态、捕捉f1所有可能异常、然后恢复状态。
即使f1和f2都是强烈异常安全，情况也不会好转。如果f1圆满结束，程序状态在任何方面都有可能有所改变；如果f2随后抛出异常，程序状态和someFunc被调用之前也并不相同，甚至当f2没有改变任何东西时也是如此。
这个问题的原因是“连带影响”（side effects）。函数对“非局部性数据”（non-local data）有连带影响时，就很难提供强烈保证。例如当f1函数修改了数据库，那么其他客户就能看到这一笔修改了，很难再提供强烈保证了。
既然强烈保证有这么多麻烦，或许你不再想为函数提供强烈保证了。还有一个理由支持你这个想法，那就是效率。copy-and-swap的关键在于“修改对象数据的副本，然后在一个不抛出异常的函数中将修改后的数据和原数据置换”，这需要耗费新建数据副本的空间以及时间。因此从效率上来看，“强烈保证”未必显得那么实际。
为实际考虑，有时放弃“强烈保证”，可以退而求其次的追求“基本保证”。对于许多函数来说，“异常安全性之基本保证”是一个比较适当的选择。
加入我们写的函数不提供异常安全，那么他人又可以假设我们在这方面有缺失，除非我们证明自己。我们应该写出异常安全的代码，但有时我们也可以有理由不这么做。例如someFunc函数中调用f1和f2,如果其中一个没有提供异常安全保证，甚至没有提供最基本的异常安全，那么someFunc是无法补偿这些问题的。因为someFunc调用函数没有提供任何异常安全保证，someFunc自身也不可能提供任何保证。
一个系统要么具备异常安全性，要么不具备，没有“局部异常安全系统”。许多老旧C++代码不具备异常安全性，所以今天 许多系统仍然不是异常安全的，因为它们使用了一些非异常安全的代码。
因此当我们编写或修改代码时，应该考虑如何让它具备异常安全性。首先是“以对象管理资源”（**条款**13），组织那些可能泄露的资源。然后挑选三个“异常安全保证”中的一个实施到我们所编写的每一个函数身上（以“现实可操作条件”为最强烈等级）。如果我们调用非异常安全代码，那么我们就别无选择了，只能将它设为“无任何保证”。将我们做的选择写成文档，为了给客户看，以及为了将来的维护代码。函数的“异常安全性保证”是其可见接口的一部分，我们应该慎重选择。
goto代码以前被视为美好的时间，如今我们却致力写出结构化控制流（structured control flows）；以前全局数据结构（globally accessible data）被视为美好的实践，如今我们却致力于数据封装。以前我们没考虑过异常安全，如今我们却致力于写出异常安全代码。时间在前进，我们与时俱进。
总结
原文地址：http://blog.csdn.net/kangroger/article/details/43883305
