条款26 : 尽可能延后变量定义式的出现时间只要你定义了一个变量, 并且其类型带有构造函数或析构函数, 那么当程序控制流到达变量定义式时, 你便得承担构造成本; 当变量离开作用域时, 你便得承担析构成本. 本条款希望我们避免定义变量但最终并未使用的情况, 不要白白浪费构造和析构的成本. 先来看看什么情况下会出现定义变量但最终并未使用 : 这是一个密码加密的函数, 由于密码本身不能修改, 所以要定

条款25 : 考虑写出一个不抛异常的swap函数 swap 是一个有趣的函数, 原本它只是STL的一部分, 而后成为了异常安全性编程中的脊柱, 有关异常安全性我在条款11中介绍过, 在之后的条款29中也将着重着墨. 由于swap相当有用, 适当的实现非常重要, 好的swap设计可以带来非凡的效率提升. swap顾名思义, 意为将两对象的值彼此赋予对方, 在现代标准库中的实现是这样 : 1234

条款24: 若所有参数皆需类型转换, 请为此采用non-member函数 虽然令classes支持隐式类型转换是一个坏主意, 但常常有许多意外出现, 有些类型之间的关联实在太强, 我们经常想把它们放在一起用, 例如支持int类型隐式转换为Rational(有理数), 当对便利性的需求非常强烈之后, 也许支持隐式类型转换也未必是坏事. 书中给出了一个Rational类, 它可以由int

人只有想起自己的无知才能有长进, 但他如此忙碌于运用自己已有的知识, 又如何能想得起来呢? 受制于对自己的看法, 受制于他通过自己行动所赢得的名誉. 大家好像都选择了相同的生活模式, 好像这种模式是在他们清醒时做出的选择, 然而其实他们并不认为还有其他模式可选, 但聪敏而健康的人记得太阳每天都会升起. 所有的改变都是奇迹, 但这种奇迹时时刻刻都在发生. 在当前的境况中找到他们的勇气和灵感

条款22 : 将成员变量声明为private本条款中, 作者明确声明, 如果没有必要的原因, 务必将成员变量声明为private, 而非public/protected, 并苦口婆心地列举出了非常多使用private的优势, 让我们逐一阅览 : 保证了语法一致性当客户通过对象调用时, 如果将成员变量声明为private, 那么就省去了客户思考要不要加小括号的问题, 只要无脑加括号就行了. 对

条款21 : 必须返回对象时, 别妄想返回其reference 当程序员领悟了条款20所讲的pass-by-value的种种效率问题之后, 往往会变成十字军战士, 一心一意根除pass-by-value的存在, 然而这却会让他们犯下一些致命的错误, 通过本条款让我们来了解. 阅读完本文章, 我更倾向于把本条款解释为 : 必须返回新对象时, 别妄想返回其reference. 这样子会更便于理解

条款20 : 宁以pass-by-reference-to-const替换pass-by-value 本条款将告诉我们函数传参时的最佳策略. 我们都知道, pass-by-value(传值传参)是一个费时费力的过程, 它会直接复制一个原件的拷贝, 如果是自定义类就会调用一次拷贝构造来实现复制, 函数结束时还要额外调用一次析构函数, 我们会很有意愿去削减这方面的花销. 相信我们在别处的很多函数中都

条款19 : 设计class犹如设计type C++ 是面向对象编程语言, 当你定义了一个新class, 也就定义了一个新type. 然而设计一个优秀的class是一项艰巨的任务, 正如设计一个好的type是一项艰巨的任务. 本条款将依照一个好的类型应有的行为来指导我们class的设计, 并一一列举出来. 当我们要设计一个class时, 让我们对自己提出这些问题吧 : 新type的对象应该如

条款18 : 让接口容易被正确使用, 不易被误用. C++在接口之海漂浮, 一个好的接口很容易被正确使用, 不容易被误用. 条款18其实是一个很宏观的条款, 让接口变得正确易用, 简单来说就是”促进正确使用“和”阻止误用“. 我们先从阻止误用的角度考虑, 对接口来说, 是否误用无非就是参数传递的类型对不对, 参数是否合法, 是否符合设计者的设想. 书中给出了一个日期类, 分别由年月日的成员变量,

条款16 : 成对使用new和delete时要采用相同形式直接看代码 : 12345std::string *stringPtr1 = new std::string;std::string *stringPtr2 = new std::string[100];...delete stringPtr1; delete [] stringPtr2; 这个其