条款29:为“异常安全”而努力是值得的

资源、数据、状态

http://blog.csdn.net/u013540854/article/details/30721675

结论1:异常安全函数即使发生异常也不会泄漏资源或允许任何数据结构败坏。这样的函数区分为三种可能的保证:基本型、强烈型、不抛异常型。

"异常安全“有两个条件:不泄漏任何资源和不允许数据败坏。解决资源泄漏问题可用对象管理资源。对于数据败坏,异常安全函数提供三个保证:

基本承诺:如果异常被抛出,程序内的任何事物仍然保持在有效状态下。没有任何对象或数据结构会因此而败坏,所有对象都处于一种内部前后一致的状态。然而程序的现实状态(exact state)恐怕不可预料,程序有可能处于任何状态,只要那是个合法状态。

强烈保证:如果异常被抛出,程序状态不改变。调用这样的函数需有这样的认知:如果函数成功,就是完全成功,如果函数失败,程序会回复到”调用函数之前“的状态。

不抛掷保证:承诺绝不抛出异常,因为它们总是能够完成它们原先承诺的功能。作用于内置类型身上的所有操作都提供不抛掷保证。

结论2:”强烈保证“往往能够以copy-and-swap实现出来,但“强烈保证”并非对所有函数都可实现或具备现实意义。

copy-and-swap原则很简单:为打算修改的对象(原件)做一份副本,然后在那副本身上做一切必要修改。若有任何修改动作抛出异常,原对象仍保持未改变状态。待所有改变都成功后,再将修改过的那个副本和原对象在一个不抛出异常的操作中置换。

实际上通常将所有“隶属对象的数据”从原对象放进另一个对象内,然后赋予原对象一个指针,指向那个所谓的实现对象(即副本)。这种手法被称为pimpl idiom。

如果函数只操作局部状态,便相对容易提供强烈保证。但当函数对“非局部数据”有连带影响时,提供强烈保证就困难得多。另一个在提供强烈保证时需要考虑的主题是效率。当“强烈保证”不切实际时,就必须提供“基本保证"。

结论3:函数提供的“异常安全保证”通常最高只等于其所调用之各个函数的“异常安全保证”中的最弱者。

时间: 2024-10-07 05:31:22

条款29:为“异常安全”而努力是值得的的相关文章

Effective C++ Item 29 为”异常安全”而努力是值得的

本文为senlie原创,转载请保留此地址:http://blog.csdn.net/zhengsenlie 经验:异常安全函数即使发生异常也不会泄漏资源或允许任何数据结构败坏.这样的函数区分为三种 可能的保证: 基本型-->发生异常,程序处于某个合法状态 强烈型-->发生异常,程序处于原先状态 不抛异常型-->承诺绝不抛出殿堂 示例: class PrettyMenu{ public: //... void changeBackground(std::istream &imgSr

Effective C++:条款29:为“异常安全”而努力是值得的

(一)先看下面这些代码: class PrettyMenu { public: void changeBackground(istream& imgSrc); private: Mutex mutex; //由于这个class希望用于多线程环境,所以它有这个互斥器作为并发控制之用 Image* bgImage; //目前的背景图像 int imageChanges; //背景图像被改变的次数 }; void PrettyMenu::changeBackground(std::istream &am

Effective C++ -----条款29:为“异常安全”而努力是值得的

异常安全函数(Exception-safe functions)即使发生异常也不会泄露资源或允许任何数据结构败坏.这样的函数区分为三种可能的保证:基本型.强烈型.不抛异常型. “强烈保证”往往能够以copy-and-swap实现出来,但“强烈保证”并非对所有函数都可实现或具备现实意义. 函数提供的“异常安全保证”通常最高只等于其所调用之各个函数的“异常安全保证”中的最弱者.

[Effective C++ --029]为“异常安全”而努力是值得的

假设有个class用来表现夹带背景图案的GUI菜单单,这个class用于多线程环境,所以它有个互斥器(mutex)作为并发控制用: 1 class PrettyMenu{ 2 public: 3 ... 4 void changeBackground(std::istream& imgSrc); 5 ... 6 private: 7 Mutex mutex; 8 Image* bgImage; 9 int imageChanges; 10 }; 11 void PrettyMenu::chang

Effective C++(Third Edition) Item29 为“异常安全”而努力是值得的

“异常安全”有两个条件: 1.不泄露任何资源 可以通过以对象管理资源的方式(Item13). 2.不允许数据败坏 异常安全函数提供以下三种保证之一 a.基本承诺 如果异常被抛出,程序内的任何事物都仍然保持在有效状态下,但是何种状态未知. b.强烈保证 如果异常被抛出,程序状态不改变. c .不抛掷(nothrow)保证 注意:不要为了表示某件事情发生而改变对象状态,除非那件事情真的发生了. copy and swap策略. 总结:异常安全函数即使发生异常也不会泄漏资源或允许任何数据结构败坏,这样

《Effective C++》学习笔记——条款29

***************************************转载请注明出处:http://blog.csdn.net/lttree******************************************** 五.Implementations Rule 29:Strive for exception-safe code 规则 29:为"异常安全"而努力是值得的 一.一个例子来引发这个规则 假设有个 class 用来表现夹带背景图案的GUI菜单.这个 cla

条款29: 避免返回内部数据的句柄

假设b是一个const string对象: class string { public: string(const char *value); // 具体实现参见条款11 ~string(); // 构造函数的注解参见条款m5 operator char *() const; // 转换string -> char*; // 参见条款m5 ... private: char *data; }; const string b("hello world"); // b是一个const

More Effective C++ 条款11 禁止异常流出destructor之外

1. ”两种情况下destructor会被调用.第一种情况是当对象在正常情况下被销毁,也就是当它离开了它的生存空间或是被明确的删除:第二种情况是当对象被exception处理机制——也就是exception传播过程中的stack-unwinding(栈展开)机制——销毁.” 2. 当destructor被调用时,可能(也可能不)有一个exception正在作用之中,但我们无法再destructor中区分这些状态(现在有了区分的办法.1995年7月 IOS/ANSI C++ 标准委员会加入一个新函

《Effective C++》:条款28-条款29

条款28避免返回handles指向对象内部成分 条款29为异常安全而努力是值得的 条款28:避免返回handles指向对象内部成分 这里的handles指的是引用.指针.迭代器等可以修改对象的传递方法. 假设现在编写一个表示矩形的class,每个矩形有其左上角和右下角表示.先定义平面内的点 class Point{ public: Point(int x, int y); -- void setX(int newVal); void setY(int newVal); -- }; 再定义矩形对象