• More Effective C++ (2)


    接下来的是more effective c++ 11至20条款:

    11.禁止异常信息(exceptions)传递到析构函数外。
    析构函数的调用情况可能有两种:(1)对象正常销毁 (2)异常传播过程中的栈展开机制-销毁。
    如果在析构函数内抛出异常,它不会被析构函数捕获,它会传播到析构函数的调用端,如果调用端是因为其他异常而被
    调用的,那么程序就会死掉。还有可能就是导致后面的语句无法执行,所以不能让异常传播到析构函数之外。

    12.理解“抛出一个异常”与“传递一个参数”或“调用一个虚函数”间的差异。
    (1)抛出的异常总会被复制(值传递或引用传递),指针不会被复制,trows ;抛出当前异常,throws type; 抛出异常的静态类型。
    (2)被抛出的异常不会进行类型转换,但是可以捕获继承父类的子类型异常。
    (3)处理异常的顺序为先捕获先处理,所以要把子类异常放在父类异常前面。

    13.通过引用(reference)捕获异常。
    通过引用捕获异常,可以解决用指针抛出异常时,如果指针为局部对象(抛出的是被销毁的垃圾),
    或者抛出指针new 的堆中的对象该不该在之后删除的烦恼。
    也可解决以值传递造成的二次复制的效率问题和虚函数调用的多态问题(异常复制是对静态类型的复制)。

    14.审慎使用异常规格(exception specifications)。
    在给出了异常规格的函数中,如果函数内不经意违反了异常规格中的异常列表,会导致程序的终止。
    也可能会导致较高层次的调用者已经准备处理该异常而无法处理。也可以用“以不同类型的异常取代非预期的异常”解决这个问题。

    15.了解异常处理的系统开销。
    异常的使用成本是挺高的,请将对try语句块和异常规格的使用限制于非用不可的地点,并且在真正异常的情况下才抛出异常。

    16.谨记80-20法则
    一个程序80%的资源用于20%的代码的身上。80%的内存被大约20%的代码使用,80%的执行时间花在大约20%的代码身上。
    当你需要找出问题的瓶颈所在,最好的是找到那关键的20%的代码,可以借助某个程序分析器来分析,知道语句被执行或函数
    调用的频繁度也可以给你一些启示。

    17.考虑使用lazy evaluation。
    这个法则简而言之就是将非必要的大量的复杂的计算在等到真的要使用的时候才去计算获得,可以提高效率。
    不过,真的需要无法避免的大量运算的话,那也是要付出相应的代价的呀。

    18.分期摊还预期的计算成本。
    这个条款与上一个相对应的,这个条款相当于先预分配需要的内存,或预记录频繁使用的数据,用空间来换取时间。

    19.了解临时对象的来源。
    临时对象并不是局部对象,它不会在你的源码里出现。
    临时对象产生有两种可能:(1)当隐式类型转换。 (2)函数返回对象时候。
    只有当以值传递或常量引用传递参数时才会发生隐式类型转换,非常量引用对象参数传递不会发生隐式转换。
    要注意避免隐式类型转换,做好返回值的优化。

    20.协助完成“返回值优化RVO”。
    可以通过内联函数进行返回值的优化,这样可以消除返回的局部对象和临时对象。

    未完待续~

  • 相关阅读:
    rotatelogs分割apache日志文件
    Linux怎么设置PostgreSQL远程访问
    【转】Shell编程
    【转】lnmp_auto:自动化安装lnmp环境脚本
    postgres配置主从流复制
    PHP中的魔术方法总结
    postgresql 忘记 postgres 密码
    linux下解压命令大全
    Java NIO Selector
    Channel (Java NIO)
  • 原文地址:https://www.cnblogs.com/george-cw/p/4172740.html
Copyright © 2020-2023  润新知