条款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; 这个其

条款15 : 在资源管理类中提供对原始资源的访问 我们将资源存入资源管理类, 为的是可以免去资源管理的麻烦, 但同时我们也希望可以正常合理地通过资源管理类来使用资源, 就像直接使用资源一样, 为此我们一定需要在资源管理类中提供对原始资源的访问; 我们先来解答一些疑问 : 为什么要对原始资源进行访问(为什么要获取原始资源的指针)?有时候需要我们传递原始资源的指针, 因为很多C API都是要求传

条款14 : 在资源管理类中小心 copying 行为 本条款是在我们自己建立资源管理类时要注意的行为, 但是归根结底, 我们为什么要自己建立资源管理类呢 ? 为什么不用 shared_ptr ? 这是我们在本条款中需要首先解决迭代问题. 书中提出, C++提供的智能指针是适配于heap-based资源上的, 其要求不管是自动生成还是手动完成, 该资源必须要有析构函数, 然而并非所有的资源都是h

条款13 : 以对象管理资源 所谓资源, 一旦用了它, 将来必须还给系统. 本条款及以后几项条款都致力于实现优秀的资源管理, 严守这些条款, 可以几乎消除资源管理问题. 本条款主要提出以对象管理资源的思想, 以及对std内置的auto_ptr和smart_prt的使用策略做了分析. 书中塑模了一个投资行为, 让我们看看资源该如何处理 : 12345678910class Investment

条款10 : 令 operator= 返回一个 reference to * this 很多类都有重写operator=函数的要求, 本质是 = 左侧调用 operator= 函数, 右侧作为参数传入, 将右侧参数赋值给左侧成员变量, 并且为了实现连锁赋值, 我们还应当使 operator= 返回当前赋完值的对象. 本条款的目的是实现连锁赋值,

条款09 : 绝不在构造和析构函数过程中调用virtual函数开门见山阐释本条款的重点 : 你不该在构造函数和析构函数中调用virtual函数. 书中给出了一个例子 : 假如我们要塑膜股市交易订单模型, 订单可以分成买入, 卖出等不同类型的订单, 当我们产生不同类型的订单, 也就是构造不同类型订单对象时, 我们也许会有记录订单日志的需求, 并我们希望订单根据不同的订单类型产生不同的订单日志. 于是