烽火前秦路

Item M1:指针与引用的区别指针与引用看上去完全不同（指针用操作符“*”和“->”，引用使用操作符“. ”），但是它们似乎有相同的功能。指针与引用都是让你间接引用其他对象。你如何决定在什么时候使用指针，在什么时候使用引用呢？首先，要认识到在任何情况下都不能使用指向空值的引用。一个引用必须总是指向某些对象。因此如果你使用一个变量并让它指向一个对象，但是该变量在某些时候也可能不指向任何对象

Item M18：分期摊还期望的计算在条款M17中，我极力称赞懒惰的优点，尽可能地拖延时间，并且我解释说懒惰如何提高程序的运行效率。在这个条款里我将采用一种不同的态度。这里将不存在懒惰。我鼓励你让程序做的事情比被要求的还要多，通过这种方式来提高软件的性能。这个条款的核心就是over-eager evaluation（过度热情计算法）：在要求你做某些事情以前就完成它们。例如下面这个模

Item M19：理解临时对象的来源当程序员之间进行交谈时，他们经常把仅仅需要一小段时间的变量称为临时变量。例如在下面这段swap(交换)例程里：templatevoid swap(T& object1, T& object2){ T temp = object1; object1 = object2; object2 = temp;}通常把te

Item M20：协助完成返回值优化一个返回对象的函数很难有较高的效率，因为传值返回会导致调用对象内的构造和析构函数(参见条款M19)，这种调用是不能避免的。问题很简单：一个函数要么为了保证正确的行为而返回对象要么就不这么做。如果它返回了对象，就没有办法摆脱被返回的对象。就说到这。考虑rational(有理数)类的成员函数operator*：(返回类型为const是为了防止连续

Item M21：通过重载避免隐式类型转换（读这一节内容之前，建议回顾C++转换构造函数和隐式转换函数的相关知识。）以下是一段代码，如果没有什么不寻常的原因，实在看不出什么东西：class UPInt { // unlimited precisionpublic:

Item M22：考虑用运算符的赋值形式(op=)取代其单独形式(op)大多数程序员认为如果他们能这样写代码：x = x + y; x = x - y;那他们也能这样写：x += y; x -= y;如果x和y是用户定义的类型（user-defined type），就不能确保这样。就C++来说，operator+、operator=和operator+=之间没有

Item M23：考虑变更程序库程序库的设计就是一个折衷的过程。理想的程序库应该是短小的、快速的、强大的、灵活的、可扩展的、直观的、普遍适用的、具有良好的支持、没有使用约束、没有错误的。这也是不存在的。为尺寸和速度而进行优化的程序库一般不能被移植。具有大量功能的的程序库不会具有直观性。没有错误的程序库在使用范围上会有限制。真实的世界里，你不能拥有每一件东西，总得有付出。

Item M24：理解虚拟函数、多继承、虚继承和RTTI所需的代价C++编译器们必须实现语言的每一个特性。这些实现的细节当然是由编译器来决定的，并且不同的编译器有不同的方法实现语言的特性。在多数情况下，你不用关心这些事情。然而有些特性的实现对对象大小和其成员函数执行速度有很大的影响，所以对于这些特性有一个基本的了解，知道编译器可能在背后做了些什么，就显得很重要。这种特性中最重要的例子是

技巧本书涉及的大多数内容都是编程的指导准则。这些准则虽是重要的，但是程序员不能单靠准则生活。有一个很早以前的卡通片叫做“菲利猫”（Felix the Cat）, 菲利猫无论何时遇到困难，它都会拿它的trick包。如果一个卡通角色都有一个trick包，那么C++程序员就更应该有了。把这一章想成你的trick包的启动器。当设计C++软件时，总会再三地受到一些问题的困扰。你如何让

Item M26：限制某个类所能产生的对象数量你很痴迷于对象，但是有时你又想束缚住你的疯狂。例如你在系统中只有一台打印机，所以你想用某种方式把打印机对象数目限定为一个。或者你仅仅取得16个可分发出去的文件描述符，所以应该确保文件描述符对象存在的数目不能超过16个。你如何能够做到这些呢？如何去限制对象的数量呢？如果这是一个用数学归纳法进行的证明，你会从n=1开始证明，然后从此出发

Item M28：灵巧(smart)指针

Item M17：考虑使用lazy evaluation(懒惰计算法)从效率的观点来看，最佳的计算就是根本不计算，那好，不过如果你根本就不用进行计算的话，为什么还在程序开始处加入代码进行计算呢?并且如果你不需要进行计算，那么如何必须执行这些代码呢？关键是要懒惰。还记得么？当你还是一个孩子时，你的父母叫你整理房间。你如果象我一样，就会说“好的“

效率我怀疑一些人在C++软件开发人员身上进行秘密的巴甫洛夫试验，否则为什么当提到“效率”这个词时，许多程序员都会流口水。（Scott Meyers真幽默 译者注）事实上，效率可不是一个开玩笑的事情。一个太大或太慢的程序它们的优点无论多么引人注目都不会为人们所接受。本来就应该这样。软件是用来帮助我们更好地工作，说运行速度慢才是更好的，说需要32MB内存的程序比仅仅需要16MB内存

Item M15：了解异常处理的系统开销为了在运行时处理异常，程序要记录大量的信息:无论执行到什么地方，程序都必须能够识别出如果在此处抛出异常的话，将要被释放哪一个对象；程序必须知道每一个入口点，以便从try块中退出；对于每一个try块，他们都必须跟踪与其相关的catch子句以及这些catch子句能够捕获的异常类型。这种信息的记录不是没有代价的。虽然确保程序满足异常

Item M4：避免无用的缺省构造函数缺省构造函数（指没有参数的构造函数）在C++语言中是一种让你无中生有的方法。构造函数能初始化对象,而缺省构造函数则可以不利用任何在建立对象时的外部数据就能初始化对象。有时这样的方法是不错的。例如一些行为特性与数字相仿的对象被初始化为空值或不确定的值也是合理的，还有比如链表、哈希表、图等等数据结构也可以被初始化为空容器。但不是所有的对象都属于上述

Item M6：自增、自减操作符前缀形式和后缀形式的区别很久以前（八十年代），没有办法区分++和--操作符的前缀与后缀调用。这个问题遭到程序员的报怨，于是C++语言得到了扩展，允许重载increment 和 decrement操作符的两种形式。然而有一个句法上的问题，重载函数间的区别决定于它们的参数类型上的差异，但是不论是increment或decrement的前缀还是后缀都只有一个参

Item M7：不要重载"&&"、"||"、","与C一样，C++使用布尔表达式短路求值法(short-circuit evaluation)。这表示一旦确定了布尔表达式的真假值，即使还有部分表达式没有被测试，布尔表达式也停止运算。例如：char *p;...if ((p != 0) && (strlen(p) > 10)) ...这里不用担心当p为空时strlen无

Item M8：理解各种不同含义的new和delete

异常关于C++异常的详细知识，请参考http://blog.youkuaiyun.com/qianqin_2014/article/details/51325842>C++新增的异常（exception）机制改变了某些事情，这种改变是深刻的，彻底的，可能是令人不舒服的。例如：使用未经处理的或原始的指针变得很危险；资源泄漏的可能性增加了；写出具有你希望的行为的构造函数与析构函数变得更加困

Item M10：在构造函数中防止资源泄漏如果你正在开发一个具有多媒体功能的通讯录程序。这个通讯录除了能存储通常的文字信息如姓名、地址、电话号码外，还能存储照片和声音（可以给出他们名字的正确发音）。为了实现这个通信录，你可以这样设计：class Image { // 用于图像数据public: Image(const st

Item M11：禁止异常信息(exceptions)传递到析构函数外在有两种情况下会调用析构函数。第一种是在正常情况下删除一个对象，例如对象超出了作用域或被显式地delete。第二种是异常传递的堆栈辗转开解（stack-unwinding）过程中，由异常处理系统删除一个对象。在上述两种情况下，调用析构函数时异常可能处于激活状态也可能没有处于激活状态。遗憾的是没有办法在析构函数

Item M12：理解"抛出一个异常"与"传递一个参数"或"调用一个虚函数"间的差异从语法上看，在函数里声明参数与在catch子句中声明参数几乎没有什么差别：class Widget { ... }; //一个类，具体是什么类 // 在这里并不重要void f1(Widg

Item M13：通过引用(reference)捕获异常当你写一个catch子句时，必须确定让异常通过何种方式传递到catch子句里。你可以有三个选择：与你给函数传递参数一样，通过指针（by pointer），通过传值（by value）或通过引用（by reference）。我们首先讨论通过指针方式捕获异常（catch by pointer）。从throw处传递一个异常到

Item M14：审慎使用异常规格(exception specifications)毫无疑问，异常规格是一个引人注目的特性。它使得代码更容易理解，因为它明确地描述了一个函数可以抛出什么样的异常。但是它不只是一个有趣的注释。编译器在编译时有时能够检测到异常规格的不一致。而且如果一个函数抛出一个不在异常规格范围里的异常，系统在运行时能够检测出这个错误，然后一个特殊函数unexpected

Item M27：要求或禁止在堆中产生对象有时你想这样管理某些对象，要让某种类型的对象能够自我销毁，也就是能够“delete this”。很明显这种管理方式需要此类型对象被分配在堆中。而其它一些时候你想获得一种保障：“不在堆中分配对象，从而保证某种类型的类不会发生内存泄漏。”如果你在嵌入式系统上工作，就有可能遇到这种情况，发生在嵌入式系统上的内存泄漏是极其严重的，其堆空间是非常珍贵的。