《Effective C++》重点摘要(五)

《Effective C++》第五章:实现

  1. 尽可能延后变量定义式的出现时间。只有变量在恰好要使用之前定义,程序的可读性往往会得到提高,因为这样不容易忘记变量说代表的意思。另一方面,这样做可以提高程序性能,如果不需要一个变量时却要为它分配、释放空间,调用构造、析构函数,获取、释放资源……这,真是太浪费了。补充一点,声明式并不会做这些事情,所以可以考虑用声明式替换定义式以尽量延后变量的定义。
  2. 尽量少做转型动作。转型意味着出错的可能性大大提升,转型意味着更多的操作。如果不得不转型,考虑使用C++ style的形式,或提供一个专门的转型函数。
  3. 避免返回handles指向对象内部成分。引用、指针、迭代器都是指向对象内部成分的handles,返回这些东西就把他们的生杀大权交给了别人,降低了封装性,安全性。如果不得不使用对象内部的成分,考虑返回const型,只让外部具有读取的权利。
  4. 为”异常安全“而努力是值得的。“异常安全”的代码不泄露任何资源,不允许数据败坏。“异常安全”的代码提供三个保证之一:(1)基本承诺。出现异常时,程序内的任何事物仍然处在有效状态下。没有任何对象或数据结构因此而败坏。(2)强烈保证。操作要么成功,要么不成功。如果操作失败,程序回到操作前的状态。(3)不抛掷保证。不抛出异常。实际情况下,函数内部调用的函数未必提供相应的保证,所以不能总是控制函数具有“异常安全”性,所以,如果全在你的掌控之中,请提供一种异常保证,如果不能,请在文档里说明。
  5. 透彻了解inlining的里里外外。Inline函数很好,但是过度的inline函数会增加程序的目标码。因为编译器对于inline函数的处理是:对于每个inline函数的调用,都以函数的本体替换之,而不是保存现场,跳转到函数的入口处。Inline函数实现放在头文件里的原因是编译器在编译时就要知道inline函数是什么样子的,以便完成替换。另外一个重点是inline是对编译器的一项建议,是否真正inline由编译器决定。如果要写inline函数,针对那些频繁调用的简单函数。
  6. 将文件间的编译依存关系降至最低。如果只是修改了程序的一部分,却要重新编译许多不相关的模块,这真是令人焦躁而无语。这主要是由于C++的编译规则引起的,如果A文件里include了B文件,现在只是对A进行修改,那么重新编译时B文件也会被重新编译,而B文件又include了C、D、E文件,而C、D、E文件又……这看起来就是个灾难,所以,非常有必要将文件间的编译依存关系降至最低。至少有三种方式可以做出这样的努力:

    1) 能使用object reference 或 object pointer,就不要使用object。reference 或 pointer只需要一个声明式就可以了,不需要定义式。

    2) 如果能够,尽量以class声明式替换class定义式。

    3) 为声明式和定义式提供不同的头文件,像std那样组织起自己的类。

    pimpl idiom手法和abstract base class可以帮助实现上面的方式,并且abstract base class往往意味着多态,而这正是面向对象的思想的体现。23中经典模式里多态还少吗?

时间: 2024-11-03 21:10:33

《Effective C++》重点摘要(五)的相关文章

BDD in Action 重点摘要

BDD in Action 重点摘要: BDD in Action ?对于需灰度发布的产品, 开发人员可经由BDD, 便可自保证需灰度发布产品的质量? ?所以, BDD 可使产品更快速的达到灰度发布的要求, 而可更快速的获得使用者对产品的反馈? ?在这样的开发模式下, 测试人员可更专注于探索性测试, 挖掘出更深层的产品缺陷, 回归到真正测试人员的专业?

《Effective C++》重点摘要(八)

<Effective C++>第八章:定制new和delete 了解new-handler的行为.new和delete不是函数,是申请和释放内存的操作符.当new提出获得内存申请失败时会发生什么?老旧的编译器是返回null指针.现在呢,如果申请失败,会先调用一个错误处理函数,那就是new-handler.这就像一个回调函数,系统有一个默认的,用户也可以自行编写一个错误处理函数并使用set_new_handler函数设置之.通常自行编写的错误处理函数可以使用这些策略: 1) 多次尝试申请内存.

《Effective C++》重点摘要(九)

