effective C++ 条款26 to 条款31
2010-11-20 20:39
218 查看
这个几个条款都在讲实现中的细节问题
条款26:尽可能延后变量定义式的出现时间
核心思想:变量一旦定义了,就要有用。
书上讲了三个例子,一个说,一旦异常被抛出,前面定义的变量就没有使用,第二个是说,不要先用默认构造函数定义一个变量,然后再赋值,而是一开始就直接调用cop构造函数给予初值。第三个是是不是应该在循环中定义变量,还是将变量定义在循环为,然后循环中用赋值。(第3点有点小夸张,呵呵)
总结出:不知应该延后变量的定义,直到非得使用该变量那一刻为止,甚至应该尝试延后这份定义直到能够给它初值实参为止。这样,不仅能避免构造和析构不必要的对象,还能避免无意义的default构造行为。
条款27:尽量少做转型动作
核心思想:
1、尽量用C++的转型,好处有,可以很方便的看出来,而且分门别类进行转型可以将转型动作变窄
2、如果能不用就尽量不要用dynamic_cast,效率低,而且容易错。
条款28:避免返回handles指向对象内部成分
其实这个条款有点夸张了,如果以后忘了再看看吧,就不多写了,那个“虚吊号码牌”的概念倒是第一次听说
有一个概念就是const函数最好返回const对象,这点倒是比较有用。
条款29:异常安全
异常安全性的函数有两个保证:
1、不泄露任何资源
2、不允许数据破坏
我们看下面的代码:
{
lock(&mutex) ;
delete bgImage ;
++imageChanged ;
bgImage = new Image(imgSrc) ;
unlock(&mutex) ;
}
从上面两个保证来看,这个代码什么都没的
一旦new语句出错,mutex永远不会被释放,有资源泄漏(违反1),并且imageChanged已经被更改了,数据被破坏(违反2)
异常安全函数提供以下三个保证之一(意思是,已经是异常安全,满足上面两个条件,在这个基础上再谈问题)
1、基本承诺:异常被抛出,程序内仍然保持有效状态(说白了就是满足上面两个条件)
2、强烈保证:异常回到以前的状态(要么成功,要么回到解放前)
3、不抛掷异常
一般,强烈保证比较常用,我们可以使用copy and swap技术:为你打算修改的对象做出一个副本,然后在副本中做所有的修改,如果这个过程中有任何异常被抛出,那么回到以前的状态(因为这个时候原始对象没有被真正改动),待所有改变成功以后,调用swap函数将副本和原对象进行调换(因为copy and swap技术告诉我们,swap函数是不会抛异常的),所以,这个时候我们也能理解了条款25说,swap函数成为异常安全编程的脊柱。
大师用怀孕来比喻异常安全代码,就是说,代码要么是一场安全的,要么就不具备异常安全,没有部分异常安全这么一说
函数提供的“异常安全保证”通常最高只等于其所调用之各个函数的“异常安全保证”中的最弱者
条款30:inline
1、将大多数inlining限制在小型,被频繁调用的函数身上,这可使日后的调试过程和二进制升级更加容易,也可使潜在的代码通胀问题最小化,使程序的速度提升机会最大化
2、不要只因为function template出现在头文件,就将它们声明为inline
条款31:不是非常理解,不敢乱写
条款26:尽可能延后变量定义式的出现时间
核心思想:变量一旦定义了,就要有用。
书上讲了三个例子,一个说,一旦异常被抛出,前面定义的变量就没有使用,第二个是说,不要先用默认构造函数定义一个变量,然后再赋值,而是一开始就直接调用cop构造函数给予初值。第三个是是不是应该在循环中定义变量,还是将变量定义在循环为,然后循环中用赋值。(第3点有点小夸张,呵呵)
总结出:不知应该延后变量的定义,直到非得使用该变量那一刻为止,甚至应该尝试延后这份定义直到能够给它初值实参为止。这样,不仅能避免构造和析构不必要的对象,还能避免无意义的default构造行为。
条款27:尽量少做转型动作
核心思想:
1、尽量用C++的转型,好处有,可以很方便的看出来,而且分门别类进行转型可以将转型动作变窄
2、如果能不用就尽量不要用dynamic_cast,效率低,而且容易错。
条款28:避免返回handles指向对象内部成分
其实这个条款有点夸张了,如果以后忘了再看看吧,就不多写了,那个“虚吊号码牌”的概念倒是第一次听说
有一个概念就是const函数最好返回const对象,这点倒是比较有用。
条款29:异常安全
异常安全性的函数有两个保证:
1、不泄露任何资源
2、不允许数据破坏
我们看下面的代码:
{
lock(&mutex) ;
delete bgImage ;
++imageChanged ;
bgImage = new Image(imgSrc) ;
unlock(&mutex) ;
}
从上面两个保证来看,这个代码什么都没的
一旦new语句出错,mutex永远不会被释放,有资源泄漏(违反1),并且imageChanged已经被更改了,数据被破坏(违反2)
异常安全函数提供以下三个保证之一(意思是,已经是异常安全,满足上面两个条件,在这个基础上再谈问题)
1、基本承诺:异常被抛出,程序内仍然保持有效状态(说白了就是满足上面两个条件)
2、强烈保证:异常回到以前的状态(要么成功,要么回到解放前)
3、不抛掷异常
一般,强烈保证比较常用,我们可以使用copy and swap技术:为你打算修改的对象做出一个副本,然后在副本中做所有的修改,如果这个过程中有任何异常被抛出,那么回到以前的状态(因为这个时候原始对象没有被真正改动),待所有改变成功以后,调用swap函数将副本和原对象进行调换(因为copy and swap技术告诉我们,swap函数是不会抛异常的),所以,这个时候我们也能理解了条款25说,swap函数成为异常安全编程的脊柱。
大师用怀孕来比喻异常安全代码,就是说,代码要么是一场安全的,要么就不具备异常安全,没有部分异常安全这么一说
函数提供的“异常安全保证”通常最高只等于其所调用之各个函数的“异常安全保证”中的最弱者
条款30:inline
1、将大多数inlining限制在小型,被频繁调用的函数身上,这可使日后的调试过程和二进制升级更加容易,也可使潜在的代码通胀问题最小化,使程序的速度提升机会最大化
2、不要只因为function template出现在头文件,就将它们声明为inline
条款31:不是非常理解,不敢乱写
相关文章推荐
- Effective C++(条款26-31)
- 《Effective C++ 3》05 实现 条款:26-31
- 《Effective C++》学习笔记条款26 尽可能延后变量定义式的出现时间
- effective C++ 条款05 to 条款12
- effective C++ 条款18 to 条款24
- 读书笔记《Effective C++》条款31:将文件间的编译依存关系降至最低
- 《Effective C++》之条款31:将文件间的编译依存关系降至最低
- Effective C++——条款31(第5章)
- Effective C++--条款20:适当地用pass-by-reference-to-const代替pass-by-value
- 《Effective C++》学习笔记条款31:将文件间的编译依存关系降至最低
- EC读书笔记系列之14:条款26、27、28、29、30、31
- Effective C++ 条款26 尽可能延后变量定义式的出现时间
- Effective C++——条款26(第5章)
- effective c++ 条款11 Handle assignment to self in operator=
- 读书笔记《Effective c++》 条款20 宁以pass-by-reference-toconst替换pass-by-value
- effective c++ 条款26 postpone variable definition as long as possible
- Effective C++ 条款20 宁以pass-by-reference-to-const替换pass-by-value
- Effective C++ -----条款31:将文件间的编译依存关系降至最低
- effective C++ 条款13 to 条款17
- Effective C++ -----条款10: 令operator=返回一个reference to *this