Effective C++第四章总结

来源:互联网 发布:淘宝消费者规则在哪 编辑:程序博客网 时间:2024/04/29 17:22
26.尽可能延后变量的定义式的出现时间。
总结:尽可能延后变量定义式的出现,这样做可增加程序的清晰度并改善程序效率。


27.尽量少做转型动作。
旧式转型:
(T)expression
T(expression)


c++提供新式转型:
const_cast<T>(expression) :将对象的常量性转除  const对象转成非const
dynamic_cast<T>(expression) :主要用来执行“安全向下转型”,也就是用来决定某对象是否归属继承体系中的某个类型。基类指针转成派生类
reinterpret_cast<T>(expression) :执行低级转换
static_cast<T>(expression) :隐式转换      int转型为double,非const对象转成const对象


总结:如果可以,尽量避免转型,特别是在注重效率的代码中避免 dynamic-casts.如果有个设计需要转型动作,试着发展无需转型的替代设计。
如果转型是必要的,试着将它隐藏于某个函数背后。
尽量使用新式转型,不要使用旧式转型,因为新式转型很容易被标记出来。


28.避免返回handles指向对象内部成分。
不论这所谓的handle是个指针或迭代器或reference,也不论这个handle是否为const,也不论那个返回handle的成员函数是否为const.
这里的唯一关键是,有个handle被传出去了,一旦如此你就是暴露在“handle比其所指对象更长寿”的风险下。


这并不意味你绝对不可以让成员函数返回handle,有时候你必须那么做。例如operator[]就允许你访问strings和vectors的个别元素,而这些
operator[]s就是返回references 指向“容器类的数据”,哪些数据会随着容器被销毁而销毁,尽管如此,这样的函数毕竟是个例外,不是常态。


总结:避免返回handles(包括references、指针、迭代器)指向对象内部。遵守这个条款可增加封装性,帮助const成员函数的行为相隔const.


29.为“异常安全”而努力是值得的。
不泄露任何资源。
不允许数据败坏。


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


30.透彻了解inlining的里里外外
总结:将大多数inlining限制在小型、被频繁调用的函数身上。这可使日后的调试过程和二进制升级更容易,也可使潜在的代码膨胀问题最小化。
不要只因为function templates出现在头文件,就将它们声明为inlining.


31.将文件间的编译依存关系降至最低。
总结:
支持“编译依存性最小化”的一般构想是:相依于声明式,不要相依于定义式。基于此构想的两个手段是Handle classes和Interface classes.
程序库头文件应该以“完全且仅有声明式”的形式存在。这种做法不论是否涉及templates都适用。



0 0