对每个人来说，习惯C++需要一些时间，对于已经熟悉C的程序员来说，这个过程尤其令人苦恼。因为C是C++的子集，所有的C的技术都可以继续使用，但很多用起来又不太合适。例如，C++程序员会认为指针的指针看起来很古怪，他们会问：为什么不用指针的引用来代替呢？
C 是一种简单的语言。它真正提供的只有有宏、指针、结构、数组和函数。不管什么问题，C都靠宏、指针、结构、数组和函数来解决。而C++不是这样。宏、指针、结构、数组和函数当然还存在，此外还有私有和保护型成员、函数重载、缺省参数、构造和析构函数、自定义操作符、内联函数、引用、友元、模板、异常、名字空间，等等。用C++比用C具有更宽广的空间，因为设计时有更多的选择可以考虑。
在面对这么多的选择时，许多C程序员墨守成规，坚持他们的老习惯。一般来说，这也不是什么很大的罪过。但某些C的习惯有悖于C++的精神本质，他们都在下面的条款进行了阐述。
条款1：尽量用const和inline而不用#define
这个条款最好称为：“尽量用编译器而不用预处理”，因为#define经常被认为好象不是语言本身的一部分。这是问题之一。再看下面的语句：
#define ASPECT_RATIO 1.653
编译器会永远也看不到ASPECT_RATIO这个符号名，因为在源码进入编译器之前，它会被预处理程序去掉，于是ASPECT_RATIO不会加入到符号列表中。如果涉及到这个常量的代码在编译时报错，就会很令人费解，因为报错信息指的是1.653，而不是ASPECT_RATIO。如果 ASPECT_RATIO不是在你自己写的头文件中定义的，你就会奇怪1.653是从哪里来的，甚至会花时间跟踪下去。这个问题也会出现在符号调试器中，因为同样地，你所写的符号名不会出现在符号列表中。
解决这个问题的方案很简单：不用预处理宏，定义一个常量：
const double ASPECT_RATIO = 1.653;
这种方法很有效。但有两个特殊情况要注意。
首先，定义指针常量时会有点不同。因为常量定义一般是放在头文件中（许多源文件会包含它），除了指针所指的类型要定义成const外，重要的是指针也经常要定义成const。例如，要在头文件中定义一个基于char*的字符串常量，你要写两次const：
const char * const authorName = "Scott Meyers";
关于const的含义和用法，特别是和指针相关联的问题，参见条款21。
另外，定义某个类(class)的常量一般也很方便，只有一点点不同。要把常量限制在类中，首先要使它成为类的成员；为了保证常量最多只有一份拷贝，还要把它定义为静态成员：
class GamePlayer {
private:
static const int NUM_TURNS = 5; // constant eclaration
int scores[NUM_TURNS]; // use of constant
...
};
还有一点，正如你看到的，上面的语句是NUM_TURNS的声明，而不是定义，所以你还必须在类的实现代码文件中定义类的静态成员：
const int GamePlayer::NUM_TURNS; // mandatory definition;
// goes in class impl.file
你不必过于担心这种小事。如果你忘了定义，链接器会提醒你。
旧一点的编译器会不接受这种语法，因为它认为类的静态成员在声明时定义初始值是非法的；而且，类内只允许初始化整数类型(如：int, bool, char 等)，还只能是常量。
在上面的语法不能使用的情况下，可以在定义时赋初值：
class EngineeringConstants { // this goes in the class
private: // header file
static const double FUDGE_FACTOR;
...
};
// this goes in the class implementation file
const double EngineeringConstants::FUDGE_FACTOR = 1.35;
大多数情况下你只要做这么多。唯一例外的是当你的类在编译时需要用到这个类的常量的情况，例如上面GamePlayer::scores数组的声明(编译过程中编译器一定要知道数组的大小)。所以，为了弥补那些(不正确地)禁止类内进行整型类常量初始化的编译器的不足，可以采用称之为“借用enum”的方法来解决。这种技术很好地利用了当需要int类型时可以使用枚举类型的原则，所以GamePlayer也可以象这样来定义：
class GamePlayer {
private:
enum { NUM_TURNS = 5 } // "the enum hack" — makes
// NUM_TURNS a symbolic name
// for 5
int scores[NUM_TURNS];// fine
};
除非你正在用老的编译器(即写于1995年之前)，你不必借用enum。当然，知道有这种方法还是值得的，因为这种可以追溯到很久以前的时代的代码可是不常见的哟。
回到预处理的话题上来。另一个普遍的#define指令的用法是用它来实现那些看起来象函数而又不会导致函数调用的宏。典型的例子是计算两个对象的最大值：
#define max(a,b) ((a) > (b) ? (a) : (b))
这个语句有很多缺陷，光想想都让人头疼，甚至比在高峰时间到高速公路去开车还让人痛苦。
无论什么时候你写了象这样的宏，你必须记住在写宏体时对每个参数都要加上括号；否则，别人调用你的宏时如果用了表达式就会造成很大的麻烦。但是即使你象这样做了，还会有象下面这样奇怪的事发生：
int a = 5, b = 0;
max(++a, b);// a 的值增加了2次
max(++a, b+10); // a 的值只增加了1次
这种情况下，max内部发生些什么取决于它比较的是什么值！
幸运的是你不必再忍受这样愚笨的语句了。你可以用普通函数实现宏的效率，再加上可预计的行为和类型安全，这就是内联函数(见条款33)：
inline int max(int a, int b) { return a > b ? a : b; }
不过这和上面的宏不大一样，因为这个版本的max只能处理int类型。但模板可以很轻巧地解决这个问题：
template<class T>
inline const T& max(const T& a, const T& b)
{ return a > b ? a : b; }
这个模板产生了一整套函数，每个函数拿两个可以转换成同种类型的对象进行比较然后返回较大的(常量)对象的引用。因为不知道T的类型，返回时传递引用可以提高效率(见条款22)。
顺便说一句，在你打算用模板写象max这样有用的通用函数时，先检查一下标准库(见条款49)，看看他们是不是已经存在。比如说上面说的max，你会惊喜地发现你可以后人乘凉：max是C++标准库的一部分。
有了const和inline，你对预处理的需要减少了，但也不能完全没有它。抛弃#include的日子还很远，#ifdef/#ifndef在控制编译的过程中还扮演重要角色。预处理还不能退休，但你一定要计划给它经常放长假。
条款2：尽量用<iostream>而不用<stdio.h>
是的，scanf和printf很轻巧，很高效，你也早就知道怎么用它们，这我承认。但尽管他们很有用，事实上scanf和printf及其系列还可以做些改进。尤其是，他们不是类型安全的，而且没有扩展性。因为类型安全和扩展性是C++的基石，所以你也要服从这一点。另外，scanf/printf系列函数把要读写的变量和控制读写格式的信息分开来，就象古老的FORTRAN那样。是该向五十年代说诀别的时候了！
不必惊奇，scanf/printf的这些弱点正是操作符>>和<<的强项:
int i;
Rational r;// r 是个有理数
...
cin >> i >> r;
cout << i << r;
上面的代码要通过编译，>>和<<必须是可以处理Rational类型对象的重载函数(可能要通过隐式类型转换)。如果没有实现这样的函数，就会出错(处理int不用这样做，因为它是标准用法)。另外，编译器自己可以根据不同的变量类型选择操作符的不同形式，所以不必劳你去指定第一个要读写的对象是int而第二个是Rational。
另外，在传递读和写的对象时采用的语法形式相同，所以不必象scanf那样死记一些规定，比如如果没有得到指针，必须加上地址符，而如果已经得到了指针，又要确定不要加上地址符。这些完全可以交给C++编译器去做。编译器没别的什么事好做的，而你却不一样。最后要注意的是，象int这样的固定类型和象Rational这样的自定义类型在读写时方式是一样的。而你用sacnf和 printf试试看！
你所写的表示有理数的类的代码可能象下面这样：
class Rational {
public:
Rational(int numerator = 0, int denominator = 1);
...
private:
int n, d;// 分子，分母
friend ostream& operator<<(ostream& s, const Rational& );
};
ostream& operator<<(ostream& s, const Rational& r)
{
s<< r.n << '/' << r.d;
return s;
}
上面的代码涉及到operator<<的一些微妙(但很重要)的用法，这在本书其他地方详细讨论。例如：上面的 operator<<不是成员函数(条款19解释了为什么)，而且，传递给operator<<的不是Rational对象，而是定义为const的对象的引用(参见条款22)。operator>>的声明和实现也类似。
尽管我不大愿意承认，可有些情况下回到那些经过证明而且正确的老路上去还是很有意义的。第一，有些iostream的操作实现起来比相应的C stream效率要低，所以不同的选择会给你的程序有可能(虽然不一定，参见条款M16)带来很大的不同。但请牢记，这不是对所有的iostream而言，只是一些特殊的实现；参见条款M23。第二，在标准化的过程中，iostream库在底层做了很多修改(参见条款49)，所以对那些要求最大可移植性的应用程序来说，会发现不同的厂商遵循标准的程度也不同。第三，iostream库的类有构造函数而<stdio.h>里的函数没有，在某些涉及到静态对象初始化顺序的时候，如果可以确认不会带来隐患，用标准C库会更简单实用。
iostream库的类和函数所提供的类型安全和可扩展性的价值远远超过你当初的想象，所以不要仅仅因为你用惯了<stdio.h>而舍弃它。毕竟，转换到iostream后，你也不会忘掉<stdio.h>。
顺便说一句，本条款的标题没有打印错；我确实说的是<iostream>而非<iostream.h>。从技术上说，其实没有<iostream.h>这样的东西——标准化委员会在简化非C标准头文件时用<iostream>取代了它。他们这样做的原因在条款49进行了解释。还必须知道的是，如果编译器同时支持 <iostream>和<iostream.h>，那头文件名的使用会很微妙。例如，如果使用了#include <iostream>, 得到的是置于名字空间std(见条款28)下的iostream库的元素；如果使用#include <iostream.h>，得到的是置于全局空间的同样的元素。在全局空间获取元素会导致名字冲突，而设计名字空间的初衷正是用来避免这种名字冲突的发生。还有，打字时<iostream>比<iostream.h>少两个字，这也是很多人用它的原因。:)
条款3：尽量用new和delete而不用malloc和free
malloc和free(及其变体)会产生问题的原因在于它们太简单：他们不知道构造函数和析构函数。
假设用两种方法给一个包含10个string对象的数组分配空间，一个用malloc，另一个用new：
string *stringarray1 =
static_cast<string*>(malloc(10 * sizeof(string)));
string *stringarray2 = new string[10];
其结果是，stringarray1确实指向的是可以容纳10个string对象的足够空间，但内存里并没有创建这些对象。而且，如果你不从这种晦涩的语法怪圈(详见条款m4和m8的描述)里跳出来的话，你没有办法来初始化数组里的对象。换句话说，stringarray1其实一点用也没有。相反，stringarray2指向的是一个包含10个完全构造好的string对象的数组,每个对象可以在任何读取string的操作里安全使用。
假设你想了个怪招对stringarray1数组里的对象进行了初始化，那么在你后面的程序里你一定会这么做：
free(stringarray1);
delete [] stringarray2;// 参见条款5：这里为什么要加上个"[]"
调用free将会释放stringarray1指向的内存，但内存里的string对象不会调用析构函数。如果string对象象一般情况那样，自己已经分配了内存，那这些内存将会全部丢失。相反，当对stringarray2调用delete时，数组里的每个对象都会在内存释放前调用析构函数。
既然new和delete可以这么有效地与构造函数和析构函数交互，选用它们是显然的。
把 new和delete与malloc和free混在一起用也是个坏想法。对一个用new获取来的指针调用free，或者对一个用malloc获取来的指针调用delete，其后果是不可预测的。大家都知道“不可预测”的意思：它可能在开发阶段工作良好，在测试阶段工作良好，但也可能会最后在你最重要的客户的脸上爆炸。
new/delete和malloc/free的不兼容性常常会导致一些严重的复杂性问题。举个例子，<string.h>里通常有个strdup函数，它得到一个char*字符串然后返回其拷贝：
char * strdup(const char *ps); // 返回ps所指的拷贝
在有些地方，c和c++用的是同一个strdup版本，所以函数内部是用malloc分配内存。这样的话，一些不知情的c++程序员会在调用strdup后忽视了必须对strdup返回的指针进行free操作。为了防止这一情况，有些地方会专门为c++重写strdup，并在函数内部调用了new，这就要求其调用者记得最后用delete。你可以想象，这会导致多么严重的移植性问题，因为代码中strdup以不同的形式在不同的地方之间颠来倒去。
c++ 程序员和c程序员一样对代码重用十分感兴趣。大家都知道，有大量基于malloc和free写成的代码构成的c库都非常值得重用。在利用这些库时，最好是你不用负责去free掉由库自己malloc的内存，并且/或者，你不用去malloc库自己会free掉的内存，这样就太好了。其实，在c++程序里使用malloc和free没有错，只要保证用malloc得到的指针用free，或者用new得到的指针最后用delete来操作就可以了。千万别马虎地把new和free或malloc和delete混起来用，那只会自找麻烦。
既然malloc和free对构造函数和析构函数一无所知，把malloc/free和new/delete混起来用又象嘈杂拥挤的晚会那样难以控制，那么，你最好就什么时候都一心一意地使用new和delete吧。
条款4：尽量使用c++风格的注释
旧的c注释语法在c++里还可以用，c++新发明的行尾注释语法也有其过人之处。例如下面这种情形：
if ( a > b ) {
// int temp = a; // swap a and b
// a = b;
// b = temp;
}
假设你出于某种原因要注释掉这个代码块。从软件工程的角度看，写这段代码的程序员也做得很好，他最初的代码里也写了一个注释，以解释代码在做什么。用c++形式的句法来注释掉这个程序块时，嵌在里面的最初的注释不受影响，但如果选择c风格的注释就会发生严重的错误：
if ( a > b ) {
/* int temp = a; /* swap a and b */
a = b;
b = temp;
*/
}
请注意嵌在代码块里的注释是怎么无意间使本来想注释掉整个代码块的注释提前结束的。
c风格的注释当然还有它存在的价值。例如，它们在c和c++编译器都要处理的头文件中是无法替代的。尽管如此，只要有可能，你最好尽量用c++风格的注释。
值得指出的是，有些老的专门为c写的预处理程序不知道处理c++风格的注释，所以象下面这种情形时，事情就不会象预想的那样：
#define light_speedp 3e8 // m/sec (in a vacuum)
对于不熟悉c++的预处理程序来说，行尾的注释竟然成为了宏的一部分！当然，正象条款1所说的那样，你无论如何也不会用预处理来定义常量的。
第二章 内存管理
c++中涉及到的内存的管理问题可以归结为两方面：正确地得到它和有效地使用它。好的程序员会理解这两个问题为什么要以这样的顺序列出。因为执行得再快、体积再小的程序如果它不按你所想象地那样去执行，那也一点用处都没有。“正确地得到”的意思是正确地调用内存分配和释放程序；而“有效地使用”是指写特定版本的内存分配和释放程序。这里，“正确地得到”显得更重要一些。
然而说到正确性，c++其实从c继承了一个很严重的头疼病，那就是内存泄露隐患。虚拟内存是个很好的发明，但虚拟内存也是有限的，并不是每个人都可以最先抢到它。
在 c中，只要用malloc分配的内存没有用free返回，就会产生内存泄露。在c++中，肇事者的名字换成了new和delete，但情况基本上是一样的。当然，因为有了析构函数的出现，情况稍有改善，因为析构函数为所有将被摧毁的对象提供了一个方便的调用delete的场所。但这同时又带来了更多的烦恼，因为new和delete是隐式地调用构造函数和析构函数的。而且，因为可以在类内和类外自定义new和delete操作符，这又带来了复杂性，增加了出错的机会。下面的条款(还有条款m8)将告诉你如何避免产生那些普遍发生的问题。
条款5：对应的new和delete要采用相同的形式
下面的语句有什么错？
string *stringarray = new string[100];
...
delete stringarray;
一切好象都井然有序——一个new对应着一个delete——然而却隐藏着很大的错误：程序的运行情况将是不可预测的。至少，stringarray指向的100个string对象中的99个不会被正确地摧毁，因为他们的析构函数永远不会被调用。
用 new的时候会发生两件事。首先，内存被分配(通过operator new 函数，详见条款7-10和条款m8)，然后，为被分配的内存调用一个或多个构造函数。用delete的时候，也有两件事发生：首先，为将被释放的内存调用一个或多个析构函数，然后，释放内存(通过operator delete 函数，详见条款8和m8)。对于 delete来说会有这样一个重要的问题：内存中有多少个对象要被删除？答案决定了将有多少个析构函数会被调用。
这个问题简单来说就是：要被删除的指针指向的是单个对象呢，还是对象数组？这只有你来告诉delete。如果你在用delete时没用括号，delete就会认为指向的是单个对象，否则，它就会认为指向的是一个数组：
string *stringptr1 = new string;
string *stringptr2 = new string[100];
...
delete stringptr1;// 删除一个对象
delete [] stringptr2;// 删除对象数组
如果你在stringptr1前加了"[]"会怎样呢？答案是：那将是不可预测的；如果你没在stringptr2前没加上"[]"又会怎样呢？答案也是：不可预测。而且对于象int这样的固定类型来说，结果也是不可预测的，即使这样的类型没有析构函数。所以，解决这类问题的规则很简单：如果你调用new时用了[]，调用delete时也要用[]。如果调用new时没有用[]，那调用delete时也不要用[]。
在写一个包含指针数据成员，并且提供多个构造函数的类时，牢记这一规则尤其重要。因为这样的话，你就必须在所有初始化指针成员的构造函数里采用相同的new的形式。否则，析构函数里将采用什么形式的delete呢？关于这一话题的进一步阐述，参见条款11。
这个规则对喜欢用typedef的人来说也很重要，因为写typedef的程序员必须告诉别人，用new创建了一个typedef定义的类型的对象后，该用什么形式的delete来删除。举例如下：
typedef string addresslines[4]; //一个人的地址，共4行，每行一个string
//因为addresslines是个数组，使用new:
string *pal = new addresslines; // 注意"new addresslines"返回string*, 和
// "new string[4]"返回的一样
delete时必须以数组形式与之对应：
delete pal;// 错误!
delete [] pal;// 正确
条款6：析构函数里对指针成员调用delete
大多数情况下，执行动态内存分配的的类都在构造函数里用new分配内存，然后在析构函数里用delete释放内存。最初写这个类的时候当然不难做，你会记得最后对在所有构造函数里分配了内存的所有成员使用delete。
然而，这个类经过维护、升级后，情况就会变得困难了，因为对类的代码进行修改的程序员不一定就是最早写这个类的人。而增加一个指针成员意味着几乎都要进行下面的工作：
·在每个构造函数里对指针进行初始化。对于一些构造函数，如果没有内存要分配给指针的话，指针要被初始化为0(即空指针)。
·删除现有的内存，通过赋值操作符分配给指针新的内存。
·在析构函数里删除指针。
如果在构造函数里忘了初始化某个指针，或者在赋值操作的过程中忘了处理它，问题会出现得很快，很明显，所以在实践中这两个问题不会那么折磨你。但是，如果在析构函数里没有删除指针，它不会表现出很明显的外部症状。相反，它可能只是表现为一点微小的内存泄露，并且不断增长，最后吞噬了你的地址空间，导致程序夭折。因为这种情况经常不那么引人注意，所以每增加一个指针成员到类里时一定要记清楚。
另外，删除空指针是安全的(因为它什么也没做)。所以，在写构造函数，赋值操作符，或其他成员函数时，类的每个指针成员要么指向有效的内存，要么就指向空，那在你的析构函数里你就可以只用简单地delete掉他们，而不用担心他们是不是被new过。
当然对本条款的使用也不要绝对。例如，你当然不会用delete去删除一个没有用new来初始化的指针，而且，就象用智能指针对象时不用劳你去删除一样，你也永远不会去删除一个传递给你的指针。换句话说，除非类成员最初用了new,否则是不用在析构函数里用delete的。
说到智能指针，这里介绍一种避免必须删除指针成员的方法，即把这些成员用智能指针对象来代替，比如c++标准库里的auto_ptr。想知道它是如何工作的，看看条款m9和m10。
条款7：预先准备好内存不够的情况
operator new在无法完成内存分配请求时会抛出异常(以前的做法一般是返回0，一些旧一点的编译器还这么做。你愿意的话也可以把你的编译器设置成这样。关于这个话题我将推迟到本条款的结尾处讨论)。大家都知道，处理内存不够所产生的异常真可以算得上是个道德上的行为，但实际做起来又会象刀架在脖子上那样痛苦。所以，你有时会不去管它，也许一直没去管它。但你心里一定还是深深地隐藏着一种罪恶感：万一new真的产生了异常怎么办？
你会很自然地想到处理这种情况的一种方法，即回到以前的老路上去，使用预处理。例如，c的一种常用的做法是，定义一个类型无关的宏来分配内存并检查分配是否成功。对于c++来说，这个宏看起来可能象这样：
#define new(ptr, type) \
try { (ptr) = new type; } \
catch (std::bad_alloc&) { assert(0); }
（“ 慢！std::bad_alloc是做什么的？”你会问。bad_alloc是operator new不能满足内存分配请求时抛出的异常类型，std是bad_alloc所在的名字空间(见条款28)的名称。“好！”你会继续问，“assert又有什么用？”如果你看看标准c头文件<assert.h>(或与它相等价的用到了名字空间的版本<cassert>，见条款 49)，就会发现assert是个宏。这个宏检查传给它的表达式是否非零，如果不是非零值，就会发出一条出错信息并调用abort。assert只是在没定义标准宏ndebug的时候，即在调试状态下才这么做。在产品发布状态下，即定义了ndebug的时候，assert什么也不做，相当于一条空语句。所以你只能在调试时才能检查断言(assertion)）。
new宏不但有着上面所说的通病，即用assert去检查可能发生在已发布程序里的状态(然而任何时候都可能发生内存不够的情况)，同时，它还在c++里有另外一个缺陷：它没有考虑到new有各种各样的使用方式。例如，想创建类型t 对象，一般有三种常见的语法形式，你必须对每种形式可能产生的异常都要进行处理：
new t;
new t(constructor arguments);
new t[size];
这里对问题大大进行了简化，因为有人还会自定义(重载)operator new，所以程序里会包含任意个使用new的语法形式。
那么，怎么办？如果想用一个很简单的出错处理方法，可以这么做：当内存分配请求不能满足时，调用你预先指定的一个出错处理函数。这个方法基于一个常规，即当 operator new不能满足请求时，会在抛出异常之前调用客户指定的一个出错处理函数——一般称为new-handler函数。(operator new实际工作起来要复杂一些，详见条款8)
指定出错处理函数时要用到set_new_handler函数，它在头文件<new>里大致是象下面这样定义的：
typedef void (*new_handler)();
new_handler set_new_handler(new_handler p) throw();
可以看到，new_handler是一个自定义的函数指针类型，它指向一个没有输入参数也没有返回值的函数。set_new_handler则是一个输入并返回new_handler类型的函数。
set_new_handler的输入参数是operator new分配内存失败时要调用的出错处理函数的指针，返回值是set_new_handler没调用之前就已经在起作用的旧的出错处理函数的指针。
可以象下面这样使用set_new_handler：
// function to call if operator new can't allocate enough memory
void nomorememory()
{
cerr << "unable to satisfy request for memory\n";
abort();
}
int main()
{
set_new_handler(nomorememory);
int *pbigdataarray = new int[100000000];
...
}
假如operator new不能为100,000,000个整数分配空间，nomorememory将会被调用，程序发出一条出错信息后终止。这就比简单地让系统内核产生错误信息来结束程序要好。(顺便考虑一下，假如cerr在写错误信息的过程中要动态分配内存，那将会发生什么...)
operator new不能满足内存分配请求时，new-handler函数不只调用一次，而是不断重复，直至找到足够的内存。实现重复调用的代码在条款8里可以看到，这里我用描述性的的语言来说明：一个设计得好的new-handler函数必须实现下面功能中的一种。
· 产生更多的可用内存。这将使operator new下一次分配内存的尝试有可能获得成功。实施这一策略的一个方法是：在程序启动时分配一个大的内存块，然后在第一次调用new-handler时释放。释放时伴随着一些对用户的警告信息，如内存数量太少，下次请求可能会失败，除非又有更多的可用空间。
·安装另一个不同的new- handler函数。如果当前的new-handler函数不能产生更多的可用内存，可能它会知道另一个new-handler函数可以提供更多的资源。这样的话，当前的new-handler可以安装另一个new-handler来取代它(通过调用set_new_handler)。下一次 operator new调用new-handler时，会使用最近安装的那个。(这一策略的另一个变通办法是让new-handler可以改变它自己的运行行为，那么下次调用时，它将做不同的事。方法是使new-handler可以修改那些影响它自身行为的静态或全局数据。)
·卸除new-handler。也就是传递空指针给set_new_handler。没有安装new-handler，operator new分配内存不成功时就会抛出一个标准的std::bad_alloc类型的异常。
· 抛出std::bad_alloc或从std::bad_alloc继承的其他类型的异常。这样的异常不会被operator new捕捉，所以它们会被送到最初进行内存请求的地方。(抛出别的不同类型的异常会违反operator new异常规范。规范中的缺省行为是调用abort，所以new-handler要抛出一个异常时，一定要确信它是从std::bad_alloc继承来的。想更多地了解异常规范，参见条款m14。)
·没有返回。典型做法是调用abort或exit。abort/exit可以在标准c库中找到(还有标准c++库，参见条款49)。
上面的选择给了你实现new-handler函数极大的灵活性。
处理内存分配失败的情况时采取什么方法，取决于要分配的对象的类：
class x {
public:
static void
outofmemory();
...
};
class y {
public:
static void outofmemory();
...
};
x* p1 = new x; // 若分配成功，调用x::outofmemory
y* p2 = new y; // 若分配不成功，调用y::outofmemory
c++ 不支持专门针对于类的new-handler函数，而且也不需要。你可以自己来实现它，只要在每个类中提供自己版本的set_new_handler和 operator new。类的set_new_handler可以为类指定new-handler(就象标准的set_new_handler指定全局new- handler一样)。类的operator new则保证为类的对象分配内存时用类的new-handler取代全局new-handler。
假设处理类x内存分配失败的情况。因为operator new对类型x的对象分配内存失败时，每次都必须调用出错处理函数，所以要在类里声明一个new_handler类型的静态成员。那么类x看起来会象这样：
class x {
public:
static new_handler set_new_handler(new_handler p);
static void * operator new(size_t size);
private:
static new_handler currenthandler;
};
类的静态成员必须在类外定义。因为想借用静态对象的缺省初始化值0，所以定义x::currenthandler时没有去初始化。
new_handler x::currenthandler; //缺省设置currenthandler为0(即null)
类x中的set_new_handler函数会保存传给它的任何指针，并返回在调用它之前所保存的任何指针。这正是标准版本的set_new_handler所做的：
new_handler x::set_new_handler(new_handler p)
{
new_handler oldhandler = currenthandler;
currenthandler = p;
return oldhandler;
}
最后看看x的operator new所做的：
1. 调用标准set_new_handler函数，输入参数为x的出错处理函数。这使得x的new-handler函数成为全局new-handler函数。注意下面的代码中，用了"::"符号显式地引用std空间(标准set_new_handler函数就存在于std空间)。
2. 调用全局operator new分配内存。如果第一次分配失败，全局operator new会调用x的new-handler，因为它刚刚(见1.)被安装成为全局new-handler。如果全局operator new最终未能分配到内存，它抛出std::bad_alloc异常，x的operator new会捕捉到它。x的operator new然后恢复最初被取代的全局new-handler函数，最后以抛出异常返回。
3. 假设全局operator new为类型x的对象分配内存成功，, x的operator new会再次调用标准set_new_handler来恢复最初的全局出错处理函数。最后返回分配成功的内存的指针。
c++是这么做的：
void * x::operator new(size_t size)
{
new_handler globalhandler = // 安装x的new_handler
std::set_new_handler(currenthandler);
void *memory;
try { // 尝试分配内存
memory = ::operator new(size);
}
catch (std::bad_alloc&) { // 恢复旧的new_handler
std::set_new_handler(globalhandler);
throw; // 抛出异常
}
std::set_new_handler(globalhandler); // 恢复旧的new_handler
return memory;
}
如果你对上面重复调用std::set_new_handler看不顺眼，可以参见条款m9来除去它们。
使用类x的内存分配处理功能时大致如下：
void nomorememory();// x的对象分配内存失败时调用的new_handler函数的声明
x::set_new_handler(nomorememory);
// 把nomorememory设置为x的
// new-handling函数
x *px1 = new x;
// 如内存分配失败，
// 调用nomorememory
string *ps = new string;
// 如内存分配失败，调用全局new-handling函数
x::set_new_handler(0);
// 设x的new-handling函数为空
x *px2 = new x;
// 如内存分配失败，立即抛出异常
// (类x没有new-handling函数)
你会注意到，处理以上类似情况，如果不考虑类的话，实现代码是一样的，这就很自然地想到在别的地方也能重用它们。正如条款41所说明的，继承和模板可以用来设计可重用代码。在这里，我们把两种方法结合起来使用，从而满足了你的要求。
你只要创建一个“混合风格”(mixin-style)的基类，这种基类允许子类继承它某一特定的功能——这里指的是建立一个类的new-handler的功能。之所以设计一个基类，是为了让所有的子类可以继承set_new_handler和operator new功能，而设计模板是为了使每个子类有不同的currenthandler数据成员。这听起来很复杂，不过你会看到代码其实很熟悉。区别只不过是它现在可以被任何类重用了。
template<class t> // 提供类set_new_handler支持的
class newhandlersupport { // 混合风格”的基类
public:
static new_handler set_new_handler(new_handler p);
static void * operator new(size_t size);
private:
static new_handler currenthandler;
};
template<class t>
new_handler newhandlersupport<t>::set_new_handler(new_handler p)
{
new_handler oldhandler = currenthandler;
currenthandler = p;
return oldhandler;
}
template<class t>
void * newhandlersupport<t>::operator new(size_t size)
{
new_handler globalhandler =
std::set_new_handler(currenthandler);
void *memory;
try {
memory = ::operator new(size);
}
catch (std::bad_alloc&) {
std::set_new_handler(globalhandler);
throw;
}
std::set_new_handler(globalhandler);
return memory;
}
// this sets each currenthandler to 0
template<class t>
new_handler newhandlersupport<t>::currenthandler;
有了这个模板类，对类x加上set_new_handler功能就很简单了：只要让x从newhandlersupport<x>继承：
// note inheritance from mixin base class template. (see
// my article on counting objects for information on why
// private inheritance might be preferable here.)
class x: public newhandlersupport<x> {
... // as before, but no declarations for
}; // set_new_handler or operator new
使用x的时候依然不用理会它幕后在做些什么；老代码依然工作。这很好！那些你常不去理会的东西往往是最可信赖的。
使用set_new_handler是处理内存不够情况下一种方便，简单的方法。这比把每个new都包装在try模块里当然好多了。而且，newhandlersupport这样的模板使得向任何类增加一个特定的new-handler变得更简单。“混合风格”的继承不可避免地将话题引入到多继承上去，在转到这个话题前，你一定要先阅读条款43。
1993年前，c++一直要求在内存分配失败时operator new要返回0，现在则是要求operator new抛出std::bad_alloc异常。很多c++程序是在编译器开始支持新规范前写的。c++标准委员会不想放弃那些已有的遵循返回0规范的代码，所以他们提供了另外形式的operator new(以及operator new[]——见条款8)以继续提供返回0功能。这些形式被称为“无抛出”，因为他们没用过一个throw，而是在使用new的入口点采用了 nothrow对象：
class widget { ... };
widget *pw1 = new widget;// 分配失败抛出std::bad_alloc if
if (pw1 == 0) ... // 这个检查一定失败
widget *pw2 = new (nothrow) widget; // 若分配失败返回0
if (pw2 == 0) ... // 这个检查可能会成功
不管是用“正规”(即抛出异常)形式的new还是“无抛出”形式的new，重要的是你必须为内存分配失败做好准备。最简单的方法是使用set_new_handler，因为它对两种形式都有用。
条款8: 写operator new和operator delete时要遵循常规
自己重写 operator new时(条款10解释了为什么有时要重写它)，很重要的一点是函数提供的行为要和系统缺省的operator new一致。实际做起来也就是：要有正确的返回值；可用内存不够时要调用出错处理函数(见条款7)；处理好0字节内存请求的情况。此外，还要避免不小心隐藏了标准形式的new，不过这是条款9的话题。
有关返回值的部分很简单。如果内存分配请求成功，就返回指向内存的指针；如果失败，则遵循条款7的规定抛出一个std::bad_alloc类型的异常。
但事情也不是那么简单。因为operator new实际上会不只一次地尝试着去分配内存，它要在每次失败后调用出错处理函数，还期望出错处理函数能想办法释放别处的内存。只有在指向出错处理函数的指针为空的情况下，operator new才抛出异常。
另外，c++标准要求，即使在请求分配0字节内存时，operator new也要返回一个合法指针。(实际上，这个听起来怪怪的要求确实给c++语言其它地方带来了简便)
这样，非类成员形式的operator new的伪代码看起来会象下面这样：
void * operator new(size_t size) // operator new还可能有其它参数
{
if (size == 0) { // 处理0字节请求时，
size = 1; // 把它当作1个字节请求来处理
}
while (1) {
分配size字节内存;
if (分配成功)
return (指向内存的指针);
// 分配不成功，找出当前出错处理函数
new_handler globalhandler = set_new_handler(0);
set_new_handler(globalhandler);
if (globalhandler) (*globalhandler)();
else throw std::bad_alloc();
}
}
处理零字节请求的技巧在于把它作为请求一个字节来处理。这看起来也很怪，但简单，合法，有效。而且，你又会多久遇到一次零字节请求的情况呢？
你又会奇怪上面的伪代码中为什么把出错处理函数置为0后又立即恢复。这是因为没有办法可以直接得到出错处理函数的指针，所以必须通过调用set_new_handler来找到。办法很笨但也有效。
条款7提到operator new内部包含一个无限循环，上面的代码清楚地说明了这一点——while (1)将导致无限循环。跳出循环的唯一办法是内存分配成功或出错处理函数完成了条款7所描述的事件中的一种：得到了更多的可用内存；安装了一个新的 new-handler(出错处理函数)；卸除了new-handler；抛出了一个std::bad_alloc或其派生类型的异常；或者返回失败。现在明白了为什么new-handler必须做这些工作中的一件。如果不做，operator new里面的循环就不会结束。
很多人没有认识到的一点是operator new经常会被子类继承。这会导致某些复杂性。上面的伪代码中，函数会去分配size字节的内存(除非size为0)。size很重要，因为它是传递给函数的参数。但是大多数针对类所写的operator new(包括条款10中的那种)都是只为特定的类设计的，不是为所有的类，也不是为它所有的子类设计的。这意味着，对于一个类x的operator new来说，函数内部的行为在涉及到对象的大小时，都是精确的sizeof(x)：不会大也不会小。但由于存在继承，基类中的operator new可能会被调用去为一个子类对象分配内存：
class base {
public:
static void * operator new(size_t size);
...
};
class derived: public base // derived类没有声明operator new
{ ... }; //
derived *p = new derived; // 调用base::operator new
如果base类的operator new不想费功夫专门去处理这种情况——这种情况出现的可能性不大——那最简单的办法是把这个“错误”数量的内存分配请求转给标准operator new来处理，象下面这样：
void * base::operator new(size_t size)
{
if (size != sizeof(base)) // 如果数量“错误”，让标准operator new
return ::operator new(size); // 去处理这个请求
//
... // 否则处理这个请求
}
“ 停!”我听见你在叫，“你忘了检查一种虽然不合理但是有可能出现的一种情况——size有可能为零!”是的，我没检查，但拜托下次再叫出声的时候不要这么文绉绉的。:)但实际上检查还是做了，只不过融合到size != sizeof(base)语句中了。c++标准很怪异，其中之一就是规定所以独立的(freestanding)类的大小都是非零值。所以 sizeof(base)永远不可能是零(即使base类没有成员)，如果size为零，请求会转到::operator new，由它来以一种合理的方式对请求进行处理。(有趣的是，如果base不是独立的类，sizeof(base)有可能是零，详细说明参见"my article on counting objects")。
如果想控制基于类的数组的内存分配，必须实现operator new的数组形式——operator new[](这个函数常被称为“数组new”，因为想不出"operator new[]")该怎么发音)。写operator new[]时，要记住你面对的是“原始”内存，不能对数组里还不存在的对象进行任何操作。实际上，你甚至还不知道数组里有多少个对象，因为不知道每个对象有多大。基类的operator new[]会通过继承的方式被用来为子类对象的数组分配内存，而子类对象往往比基类要大。所以，不能想当然认为base::operator new[]里的每个对象的大小都是sizeof(base)，也就是说，数组里对象的数量不一定就是(请求字节数)/sizeof(base)。关于 operator new[]的详细介绍参见条款m8。
重写operator new(和operator new[])时所有要遵循的常规就这些。对于operator delete(以及它的伙伴operator delete[])，情况更简单。所要记住的只是，c++保证删除空指针永远是安全的，所以你要充分地应用这一保证。下面是非类成员形式的 operator delete的伪代码：
void operator delete(void *rawmemory)
{
if (rawmemory == 0) return; file://如/果指针为空，返回
//
释放rawmemory指向的内存;
return;
}
这个函数的类成员版本也简单，只是还必须检查被删除的对象的大小。假设类的operator new将“错误”大小的分配请求转给::operator new，那么也必须将“错误”大小的删除请求转给::operator delete：
class base { // 和前面一样，只是这里声明了
public: // operator delete
static void * operator new(size_t size);
static void operator delete(void *rawmemory, size_t size);
...
};
void base::operator delete(void *rawmemory, size_t size)
{
if (rawmemory == 0) return; // 检查空指针
if (size != sizeof(base)) { // 如果size"错误"，
::operator delete(rawmemory); // 让标准operator来处理请求
return;
}
释放指向rawmemory的内存;
return;
}
可见，有关operator new和operator delete(以及他们的数组形式)的规定不是那么麻烦，重要的是必须遵守它。只要内存分配程序支持new-handler函数并正确地处理了零内存请求，就差不多了；如果内存释放程序又处理了空指针，那就没其他什么要做的了。至于在类成员版本的函数里增加继承支持，那将很快就可以完成。
条款9: 避免隐藏标准形式的new
因为内部范围声明的名称会隐藏掉外部范围的相同的名称，所以对于分别在类的内部
和全局声明的两个相同名字的函数f来说，类的成员函数会隐藏掉全局函数：
void f(); // 全局函数
class x {
public:
void f(); // 成员函数
};
x x;
f(); // 调用 f
x.f(); // 调用 x::f
这不会令人惊讶，也不会导致混淆，因为调用全局函数和成员函数时总是采用不同的
语法形式。然而如果你在类里增加了一个带多个参数的operator new函数，结果就有
可能令人大吃一惊。
class x {
public:
void f();
// operator new的参数指定一个
// new-hander(new的出错处理)函数
static void * operator new(size_t size, new_handler p);
};
void specialerrorhandler(); // 定义在别的地方
x *px1 =
new (specialerrorhandler) x; // 调用x::operator new
x *px2 = new x; // 错误!
在类里定义了一个称为“operator new”的函数后，会不经意地阻止了对标准new的访
问。条款50解释了为什么会这样，这里我们更关心的是如何想个办法避免这个问题。
一个办法是在类里写一个支持标准new调用方式的operator new，它和标准new做同样
的事。这可以用一个高效的内联函数来封装实现。
class x {
public:
void f();
static void * operator new(size_t size, new_handler p);
static void * operator new(size_t size)
{ return ::operator new(size); }
};
x *px1 =
new (specialerrorhandler) x; // 调用 x::operator
// new(size_t, new_handler)
x* px2 = new x; // 调用 x::operator
// new(size_t)
另一种方法是为每一个增加到operator new的参数提供缺省值(见条款24)：
class x {
public:
void f();
static
void * operator new(size_t size, // p缺省值为0
new_handler p = 0); //
};
x *px1 = new (specialerrorhandler) x; // 正确
x* px2 = new x; // 也正确
无论哪种方法，如果以后想对“标准”形式的new定制新的功能，只需要重写这个函数。
调用者重新编译链接后就可以使用新功能了。
条款10: 如果写了operator new就要同时写operator delete
让我们回过头去看看这样一个基本问题：为什么有必要写自己的operator new和operator delete？
答案通常是：为了效率。缺省的operator new和operator delete具有非常好的通用性，它的这种灵活性也使得在某些特定的场合下，可以进一步改善它的性能。尤其在那些需要动态分配大量的但很小的对象的应用程序里，情况更是如此。
例如有这样一个表示飞机的类：类airplane只包含一个指针，它指向的是飞机对象的实际描述(此技术在条款34进行说明)：
class airplanerep { ... }; // 表示一个飞机对象
//
class airplane {
public:
...
private:
airplanerep *rep; // 指向实际描述
};
一个airplane对象并不大，它只包含一个指针（正如条款14和m24所说明的，如果airplane类声明了虚函数，会隐式包含第二个指针）。但当调用operator new来分配一个airplane对象时，得到的内存可能要比存储这个指针（或一对指针）所需要的要多。之所以会产生这种看起来很奇怪的行为，在于 operator new和operator delete之间需要互相传递信息。
因为缺省版本的operator new是一种通用型的内存分配器，它必须可以分配任意大小的内存块。同样，operator delete也要可以释放任意大小的内存块。operator delete想弄清它要释放的内存有多大，就必须知道当初operator new分配的内存有多大。有一种常用的方法可以让operator new来告诉operator delete当初分配的内存大小是多少，就是在它所返回的内存里预先附带一些额外信息，用来指明被分配的内存块的大小。也就是说，当你写了下面的语句，
airplane *pa = new airplane;
你不会得到一块看起来象这样的内存块：
pa——> airplane对象的内存
而是得到象这样的内存块：
pa——> 内存块大小数据 + airplane对象的内存
对于象airplane这样很小的对象来说，这些额外的数据信息会使得动态分配对象时所需要的的内存的大小翻番（特别是类里没有虚拟函数的时候）。
如果软件运行在一个内存很宝贵的环境中，就承受不起这种奢侈的内存分配方案了。为airplane类专门写一个operator new，就可以利用每个airplane的大小都相等的特点，不必在每个分配的内存块上加上附带信息了。
具体来说，有这样一个方法来实现你的自定义的operator new：先让缺省operator new分配一些大块的原始内存，每块的大小都足以容纳很多个airplane对象。airplane对象的内存块就取自这些大的内存块。当前没被使用的内存块被组织成链表——称为自由链表——以备未来airplane使用。听起来好象每个对象都要承担一个next域的开销（用于支持链表），但不会：rep 域的空间也被用来存储next指针（因为只是作为airplane对象来使用的内存块才需要rep指针；同样，只有没作为airplane对象使用的内存块才需要next指针），这可以用union来实现。
具体实现时，就要修改airplane的定义，从而支持自定义的内存管理。可以这么做：
class airplane { // 修改后的类 — 支持自定义的内存管理
public: //
static void * operator new(size_t size);
...
private:
union {
airplanerep *rep; // 用于被使用的对象
airplane *next; // 用于没被使用的（在自由链表中）对象
};
// 类的常量，指定一个大的内存块中放多少个
// airplane对象，在后面初始化
static const int block_size;
static airplane *headoffreelist;
};
上面的代码增加了的几个声明：一个operator new函数，一个联合（使得rep和next域占用同样的空间），一个常量（指定大内存块的大小），一个静态指针（跟踪自由链表的表头）。表头指针声明为静态成员很重要，因为整个类只有一个自由链表，而不是每个airplane对象都有。
下面该写operator new函数了：
void * airplane::operator new(size_t size)
{
// 把“错误”大小的请求转给::operator new()处理;
// 详见条款8
if (size != sizeof(airplane))
return ::operator new(size);
airplane *p = // p指向自由链表的表头
headoffreelist; //
// p 若合法，则将表头移动到它的下一个元素
//
if (p)
headoffreelist = p->next;
else {
// 自由链表为空，则分配一个大的内存块，
// 可以容纳block_size个airplane对象
airplane *newblock =
static_cast<airplane*>(::operator new(block_size *
sizeof(airplane)));
// 将每个小内存块链接起来形成一个新的自由链表
// 跳过第0个元素，因为它要被返回给operator new的调用者
//
for (int i = 1; i < block_size-1; ++i)
newblock[i].next = &newblock[i+1];
// 用空指针结束链表
newblock[block_size-1].next = 0;
// p 设为表的头部，headoffreelist指向的
// 内存块紧跟其后
p = newblock;
headoffreelist = &newblock[1];
}
return p;
}
如果你读了条款8，就会知道在operator new不能满足内存分配请求时，会执行一系列与new-handler函数和例外有关的例行性动作。上面的代码没有这些步骤，这是因为operator new管理的内存都是从::operator new分配来的。这意味着只有::operator new失败时，operator new才会失败。而如果::operator new失败，它会去执行new-handler的动作（可能最后以抛出异常结束），所以不需要airplane的operator new也去处理。换句话说，其实new-handler的动作都还在，你只是没看见，它隐藏在::operator new里。
有了operator new，下面要做的就是给出airplane的静态数据成员的定义：
airplane *airplane::headoffreelist;
const int airplane::block_size = 512;
没必要显式地将headoffreelist设置为空指针，因为静态成员的初始值都被缺省设为0。block_size决定了要从::operator new获得多大的内存块。
这个版本的operator new将会工作得非常好。它为airplane对象分配的内存要比缺省operator new更少，而且运行得更快，可能会快2次方的等级。这没什么奇怪的，通用型的缺省operator new必须应付各种大小的内存请求，还要处理内部外部的碎片；而你的operator new只用操作链表中的一对指针。抛弃灵活性往往可以很容易地换来速度。
下面我们将讨论operator delete。还记得operator delete吗？本条款就是关于operator delete的讨论。但直到现在为止，airplane类只声明了operator new，还没声明operator delete。想想如果写了下面的代码会发生什么:
airplane *pa = new airplane; // 调用
// airplane::operator new
...
delete pa; // 调用 ::operator delete
读这段代码时，如果你竖起耳朵，会听到飞机撞毁燃烧的声音，还有程序员的哭泣。问题出在operator new（在airplane里定义的那个）返回了一个不带头信息的内存的指针，而operator delete（缺省的那个）却假设传给它的内存包含头信息。这就是悲剧产生的原因。
这个例子说明了一个普遍原则：operator new和operator delete必须同时写，这样才不会出现不同的假设。如果写了一个自己的内存分配程序，就要同时写一个释放程序。（关于为什么要遵循这条规定的另一个理由，参见article on counting objects一文的the sidebar on placement章节）
因而，继续设计airplane类如下：
class airplane { // 和前面的一样，只不过增加了一个
public: // operator delete的声明
...
static void operator delete(void *deadobject,
size_t size);
};
// 传给operator delete的是一个内存块, 如果
// 其大小正确，就加到自由内存块链表的最前面
//
void airplane::operator delete(void *deadobject,
size_t size)
{
if (deadobject == 0) return; // 见条款 8
if (size != sizeof(airplane)) { // 见条款 8
::operator delete(deadobject);
return;
}
airplane *carcass =
static_cast<airplane*>(deadobject);
carcass->next = headoffreelist;
headoffreelist = carcass;
}
因为前面在operator new里将“错误”大小的请求转给了全局operator new（见条款8），那么这里同样要将“错误”大小的对象交给全局operator delete来处理。如果不这样，就会重现你前面费尽心思想避免的那种问题——new和delete句法上的不匹配。
有趣的是，如果要删除的对象是从一个没有虚析构函数的类继承而来的，那传给operator delete的size_t值有可能不正确。这就是必须保证基类必须要有虚析构函数的原因，此外条款14还列出了第二个、理由更充足的原因。这里只要简单地记住，基类如果遗漏了虚拟构函数，operator delete就有可能工作不正确。
所有一切都很好，但从你皱起的眉头我可以知道你一定在担心内存泄露。有着大量开发经验的你不会没注意到，airplane的operator new调用::operator new 得到了大块内存，但airplane的operator delete却没有释放它们。内存泄露！内存泄露！我分明听见了警钟在你脑海里回响。
但请仔细听我回答，这里没有内存泄露！
引起内存泄露的原因在于内存分配后指向内存的指针丢失了。如果没有垃圾处理或其他语言之外的机制，这些内存就不会被收回。但上面的设计没有内存泄露，因为它决不会出现内存指针丢失的情况。每个大内存块首先被分成airplane大小的小块，然后这些小块被放在自由链表上。当客户调用 airplane::operator new时，小块被自由链表移除，客户得到指向小块的指针。当客户调用operator delete时，小块被放回到自由链表上。采用这种设计，所有的内存块要不被airplane对象使用（这种情况下，是由客户来负责避免内存泄露），要不就在自由链表上（这种情况下内存块有指针）。所以说这里没有内存泄露。
然而确实，::operator new返回的内存块是从来没有被airplane::operator delete释放，这个内存块有个名字，叫内存池。但内存泄漏和内存池有一个重要的不同之处。内存泄漏会无限地增长，即使客户循规蹈矩；而内存池的大小决不会超过客户请求内存的最大值。
修改airplane的内存管理程序使得::operator new返回的内存块在不被使用时自动释放并不难，但这里不会这么做，这有两个原因：
第一个原因和你自定义内存管理的初衷有关。你有很多理由去自定义内存管理，最基本的一条是你确认缺省的operator new和operator delete使用了太多的内存或（并且）运行很慢。和采用内存池策略相比，跟踪和释放那些大内存块所写的每一个额外的字节和每一条额外的语句都会导致软件运行更慢，用的内存更多。在设计性能要求很高的库或程序时，如果你预计内存池的大小会在一个合理的范围之内，那采用内存池的方法再好不过了。
第二个原因和处理一些不合理的程序行为有关。假设airplane的内存管理程序被修改了，airplane的operator delete可以释放任何没有对象存在的大块的内存。那看下面的程序：
int main()
{
airplane *pa = new airplane; // 第一次分配: 得到大块内存，
// 生成自由链表，等
delete pa; // 内存块空;
// 释放它
pa = new airplane; // 再次得到大块内存,
// 生成自由链表，等
delete pa; // 内存块再次空，
// 释放
... // 你有了想法...
return 0;
}
这个糟糕的小程序会比用缺省的operator new和operator delete写的程序运行得还慢，占用还要多的内存，更不要和用内存池写的程序比了。
当然有办法处理这种不合理的情况，但考虑的特殊情况越多，就越有可能要重新实现内存管理函数，而最后你又会得到什么呢？内存池不能解决所有的内存管理问题，在很多情况下是很适合的。
实际开发中，你会经常要给许多不同的类实现基于内存池的功能。你会想，“一定有什么办法把这种固定大小内存的分配器封装起来，从而可以方便地使用”。是的，有办法。虽然我在这个条款已经唠叨这么长时间了，但还是要简单介绍一下，具体实现留给读者做练习。
下面简单给出了一个pool类的最小接口（见条款18），pool类的每个对象是某类对象（其大小在pool的构造函数里指定）的内存分配器。
class pool {
public:
pool(size_t n); // 为大小为n的对象创建
// 一个分配器
void * alloc(size_t n) ; // 为一个对象分配足够内存
// 遵循条款8的operator new常规
void free( void *p, size_t n); // 将p所指的内存返回到内存池；
// 遵循条款8的operator delete常规
~pool(); // 释放内存池中全部内存
};
这个类支持pool对象的创建，执行分配和释放操作，以及被摧毁。pool对象被摧毁时，会释放它分配的所有内存。这就是说，现在有办法避免 airplane的函数里所表现的内存泄漏似的行为了。然而这也意味着，如果pool的析构函数调用太快（使用内存池的对象没有全部被摧毁），一些对象就会发现它正在使用的内存猛然间没了。这造成的结果通常是不可预测的。
有了这个pool类，即使java程序员也可以不费吹灰之力地在airplane类里增加自己的内存管理功能：
class airplane {
public:
... // 普通airplane功能
static void * operator new(size_t size);
static void operator delete(void *p, size_t size);
private:
airplanerep *rep; // 指向实际描述的指针
static pool mempool; // airplanes的内存池
};
inline void * airplane::operator new(size_t size)
{ return mempool.alloc(size); }
inline void airplane::operator delete(void *p,
size_t size)
{ mempool.free(p, size); }
// 为airplane对象创建一个内存池，
// 在类的实现文件里实现
pool airplane::mempool(sizeof(airplane));
这个设计比前面的要清楚、干净得多，因为airplane类不再和非airplane的代码混在一起。union，自由链表头指针，定义原始内存块大小的常量都不见了，它们都隐藏在它们应该呆的地方——pool类里。让写pool的程序员去操心内存管理的细节吧，你的工作只是让airplane类正常工作。
现在应该明白了，自定义的内存管理程序可以很好地改善程序的性能，而且它们可以封装在象pool这样的类里。但请不要忘记主要的一点，operator new和operator delete需要同时工作，那么你写了operator new，就也一定要写operator delete。
第三章 构造函数，析构函数和赋值操作符
几乎所有的类都有一个或多个构造函数，一个析构函数和一个赋值操作符。这没什么奇怪的，因为它们提供的都是一些最基本的功能。构造函数控制对象生成时的基本操作，并保证对象被初始化；析构函数摧毁一个对象并保证它被彻底清除；赋值操作符则给对象一个新的值。在这些函数上出错就会给整个类带来无尽的负面影响，所以一定要保证其正确性。本章我将指导如何用这些函数来搭建一个结构良好的类的主干。
条款11: 为需要动态分配内存的类声明一个拷贝构造函数和一个赋值操作符
看下面一个表示string对象的类：
// 一个很简单的string类
class string {
public:
string(const char *value);
~string();
... // 没有拷贝构造函数和operator=
private:
char *data;
};
string::string(const char *value)
{
if (value) {
data = new char[strlen(value) + 1];
strcpy(data, value);
}
else {
data = new char[1];
*data = '\0';
}
}
inline string::~string() { delete [] data; }
请注意这个类里没有声明赋值操作符和拷贝构造函数。这会带来一些不良后果。
如果这样定义两个对象：
string a("hello");
string b("world");
其结果就会如下所示：
a: data——> "hello\0"
b: data——> "world\0"
对象a的内部是一个指向包含字符串"hello"的内存的指针，对象b的内部是一个指向包含字符串"world"的内存的指针。如果进行下面的赋值：
b = a;
因为没有自定义的operator=可以调用，c++会生成并调用一个缺省的operator=操作符（见条款45）。这个缺省的赋值操作符会执行从a的成员到b的成员的逐个成员的赋值操作，对指针(a.data和b.data) 来说就是逐位拷贝。赋值的结果如下所示：
a: data --------> "hello\0"
/
b: data --/ "world\0"
这种情况下至少有两个问题。第一，b曾指向的内存永远不会被删除，因而会永远丢失。这是产生内存泄漏的典型例子。第二，现在a和b包含的指针指向同一个字符串，那么只要其中一个离开了它的生存空间，其析构函数就会删除掉另一个指针还指向的那块内存。
string a("hello"); // 定义并构造 a
{ // 开一个新的生存空间
string b("world"); // 定义并构造 b
...
b = a; // 执行 operator=,
// 丢失b的内存
} // 离开生存空间, 调用
// b的析构函数
string c = a; // c.data 的值不能确定!
// a.data 已被删除
例子中最后一个语句调用了拷贝构造函数，因为它也没有在类中定义，c++以与处理赋值操作符一样的方式生成一个拷贝构造函数并执行相同的动作：对对象里的指针进行逐位拷贝。这会导致同样的问题，但不用担心内存泄漏，因为被初始化的对象还不能指向任何的内存。比如上面代码中的情形，当c.data用 a.data的值来初始化时没有内存泄漏，因为c.data没指向任何地方。不过，假如c被a初始化后，c.data和a.data指向同一个地方，那这个地方会被删除两次：一次在c被摧毁时，另一次在a被摧毁时。
拷贝构造函数的情况和赋值操作符还有点不同。在传值调用的时候，它会产生问题。当然正如条款22所说明的，一般很少对对象进行传值调用，但还是看看下面的例子：
void donothing(string localstring) {}
string s = "the truth is out there";
donothing(s);
一切好象都很正常。但因为被传递的localstring是一个值，它必须从s通过（缺省）拷贝构造函数进行初始化。于是localstring拥有了一个 s内的指针的拷贝。当donothing结束运行时，localstring离开了其生存空间，调用析构函数。其结果也将是：s包含一个指向 localstring早已删除的内存的指针。
顺便指出，用delete去删除一个已经被删除的指针，其结果是不可预测的。所以即使s永远也没被使用，当它离开其生存空间时也会带来问题。
解决这类指针混乱问题的方案在于，只要类里有指针时，就要写自己版本的拷贝构造函数和赋值操作符函数。在这些函数里，你可以拷贝那些被指向的数据结构，从而使每个对象都有自己的拷贝；或者你可以采用某种引用计数机制（见条款 m29）去跟踪当前有多少个对象指向某个数据结构。引用计数的方法更复杂，而且它要求构造函数和析构函数内部做更多的工作，但在某些（虽然不是所有）程序里，它会大量节省内存并切实提高速度。
对于有些类，当实现拷贝构造函数和赋值操作符非常麻烦的时候，特别是可以确信程序中不会做拷贝和赋值操作的时候，去实现它们就会相对来说有点得不偿失。前面提到的那个遗漏了拷贝构造函数和赋值操作符的例子固然是一个糟糕的设计，那当现实中去实现它们又不切实际的情况下，该怎么办呢？很简单，照本条款的建议去做：可以只声明这些函数（声明为private成员）而不去定义（实现）它们。这就防止了会有人去调用它们，也防止了编译器去生成它们。关于这个俏皮的小技巧的细节，参见条款27。
关于本条款中所用到的那个string类，还要注意一件事。构造函数体内，在两个调用new的地方都小心地用了[]，尽管有一个地方实际只需要单个对象。正如条款5所说，在配套使用new和delete时一定要采用相同的形式，所以这里也这么做了。一定要经常注意，当且仅当相应的new用了[]的时候，delete才要用[]。
条款12: 尽量使用初始化而不要在构造函数里赋值
看这样一个模板，它生成的类使得一个名字和一个t类型的对象的指针关联起来。
template<class t>
class namedptr {
public:
namedptr(const string& initname, t *initptr);
...
private:
string name;
t *ptr;
};
（因为有指针成员的对象在进行拷贝和赋值操作时可能会引起指针混乱（见条款11），namedptr也必须实现这些函数（见条款2））
在写namedptr构造函数时，必须将参数值传给相应的数据成员。有两种方法来实现。第一种方法是使用成员初始化列表：
template<class t>
namedptr<t>::namedptr(const string& initname, t *initptr )
: name(initname), ptr(initptr)
{}
第二种方法是在构造函数体内赋值：
template<class t>
namedptr<t>::namedptr(const string& initname, t *initptr)
{
name = initname;
ptr = initptr;
}
两种方法有重大的不同。
从纯实际应用的角度来看，有些情况下必须用初始化。特别是const和引用数据成员只能用初始化，不能被赋值。所以，如果想让namedptr<t>对象不能改变它的名字或指针成员，就必须遵循条款21的建议声明成员为const：
template<class t>
class namedptr {
public:
namedptr(const string& initname, t *initptr);
...
private:
const string name;
t * const ptr;
};
这个类的定义要求使用一个成员初始化列表，因为const成员只能被初始化，不能被赋值。
如果namedptr<t>对象包含一个现有名字的引用，情况会非常不同。但还是要在构造函数的初始化列表里对引用进行初始化。还可以对名字同时声明const和引用，这样就生成了一个其名字成员在类外可以被修改而在内部是只读的对象。
template<class t>
class namedptr {
public:
namedptr(const string& initname, t *initptr);
...
private:
const string& name; // 必须通过成员初始化列表
// 进行初始化
t * const ptr; // 必须通过成员初始化列表
// 进行初始化
};
然而前面最初的类模板不包含const和引用成员。即使这样，用成员初始化列表还是比在构造函数里赋值要好。这次的原因在于效率。当使用成员初始化列表时，只有一个string成员函数被调用。而在构造函数里赋值时，将有两个被调用。为了理解为什么，请看在声明namedptr<t>对象时都发生了些什么。
对象的创建分两步：
1. 数据成员初始化。（参见条款13）
2. 执行被调用构造函数体内的动作。
（对有基类的对象来说，基类的成员初始化和构造函数体的执行发生在派生类的成员初始化和构造函数体的执行之前）
对namedptr类来说，这意味着string对象name的构造函数总是在程序执行到namedptr的构造函数体之前就已经被调用了。问题只在于：string的哪个构造函数会被调用？
这取决于namedptr类的成员初始化列表。如果没有为name指定初始化参数，string的缺省构造函数会被调用。当在namedptr的构造函数里对name执行赋值时，会对name调用operator=函数。这样总共有两次对string的成员函数的调用：一次是缺省构造函数，另一次是赋值。
相反，如果用一个成员初始化列表来指定name必须用initname来初始化，name就会通过拷贝构造函数以仅一个函数调用的代价被初始化。
即使是一个很简单的string类型，不必要的函数调用也会造成很高的代价。随着类越来越大，越来越复杂，它们的构造函数也越来越大而复杂，那么对象创建的代价也越来越高。养成尽可能使用成员初始化列表的习惯，不但可以满足const和引用成员初始化的要求，还可以大大减少低效地初始化数据成员的机会。
换句话说，通过成员初始化列表来进行初始化总是合法的，效率也决不低于在构造函数体内赋值，它只会更高效。另外，它简化了对类的维护（见条款m32），因为如果一个数据成员以后被修改成了必须使用成员初始化列表的某种数据类型，那么，什么也不用变。
但有一种情况下，对类的数据成员用赋值比用初始化更合理。这就是当有大量的固定类型的数据成员要在每个构造函数里以相同的方式初始化的时候。例如，这里有个类可以用来说明这种情形：
class manydatambrs {
public:
// 缺省构造函数
manydatambrs();
// 拷贝构造函数
manydatambrs(const manydatambrs& x);
private:
int a, b, c, d, e, f, g, h;
double i, j, k, l, m;
};
假如想把所有的int初始化为1而所有的double初始化为0，那么用成员初始化列表就要这样写：
manydatambrs::manydatambrs()
: a(1), b(1), c(1), d(1), e(1), f(1), g(1), h(1), i(0),
j(0), k(0), l(0), m(0)
{ ... }
manydatambrs::manydatambrs(const manydatambrs& x)
: a(1), b(1), c(1), d(1), e(1), f(1), g(1), h(1), i(0),
j(0), k(0), l(0), m(0)
{ ... }
这不仅仅是一项讨厌而枯燥的工作，而且从短期来说它很容易出错，从长期来说很难维护。
然而你可以利用固定数据类型的（非const, 非引用）对象其初始化和赋值没有操作上的不同的特点，安全地将成员初始化列表用一个对普通的初始化函数的调用来代替。
class manydatambrs {
public:
// 缺省构造函数
manydatambrs();
// 拷贝构造函数
manydatambrs(const manydatambrs& x);
private:
int a, b, c, d, e, f, g, h;
double i, j, k, l, m;
void init(); // 用于初始化数据成员
};
void manydatambrs::init()
{
a = b = c = d = e = f = g = h = 1;
i = j = k = l = m = 0;
}
manydatambrs::manydatambrs()
{
init();
...
}
manydatambrs::manydatambrs(const manydatambrs& x)
{
init();
...
}
因为初始化函数只是类的一个实现细节，所以当然要把它声明为private成员。
请注意static类成员永远也不会在类的构造函数初始化。静态成员在程序运行的过程中只被初始化一次，所以每当类的对象创建时都去“初始化”它们没有任何意义。至少这会影响效率：既然是“初始化”，那为什么要去做多次？而且，静态类成员的初始化和非静态类成员有很大的不同，这专门有一个条款m47来说明。
条款13: 初始化列表中成员列出的顺序和它们在类中声明的顺序相同
顽固的pascal和ada程序员会经常想念那种可以任意设定数组下标上下限的功能，即，数组下标的范围可以设为10到20，不一定要是0到10。资深的c程序员会坚持一定要从0开始计数，但想个办法来满足那些还在用begin/end的人的这个要求也很容易，这只需要定义一个自己的array类模板：
template<class t>
class array {
public:
array(int lowbound, int highbound);
...
private:
vector<t> data; // 数组数据存储在vector对象中
// 关于vector模板参见条款49
size_t size; // 数组中元素的数量
int lbound, hbound; // 下限，上限
};
template<class t>
array<t>::array(int lowbound, int highbound)
: size(highbound - lowbound + 1),
lbound(lowbound), hbound(highbound),
data(size)
{}
构造函数会对参数进行合法性检查，以保证highbound至少要大于等于lowbound，但这里有个很糟糕的错误：即使数组的上下限值合法，也绝对没人会知道data里会有多少个元素。
“ 这怎么可能？”我听见你在叫。“我小心地初始化了size后才把它传给vector的构造函数！”但不幸的是，你没有——你只是想这样做，但没遵守游戏规则：类成员是按照它们在类里被声明的顺序进行初始化的，和它们在成员初始化列表中列出的顺序没一点关系。用上面的array模板生成的类里，data总会被首先初始化，然后是size, lbound和hbound。
看起来似乎有悖常理，但这么做是有理由的。看下面这种情况：
class wacko {
public:
wacko(const char *s): s1(s), s2(0) {}
wacko(const wacko& rhs): s2(rhs.s1), s1(0) {}
private:
string s1, s2;
};
wacko w1 = "hello world!";
wacko w2 = w1;
如果成员按它们在初始化列表上出现的顺序被初始化，那w1和w2中的数据成员被创建的顺序就会不同。我们知道，对一个对象的所有成员来说，它们的析构函数被调用的顺序总是和它们在构造函数里被创建的顺序相反。那么，如果允许上面的情况（即，成员按它们在初始化列表上出现的顺序被初始化）发生，编译器就要为每一个对象跟踪其成员初始化的顺序，以保证它们的析构函数以正确的顺序被调用。这会带来昂贵的开销。所以，为了避免这一开销，同一种类型的所有对象在创建（构造）和摧毁（析构）过程中对成员的处理顺序都是相同的,而不管成员在初始化列表中的顺序如何。
实际上，如果你深究一下的话，会发现只是非静态数据成员的初始化遵守以上规则。静态数据成员的行为有点象全局和名字空间对象，所以只会被初始化一次（详见条款47）。另外，基类数据成员总是在派生类数据成员之前被初始化，所以使用继承时，要把基类的初始化列在成员初始化列表的最前面。（如果使用多继承，基类被初始化的顺序和它们被派生类继承的顺序一致，它们在成员初始化列表中的顺序会被忽略。使用多继承有很多地方要考虑。条款43关于多继承应考虑哪些方面的问题提出了很多建议。）
基本的一条是：如果想弄清楚对象被初始化时到底是怎么做的，请确信你的初始化列表中成员列出的顺序和成员在类内声明的顺序一致。
条款14: 确定基类有虚析构函数
有时，一个类想跟踪它有多少个对象存在。一个简单的方法是创建一个静态类成员来统计对象的个数。这个成员被初始化为0，在构造函数里加1，析构函数里减1。（条款m26里说明了如何把这种方法封装起来以便很容易地添加到任何类中，“my article on counting objects”提供了对这个技术的另外一些改进）
设想在一个军事应用程序里，有一个表示敌人目标的类：
class enemytarget {
public:
enemytarget() { ++numtargets; }
enemytarget(const enemytarget&) { ++numtargets; }
~enemytarget() { --numtargets; }
static size_t numberoftargets()
{ return numtargets; }
virtual bool destroy(); // 摧毁enemytarget对象后
// 返回成功
private:
static size_t numtargets; // 对象计数器
};
// 类的静态成员要在类外定义;
// 缺省初始化为0
size_t enemytarget::numtargets;
这个类不会为你赢得一份政府防御合同，它离国防部的要求相差太远了，但它足以满足我们这儿说明问题的需要。
敌人的坦克是一种特殊的敌人目标，所以会很自然地想到将它抽象为一个以公有继承方式从enemytarget派生出来的类（参见条款35及m33）。因为不但要关心敌人目标的总数，也要关心敌人坦克的总数，所以和基类一样，在派生类里也采用了上面提到的同样的技巧：
class enemytank: public enemytarget {
public:
enemytank() { ++numtanks; }
enemytank(const enemytank& rhs)
: enemytarget(rhs)
{ ++numtanks; }
~enemytank() { --numtanks; }
static size_t number
最低0.47元/天 解锁文章
305
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