<Effective C++>第九章:杂项讨论 不要轻忽编译器的警告.严肃对待编译器发出的警告信息.努力在最高警告级别下争取无警告.也不要过度依赖编译器给出的警告信息,不同的编译器给出的警告信息是不一样的,甚至给出警告的点也不一样. 让自己熟悉包括TR1在内的标准程序库. 让自己熟悉Boost. C++不想Java和C#那样,语言本身就带有很强大的库,所以外部的程序库对于编写C++程序至关重要.俗话说不要重复发明轮子嘛,所以能用别人的就用吧.当然这是在实际工程中,学习阶段嘛,我还是比较推崇自己

《Effective C++》重点摘要(一)

开篇的话 这个星期不再发布关于数据结构的博客,想把半个月来看的书做一些总结,整理整理,第一本就是<Effective C++>.第一次看这本书是一年多前,准备考研复试的时候,随后陆陆续续,这个月再来看算是第三遍了吧,之前没有看过<深度探索C++对象模型>,所以有的地方看得不是很透彻(现在有的地方也看得不透,但是比以前好点了).还有另一本书就是<深度探索C++对象模型>,看第二遍,吸收得更容易了,看书总是这样,第一遍也许什么也不知道,但是只要坚持看下去,回过头来再读的时候

《Effective C++》重点摘要(二)

<Effective C++>第二章:构造/析构/赋值运算 C++默认编写的函数.C++编译器如果没有发现以下函数,就会为类生成一份默认版本的: 1) default构造函数 2) default析构函数 3) copy构造函数 4) copy assignment操作符(=运算符) 前两个函数并不总是产生,它只在编译器需要的时候才产生出来.后两个函数只保证以bitwise语义拷贝non-static成员,所以如果有指针.引用等non-static成员的类要么拒绝编译器产生的版本,要么自行小心

《Effective C++》重点摘要(三)

<Effective C++>第三章:资源管理 以对象管理资源.一份资源,可能是一片内存,可能是一个锁,当客户申请后需要手动释放才是合理的,那么最好在获得这份资源的时候,就立刻把它放到一个对象里(RAII技术),然后在对象的析构函数里释放它.这样释放操作就不会被遗忘了,并且,就算在使用资源类的语境中有语句抛出异常,也能确保资源得到正确的释放. 在资源管理类中小心coping行为.有的资源是不支持copy语义的,而有的资源需要深拷贝语义,有的资源支持控制权转移语义,还有的资源是支持引用计数的,所

《Effective C++》重点摘要(七)

<Effective C++>第七章:模板与泛型编程 了解隐式接口和编译期多态.面向对象编程总是采用显式地声明一个接口,并在子类中提供特殊的实现,进而实现运行期多态.模板类中的接口往往是隐式的,隐式的意思是,编写模板时,假设需要的接口类T中是存在的,至于实例化模板的类是否真的具有该接口,编译时才知道(如果实例化类型没有实现这些接口,则编译失败).这正是模板多态的展现方式,由实例化模板的类决定具体的行为是什么.这种多态编译期与运行期多态有很大的区别,运行期的多态是一种is-a类型的多态(我自造的

《More Effective C++》重点摘要一:基础议题

仔细区别pointers和references.指针和引用有些相似,他们本身都是对存在于某个地方的对象(不是指class)的指示,但是他们有着本质的区别.指针变量存储所指对象的地址,所指的对象可以是null,只要可以寻址就行.而引用是某个已经存在对象的别名,所以不可以先声明一个引用,经过一段时间(代码)后让它指向某个对象. 最好使用C++转型操作符.C++提供了自己的四种转型操作符: 1) static_cast.拥有与C旧式转型相同的意义与限制,但不能移除表达式的常量性,因为有const_ca

《Effective C++》重点摘要(四)

<Effective C++>第四章:设计与声明 让接口容易被正确使用,不易被误用.一个接口由返回类型.接口名称.和参数列表组成,为了让接口容易被正确的使用,需要小心设计返回类型,最好是简单.直接.自然.接口名称选择很重要,做到简单.达意.无歧义.参数列表形参类型需要身份小心,如果能防范非法输入,尽力为之,形参名也尽可能做到同接口名称一样的标准.另外请保持命名习惯的一致性也能收到奇效. 设计class犹如设计type.用户对语言内置的type支持的行为一般十分熟悉,所以最好自行设计的class