本篇文章都是摘自 《Effective C++》 中文版 第三版 和 第二版。

再好的记性也有忘记的一天，记录下以备随时查看。。。

电子书下载地址：https://download.csdn.net/download/freeking101/10278088

《Effective C++》第二版在线教程：http://www.kuqin.com/effectivec2e/

《Effective C++》第三版在线教程：http://blog.csdn.net/KangRoger/article/details/44706403

----------------------------------------------------------------------------------------------

导读

术语

1. 从 C 转向 CPP

        因为C是C++的子集，所有的C的技术都可以继续使用，但很多用起来又不太合适。例如，C++程序员会认为指针的指针看起来很古怪，他们会问：为什么不用指针的引用来代替呢？
        C是一种简单的语言。它真正提供的只有有宏、指针、结构、数组和函数。不管什么问题，C都靠宏、指针、结构、数组和函数来解决。而 C++ 不是这样。宏、指针、结构、数组和函数当然还存在，此外还有私有和保护型成员、函数重载、缺省参数、构造和析构函数、自定义操作符、内联函数、引用、友元、模板、异常、名字空间，等等。用C++比用C具有更宽广的空间，因为设计时有更多的选择可以考虑。

条款1：视CPP为一个语言联邦

View C++ as federation of languages

条款2：尽量以const和enum和inline来替换#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 *constauthorName = "Scott Meyers";   //指针 和指针所指向的内容 都是常量
关于const的含义和用法，特别是和指针相关联的问题，参见条款21。

第二个注意的是：定义某个类(class)的常量一般也很方便，只有一点点不同。要把常量限制在类中，首先要使它成为类的成员；为了保证常量最多只有一份拷贝，还要把它定义为静态成员：

class GamePlayer {
public:GamePlayer(){cout<<sizeof(scores)/sizeof(int)<<endl;}
private:static int temp;                   //静态变量（静态变量在类外初始化）static const int NUM_TURNS = 5;    // 常量声明和定义（常静态变量在类内初始化）int scores[NUM_TURNS];             // 使用常静态变量
};int GamePlayer::temp = 10;    // mandatory definition;int main(int argc, char *argv[])
{GamePlayer game;return 0;
}

还有一点，正如你看到的，上面的语句是 NUM_TURNS 的声明，而不是定义，所以你还必须在类的实现代码文件中定义类的静态成员。你不必过于担心这种小事。如果你忘了定义，链接器会提醒你。

旧一点的编译器会不接受这种语法，因为它认为类的静态成员在声明时定义初始值是非法的；而且，类内（in-class 初值设定）只允许初始化整数类型(如：int, bool, char 等)，还只能是常量。在上面的语法不能使用的情况下，可以在定义时赋初值：

class Test 
{
private:static const double m_temp;
};
const double Test::m_temp = 12.34;

class GamePlayer {
public:GamePlayer(){cout<<sizeof(scores)/sizeof(int)<<endl;}
private:enum { NUM_TURNS = 5 };    // "the enum hack" — makesint scores[NUM_TURNS];     // NUM_TURNS a symbolic name 。for 5
};

回到预处理的话题上来。另一个普遍的#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<typename T>
inline const T& max(const T& a, const T& b)
{ return a > b ? a : b; }

#include<iostream>
using namespace std;template<class T>
inline const T& My_Max(const T& a, const T& b)
{ return a > b ? a : b; }int main(int argc, char *argv[])
{cout<<My_Max(1,2)<<endl;return 0;
}

这个模板产生了一整套函数，每个函数拿两个可以转换成同种类型的对象进行比较然后返回较大的(常量)对象的引用。因为不知道T的类型，返回时传递引用可以提高效率(见条款22)。

顺便说一句，在你打算用模板写象max这样有用的通用函数时，先检查一下标准库(见条款49)，看看他们是不是已经存在。比如说上面说的max，你会惊喜地发现你可以后人乘凉：max是C++标准库的一部分。
有了const和inline，你对预处理的需要减少了，但也不能完全没有它。抛弃#include的日子还很远，#ifdef/#ifndef在控制编译的过程中还扮演重要角色。预处理还不能退休，但你一定要计划给它经常放长假。

然而，了解宏的机制以后，我们也可以用宏实现特殊的技巧。例如：C++反射，TEST

宏实现工厂模式

1. 需要一个全局的map用于存储类的信息以及创建实例的函数
2. 需要调用全局对象的构造函数用于注册

typedef void* (*register_fun)();class CCFactory
{
public:static void *NewInstance(string class_name){auto it = map_.find(class_name);if(it == map_.end()){return NULL;}elsereturn it->second();}static void Register(string class_name, register_fun func){map_[class_name] = func;}
private:static map<string, register_fun> map_; 
};map<string, register_fun> CCFactory::map_;class Register
{
public:Register(string class_name, register_fun func){CCFactory::Register(class_name, func);}
};#define REGISTER_CLASS(class_name); \const Register class_name_register(#class_name, []()->void *{return new class_name;});

条款3：尽可能使用const

use const whenever possible

1. const定义接口，防止误用
2. const成员函数，代表这个成员函数承诺不会改变对象值
   1. const成员只能调用const成员函数(加-fpermissive编译选项就可以了)
   2. 非const成员可以调用所有成员函数

使用const的好处在于它允许指定一种语意上的约束——某种对象不能被修改——编译器具体来实施这种约束。通过const，你可以通知编译器和其他程序员某个值要保持不变。只要是这种情况，你就要明确地使用const ，因为这样做就可以借助编译器的帮助确保这种约束不被破坏。

const关键字实在是神通广大。在 classes 外面，它可以用于全局global或名字空间namespace作用域中的常量（见条款2），以及静态对象（某一文件、函数、或者区块作用域（block scope））。在类的内部，它可以用于静态和非静态成员（见条款12）。

对指针来说，可以指定指针本身为const，也可以指定指针所指的数据为const，或二者同时指定为const，还有，两者都不指定为const：

char greeting[]      = "Hello";
char *p              = "hello";          // 非const指针, 非const数据
const char *p        = "hello";          // 非const指针, const数据
char * const p       = "hello";          // const指针, 非const数据
const char * const p = "hello";          // const指针, const数据

语法并非看起来那么变化多端。一般来说，你可以在头脑里画一条垂直线穿过指针声明中的星号（*）位置，如果const出现在线的左边，指针指向的数据为常量；如果const出现在线的右边，指针本身为常量；如果const在线的两边都出现，二者都是常量。

在指针所指为常量的情况下，有些程序员喜欢把const放在类型名之前，有些程序员则喜欢把const放在类型名之后、星号之前。所以，下面的函数取的是同种参数类型：

class Widget { ... };
void f1(const Widget *pw);      // f1取的是指向 Widget常量对象的指针
void f2(Widget const *pw);      // f2 也是

因为两种表示形式在实际代码中都存在，所以要使自己对这两种形式都习惯。

const的一些强大的功能基于它在函数声明中的应用。在一个函数声明中，const可以指的是函数的返回值，或某个参数；对于成员函数，还可以指的是整个函数。

让函数返回一个常量值经常可以在不降低安全性和效率的情况下减少用户出错的几率。实际上正如条款29所说明的，对返回值使用const有可能提高一个函数的安全性和效率，否则还会出问题。

class Rational { /*...*/ };
const Rational operator*(const Rational& lhs, const Rational& rhs);

Rational a, b, c;
//...
(a * b) = c;      // 对a*b的结果上调用 赋值（operator=）

关于const参数没什么特别之处要强调——它们的运作和局部const对象一样。（但，见条款m19，const参数会导致一个临时对象的产生）然而，如果成员函数为const，那就是另一回事了。

const成员函数

const成员函数的目的：是为了确认该成员函数可以在const对象上被调用。但很多人忽视了这样一个事实：仅在const方面有不同的成员函数可以重载。这是c++的一个重要特性。再次看这个 TextBlock 类：

class TextBlock
{
public://...char& operator[](int position)    // 用于非const对象的operator[]{ return data[position]; }  const char& operator[](int position) const  // 用于const对象的operator[]{ return data[position]; }private:char *data;
};TextBlock s1 = "hello";  //或者 TextBlock s1("hello");
cout << s1[0];       // 调用非const TextBlock::operator[]
const TextBlock s2 = "world";
cout << s2[0];       // 调用const TextBlock::operator[]

通过重载operator[]并给不同版本不同的返回值，就可以对const和非const TextBlock进行不同的处理：

TextBlock s = "hello";           // 非const TextBlock对象
cout << s[0];                    // 正确。读一个非const TextBlock
s[0] = 'x';                      // 正确。写一个非const TextBlock
const TextBlock cs = "world";    // const TextBlock 对象
cout << cs[0];                   // 正确。读一个const TextBlock
cs[0] = 'x';                     // 错误。写一个const TextBlock

另外注意，这里的错误只和调用operator[]的返回值有关；operator[]调用本身没问题。 错误产生的原因在于企图对一个const char&赋值，因为被赋值的对象是const版本的operator[]函数的返回值。

还要注意，非const operator[]的返回类型必须是一个char的引用——char本身则不行。如果operator[]真的返回了一个简单的char，如下所示的语句就不会通过编译： s[0] = 'x';

因为，修改一个“返回值为固定类型”的函数的返回值绝对是不合法的。即使合法，由于c++“通过值（而不是引用）来返回对象”（见条款22）的内部机制的原因，s.data[0]的一个拷贝会被修改，而不是s.data[0]自己，这就不是你所想要的结果了。

一个成员函数为const的确切含义是什么？

让我们停下来看一个基本原理。

有两种主要的看法：数据意义上的const（bitwise constness）和概念意义上的const（conceptual constness）。

bitwise constness的坚持者认为，当且仅当成员函数不修改对象的任何数据成员（静态数据成员除外）时，即不修改对象中任何一个比特(bit)时，这个成员函数才是const的。bitwise constness最大的好处是可以很容易地检测到违反bitwise constness规定的事件：编译器只用去寻找有无对数据成员的赋值就可以了。实际上，bitwise constness正是c++对const问题的定义，const成员函数不被允许修改它所在对象的任何一个数据成员。

不幸的是，很多不遵守bitwise constness定义的成员函数也可以通过bitwise测试。特别是，一个“修改了指针所指向的数据”的成员函数，其行为显然违反了bitwise constness定义，但如果对象中仅包含这个指针，这个函数也是bitwise const的，编译时会通过。这就和我们的直觉有差异：

class string {
public:// 构造函数，使data指向一个// value所指向的数据的拷贝string(const char *value);//...operator char *() const { return data;}private://char *data;
};const string s = "hello";      // 声明常量对象
char *nasty = s;               // 调用 operator char*() const
*nasty = 'm';                  // 修改s.data[0]
cout << s;                     // 输出"mello"

显然，在用一个值创建一个常量对象并调用对象的const成员函数时一定有什么错误，对象的值竟然可以修改！（关于这个例子更详细的讨论参见条款29）

这就导致conceptual constness观点的引入。此观点的坚持者认为，一个const成员函数可以修改它所在对象的一些数据（bits） ，但只有在用户不会发觉的情况下。例如，假设string类想保存对象每次被请求时数据的长度：

class string 
{
public:// 构造函数，使data指向一个// value所指向的数据的拷贝string(const char *value): lengthisvalid(false) { ... }//...size_t length() const;private:char *data;    size_t datalength;           // 最后计算出的string的长度   bool lengthisvalid;          // 长度当前是否合法
};size_t string::length() const
{if (!lengthisvalid) {datalength = strlen(data); // 错误!lengthisvalid = true;      // 错误!}return datalength;
}

这个length的实现显然不符合“bitwise const”的定义——datalength 和lengthisvalid都可以修改——但对const string对象来说，似乎它一定要是合法的才行。但编译器也不同意， 它们坚持“bitwise constness”，怎么办？

解决方案很简单：利用c++标准组织针对这类情况专门提供的有关const问题的另一个可选方案。此方案使用了关键字mutable，当对非静态数据成员运用mutable时，这些成员的“bitwise constness”限制就被解除：

class string 
{
public://...    // same as aboveprivate:char *data;    mutable size_t datalength;  // 这些数据成员现在为mutable；他们可以在任何地方被修改，即使在const成员函数里mutable bool lengthisvalid; 
}; size_t string::length() const
{if (!lengthisvalid) {datalength = strlen(data);    // 现在合法lengthisvalid = true;         // 同样合法}return datalength;
}

mutable在处理“bitwise-constness限制”问题时是一个很好的方案，但它被加入到c++标准中的时间不长，所以有的编译器可能还不支持它。如果是这样，就不得不倒退到c++黑暗的旧时代去，在那儿，生活很简陋，const有时可能会被抛弃。

类c的一个成员函数中，this指针就好象经过如下的声明：

c * const this; // 非const成员函数中
const c * const this; // const成员函数中

这种情况下（即编译器不支持mutable的情况下），如果想使那个有问题的string::length版本对const和非const对象都合法，就只有把this的类型从const c * const改成c * const。不能直接这么做，但可以通过初始化一个局部变量指针，使之指向this所指的同一个对象来间接实现。然后，就可以通过这个局部指针来访问你想修改的成员：

size_t string::length() const
{// 定义一个不指向const对象的// 局部版本的this指针string * const localthis = const_cast<string * const>(this);if (!lengthisvalid) {localthis->datalength = strlen(data);localthis->lengthisvalid = true;}    return datalength;
}

做的不是很漂亮。但为了完成想要的功能也就只有这么做。

当然，如果不能保证这个方法一定可行，就不要这么做：比如，一些老的“消除const”的方法就不行。特别是，如果this所指的对象真的是const，即，在定义时被声明为const，那么，“消除const”就会导致不可确定的后果。所以，如果想在成员函数中通过转换消除const，就最好先确信你要转换的对象最初没有被定义为const。

还有一种情况下，通过类型转换消除const会既有用又安全。这就是：将一个const对象传递到一个取非const参数的函数中，同时你又知道参数不会在函数内部被修改的情况时。第二个条件很重要，因为对一个只会被读的对象（不会被写）消除const永远是安全的，即使那个对象最初曾被定义为const。

例如，已经知道有些库不正确地声明了象下面这样的strlen函数：

size_t strlen(char *s);

strlen当然不会去修改s所指的数据——至少我一辈子没看见过。但因为有了这个声明，对一个const char *类型的指针调用这个函数时就会不合法。为解决这个问题，可以在给strlen传参数时安全地把这个指针的const强制转换掉：

const char *klingongreeting = "nuqneh"; // "nuqneh"即"hello"
// 
size_t length =
strlen(const_cast<char*>(klingongreeting));

但不要滥用这个方法。只有在被调用的函数（比如本例中的strlen）不会修改它的参数所指的数据时，才能保证它可以正常工作。

条款4：确定对象被使用前已被初始化

Make sure that objects initialized before they're uesd

1. 内置类型需要定义时初始化
2. 类中定义的成员变量，最好使用初始化序列(序列顺序与声明顺序相同)，而不是在构造函数中赋值
3. 跨编译单元定义全局对象不能确保初始化顺序
   1. 将static对象放入一个函数

永远在使用对象之前先将它初始化。对于内置类型，可以手工完成初始化。

int x = 0;                              // 对 int 手工初始化
const char* text = "A C-style string";  //对指针手工初始化
double d;
std::cin >> d;                          // 以读取input stream 方式初始化

2. 构造、析构、赋值操作

Constructors、Destructors、and Assignment operators

几乎所有的类都有一个或多个构造函数，一个析构函数和一个赋值操作符。这没什么奇怪的，因为它们提供的都是一些最基本的功能。构造函数控制对象生成时的基本操作，并保证对象被初始化；析构函数摧毁一个对象并保证它被彻底清除；赋值操作符则给对象一个新的值。在这些函数上出错就会给整个类带来无尽的负面影响，所以一定要保证其正确性。本章我将指导如何用这些函数来搭建一个结构良好的类的主干。

为需要动态分配内存的类声明一个拷贝构造函数和一个赋值操作符

看下面一个表示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才要用[]。

尽量使用成员初始化列表而不要在构造函数里赋值

看这样一个模板，它生成的类使得一个名字和一个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. 执行被调用构造函数体内的动作。

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来说明。

初始化列表中成员列出的顺序和它们在类中声明的顺序相同

顽固的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模板参见条款49size_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("") {}wacko(const wacko& rhs): s2(rhs.s1), s1("") {}public:string s1, s2;
};int main(int argc, char *argv[])
{wacko w1 = "hello world!";cout << w1.s1 << " " << w1.s2 << endl;wacko w2 = w1;cout << w2.s1 << " " << w2.s2 << endl;return 0;
}

条款5：了解 CPP 默认编写并调用哪些函数

条款6：若不想使用编译器自动生成的函数，就该明确拒绝

假设想写一个类模板Array，它所生成的类除了可以进行上下限检查外，其它行为和C++标准数组一样。设计中面临的一个问题是怎么禁止掉Array对象之间的赋值操作，因为对标准C++数组来说赋值是不合法的：        double values1[10];        double values2[10];                values1 = values2;                 // 错误!对很多函数来说，这不是个问题。如果你不想使用某个函数，只用简单地不把它放进类中。然而，赋值运算符属于那种与众不同的成员函数，当你没有去写这个函数时，C++会帮你写一个（见条款45）。那么，该怎么办呢？方法是声明这个函数（operator=），并使之为private。显式地声明一个成员函数，就防止了编译器去自动生成它的版本；使函数为private，就防止了别人去调用它。但是，这个方法还不是很安全，成员函数和友元函数还是可以调用私有函数，除非——如果你够聪明的话——不去定义（实现）这个函数。这样，当无意间调用了这个函数时，程序在链接时就会报错。对于Array来说，模板的定义可以象这样开始：

template<class T>
class Array 
{
private:// 不要定义这个函数!Array& operator=(const Array& rhs);//...
};

条款7：为多态基类声明virtual析构函数

1. 给多态基类应该主动声明virtual析构函数
2. 非多态基类，没有virtual函数，不要声明virtual析构函数

确定基类有虚析构函数

有时，一个类想跟踪它有多少个对象存在。一个简单的方法是创建一个静态类成员来统计对象的个数。这个成员被初始化为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;     // 对象计数器
};

class enemytank: public enemytarget 
{
public:enemytank() { ++numtanks; }enemytank(const enemytank& rhs): enemytarget(rhs){ ++numtanks; }~enemytank() { --numtanks; }static size_t numberoftanks(){ return numtanks; }virtual bool destroy();private:static size_t numtanks;         // 坦克对象计数器
};

（写完以上两个类的代码后，你就更能够理解条款m26对这个问题的通用解决方案了。）最后，假设程序的其他某处用new动态创建了一个enemytank对象，然后用delete删除掉：

        enemytarget *targetptr = new enemytank;
        ...
        delete targetptr;

到此为止所做的一切好象都很正常：两个类在析构函数里都对构造函数所做的操作进行了清除；应用程序也显然没有错误，用new生成的对象在最后也用delete删除了。然而这里却有很大的问题。程序的行为是不可预测的——无法知道将会发生什么。

c++语言标准关于这个问题的阐述非常清楚：当通过基类的指针去删除派生类的对象，而基类又没有虚析构函数时，结果将是不可确定的。这意味着编译器生成的代码将会做任何它喜欢的事：重新格式化你的硬盘，给你的老板发电子邮件，把你的程序源代码传真给你的对手，无论什么事都可能发生。（实际运行时经常发生的是，派生类的析构函数永远不会被调用。在本例中，这意味着当targetptr 删除时，enemytank的数量值不会改变，那么，敌人坦克的数量就是错的，这对需要高度依赖精确信息的部队来说，会造成什么后果？）

为了避免这个问题，只需要使enemytarget的析构函数为virtual。声明析构函数为虚就会带来你所希望的运行良好的行为：对象内存释放时，enemytank和enemytarget的析构函数都会被调用。

和绝大部分基类一样，现在enemytarget类包含一个虚函数。虚函数的目的是让派生类去定制自己的行为（见条款36），所以几乎所有的基类都包含虚函数。

如果某个类不包含虚函数，那一般是表示它将不作为一个基类来使用。当一个类不准备作为基类使用时，使析构函数为虚一般是个坏主意。请看下面的例子，这个例子基于arm(“the annotated c++ reference manual”)一书的一个专题讨论。

// 一个表示2d点的类
class point {
public:point(short int xcoord, short int ycoord);~point();private:short int x, y;
};

template<class t>   // 基类模板
class Array {       // (来自条款13)
public:Array(int lowbound, int highbound);~Array();private:vector<t> data;size_t size;int lbound, hbound;
};template<class t>
class NamedArray: public Array<t> 
{
public:NamedArray(int lowbound, int highbound, const string& name);//...private:string arrayname;
};

如果在应用程序的某个地方你将指向 NamedArray 类型的指针转换成了 Array 类型的指针，然后用delete来删除 Array 指针，那你就会立即掉进“不确定行为”的陷阱中。

NamedArray<int> *pna = newNamedArray<int>(10, 20, "impending doom");
Array<int> *pa;
...
pa = pna;    // NamedArray<int>* -> Array<int>*
...
delete pa;      // 不确定! 实际中，pa->arrayname
                      // 会造成泄漏，因为*pa的namedarray
                      // 永远不会被删除

现实中，这种情形出现得比你想象的要频繁。让一个现有的类做些什么事，然后从它派生一个类做和它相同的事，再加上一些特殊的功能，这在现实中不是不常见。NamedArray 没有重定义 Array 的任何行为——它继承了 Array 的所有功能而没有进行任何修改——它只是增加了一些额外的功能。但非虚析构函数的问题依然存在（还有其他问题，参见m33）

最后，值得指出的是，在某些类里声明纯虚析构函数很方便。纯虚函数将产生抽象类——不能实例化的类（即不能创建此类型的对象）。有些时候，你想使一个类成为抽象类，但刚好又没有任何纯虚函数。怎么办？因为抽象类是准备被用做基类的，基类必须要有一个虚析构函数，纯虚函数会产生抽象类，所以方法很简单：在想要成为抽象类的类里声明一个纯虚析构函数。

这里是一个例子：

class awov {       // awov = "abstract w/o// virtuals"
public:virtual ~awov() = 0;    // 声明一个纯虚析构函数   
};

这个类有一个纯虚函数，所以它是抽象的，而且它有一个虚析构函数，所以不会产生析构函数问题。但这里还有一件事：必须提供纯虚析构函数的定义：
awov::~awov() {}           // 纯虚析构函数的定义

这个定义是必需的，因为虚析构函数工作的方式是：最底层的派生类的析构函数最先被调用，然后各个基类的析构函数被调用。这就是说，即使是抽象类，编译器也要产生对~awov的调用，所以要保证为它提供函数体。如果不这么做，链接器就会检测出来，最后还是得回去把它添上。

可以在函数里做任何事，但正如上面的例子一样，什么事都不做也不是不常见。如果是这种情况，那很自然地会想到将析构函数声明为内联函数，从而避免对一个空函数的调用所产生的开销。这是一个很好的方法，但有一件事要清楚。

因为析构函数为虚，它的地址必须进入到类的vtbl（见条款m24）。但内联函数不是作为独立的函数存在的（这就是“内联”的意思），所以必须用特殊的方法得到它们的地址。条款33对此做了全面的介绍，其基本点是：如果声明虚析构函数为inline，将会避免调用它们时产生的开销，但编译器还是必然会在什么地方产生一个此函数的拷贝。

条款8：别让异常逃离析构函数

条款9：绝不在构造和析构过程中调用virtual函数

在初值列表中调用函数进行成员数据的初始化

#include<iostream>
#include<string>
using namespace std;class A
{
public:A():a(init()){ cout<<"Construct"<<endl; }void print(){cout<<"A::print()"<<endl;cout<<this->a<<endl;common();}virtual void common(){ cout<<"A::common()"<<endl; }private:int init(){ cout<<"init()"<<endl; return 100; }private:int a;
};class B : public A
{
public:B():A(){}void common(){cout<<"B::common()"<<endl;}
};int main()
{A a;a.print();cout<<"------------------"<<endl;B b;b.print();cout<<"------------------"<<endl;
}

运行结果：

条款10：令operator= 返回一个reference to *this

让operator=返回*this的引用

c++的设计者bjarne stroustrup下了很大的功夫使用户自定义类型尽可能地和固定类型的工作方式相似。这就是为什么你可以重载运算符，写类型转换函数（见条款m5），控制赋值和拷贝构造函数，等等。他做了这么多努力，那你最少也该继续做下去。

让我们看看赋值。用固定类型的情况下，赋值操作可以象下面这样链起来：
        int w, x, y, z;
        w = x = y = z = 0;
所以，你也应该可以将用户自定义类型的赋值操作链起来：
        string w, x, y, z;     // string是由标准c++库“自定义”的类型 (参见条款49)
        w = x = y = z = "hello";
因为赋值运算符的结合性天生就是由右向左，所以上面的赋值可以解析为：

        w = (x = (y = (z = "hello")));
很值得把它写成一个完全等价的函数形式。除非是个lisp程序员，否则下面的例子会很令人感到高兴，因为它定义了一个中缀运算符：w.operator=(x.operator=(y.operator=(z.operator=("hello"))));
这个格式在此很具有说明性，因为它强调了w.operator=, x.operator=和y.operator=的参数是前一个operator=调用的返回值。所以operator=的返回值必须可以作为一个输入参数被函数自己接受。在一个类c中，缺省版本的operator=函数具有如下形式（见条款45）：c& c::operator=(const c&);
一般情况下几乎总要遵循operator=输入和返回的都是类对象的引用的原则，然而有时候需要重载operator=使它能够接受不同类型的参数。

例如，标准string类型提供了两个不同版本的赋值运算符：
    string& // 将一个string
    operator=(const string& rhs); // 赋给一个string

    string& // 将一个char*
    operator=(const char *rhs); // 赋给一个string
请注意，即使在重载时，返回类型也是类的对象的引用。

c++程序员经常犯的一个错误是让operator=返回void，这好象没什么不合理的，但它妨碍了连续（链式）赋值操作，所以不要这样做。另一个常犯的错误是让operator=返回一个const对象的引用，象下面这样：

class widget {
public://...const widget& operator=(const widget& rhs);  //...
};

这样做通常是为了防止程序中做象下面这样愚蠢的操作：
widget w1, w2, w3;
...
(w1 = w2) = w3;     // w2赋给w1, 然后w3赋给其结果(给operator=一个const返回值就使这个语句不能通过编译)这可能是很愚蠢，但固定类型这么做并不愚蠢:
int i1, i2, i3;
...
(i1 = i2) = i3; // 合法! i2赋给i1，然后i3赋给i1!

这样的做法实际中很少看到，但它对int来说是可以的，对我和我的类来说也可以。那它对你和你的类也应该可以。为什么要无缘无故地和固定类型的常规做法不兼容呢？

采用缺省形式定义的赋值运算符里，对象返回值有两个很明显的候选者：赋值语句左边的对象（被this指针指向的对象）和赋值语句右边的对象（参数表中被命名的对象）。哪一个是正确的呢？

例如，对string类（假设你想在这个类中写赋值运算符，参见条款11中的解释）来说有两种可能：

string& string::operator=(const string& rhs)
{//...return *this;	// 返回左边的对象
}
string& string::operator=(const string& rhs)
{//...return rhs;	// 返回右边的对象
}

对你来说，这好象是拿六个一和十二的一半来比较一样为难。实际上他们有很大的不同。

首先，返回rhs的那个版本不会通过编译，因为rhs是一个const string的引用，而operator=要返回的是一个string的引用。当要返回一个非const的引用而对象自身是const时，编译器会给你带来无尽的痛苦。看起来这个问题很容易解决——只用象这样重新声明operator=：
string& string::operator=(string& rhs) { ... }
这次又轮到用到它的应用程序不能通过编译了！再看看最初那个连续赋值语句的后面部分：
x = "hello"; // 和x.op = ("hello"); 相同
因为赋值语句的右边参数不是正确的类型——它是一个字符数组，不是一个string——编译器就要产生一个临时的string对象（通过stirng构造函数——参见条款m19）使得函数继续运行。就是说，编译器必须产生大致象下面这样的代码：

const string temp("hello"); // 产生临时string
x = temp; // 临时string传给operator=

编译器一般会产生这样的临时值（除非显式地定义了所需要的构造函数——见条款19），但注意临时值是一个const。这很重要，因为它可以防止传递到函数内的临时值被修改。否则，程序员就会很奇怪地发现，只有编译器产生的临时值可以修改而他们在函数调用时实际传进去的参数却不行。（关于这一点是有事实根据的，早期版本的c++允许这类的临时值可以被产生，传递，修改，结果很多程序员感到很奇怪）

现在我们就可以知道如果string的operator=声明传递一个非const的stirng参数，应用程序就不能通过编译的原因了：对于没有声明相应参数为const的函数来说，传递一个const对象是非法的。这是一个关于const的很简单的规定。

所以，结论是，这种情况下你将别无选择：当定义自己的赋值运算符时，必须返回赋值运算符左边参数的引用，*this。如果不这样做，就会导致不能连续赋值，或导致调用时的隐式类型转换不能进行，或两种情况同时发生。

条款11：在operator= 里处理自我赋值

没什么理由，照着做就行

Widget& Widget::operator== (const Widget& rhs){if(this == &rhs) return *this···
}

做类似下面的事时，就会发生自己给自己赋值的情况：

class x { ... };
x a;
a = a; // a赋值给自己

这种事做起来好象很无聊，但它完全是合法的，所以看到程序员这样做不要感到丝毫的怀疑。更重要的是，给自己赋值的情况还可以以下面这种看起来更隐蔽的形式出现：

a = b;

如果b是a的另一个名字（例如，已被初始化为a的引用），那这也是对自己赋值，虽然表面上看起来不象。这是别名的一个例子：同一个对象有两个以上的名字。在本条款的最后将会看到，别名可以以大量任意形式的伪装出现，所以在写函数时一定要时时考虑到它。

在赋值运算符中要特别注意可能出现别名的情况，其理由基于两点。其中之一是效率。如果可以在赋值运算符函数体的首部检测到是给自己赋值，就可以立即返回，从而可以节省大量的工作，否则必须去实现整个赋值操作。例如，条款16指出，一个正确的派生类的赋值运算符必须调用它的每个基类的的赋值运算符，所以在派生类中省略赋值运算符函数体的操作将会避免大量对其他函数的调用。

另一个更重要的原因是保证正确性。一个赋值运算符必须首先释放掉一个对象的资源（去掉旧值），然后根据新值分配新的资源。在自己给自己赋值的情况下，释放旧的资源将是灾难性的，因为在分配新的资源时会需要旧的资源。

看看下面string对象的赋值，赋值运算符没有对给自己赋值的情况进行检查：

class string 
{
public:string(const char *value);    // 函数定义参见条款11  ~string();                    // 函数定义参见条款11//...    string& operator=(const string& rhs);private:char *data;
};// 忽略了给自己赋值的情况
// 赋值运算符重载
string& string::operator=(const string& rhs)
{delete [] data;    // delete old memory// 分配新内存，将rhs的值拷贝给它data = new char[strlen(rhs.data) + 1];strcpy(data, rhs.data);return *this;      // see item 15
}

看看下面这种情况将会发生什么：
        string a = "hello";
        a = a;               // same as a.operator=(a)
赋值运算符内部，*this和rhs好象是不同的对象，但在现在这种情况下它们却恰巧是同一个对象的不同名字。可以这样来表示这种情况：
        *this  data ------------> "hello\0"
        rhs    data -----
赋值运算符做的第一件事是用delete删除data，其结果将如下所示：
        *this  data ------------> ???
        rhs    data -----
现在，当赋值运算符对rhs.data调用strlen时，结果将无法确定。这是因为data被删除的时候rhs.data也被删除了，data，this->data 和rhs.data 其实都是同一个指针！从这一点看，情况只会越变越糟糕。现在可以知道，解决问题的方案是对可能发生的自己给自己赋值的情况先进行检查，如果有这种情况就立即返回。不幸的是，这种检查说起来容易做起来难，因为你必须定义两个对象怎么样才算是“相同”的。

你面临的这个问题学术上称为object identity，它在面向对象领域是个很有名的论题。本书不是讲述object identity的地方，但有必要提到两个解决这个问题的基本方法。

一个方法是，如果两个对象具有相同的值，就说它们是相同的（具有相同的身份）。例如，两个string对象如果都表示的是相同顺序的字符序列，它们就是相同的：
        string a = "hello";
        string b = "world";
        string c = "hello";
a和c具有相同值，所以它们被认为是完全相同的；b和它们都不同。如果把这个定义用到string类中，赋值运算符看起来就象这样：

string& string::operator=(const string& rhs)
{if (strcmp(data, rhs.data) == 0) return *this;       //...
}

c& c::operator=(const c& rhs)
{// 检查对自己赋值的情况if (*this == rhs)            // 假设operator=存在return *this;        //...
}

c& c::operator=(const c& rhs)
{// 检查对自己赋值的情况if (this == &rhs) return *this;        //...
}

class c 
{
public:objectid identity() const;    // 参见条款36        //...
};

class base 
{void mf1(base& rb);          // rb和*this可能相同                      //...        
};void f1(base& rb1,base& rb2);  // rb1和rb2可能相同class derived: public base 
{void mf2(base& rb);          // rb和*this可能相同//...
};int f2(derived& rd, base& rb); // rd和rb可能相同

条款12：复制对象时不要忘记每一个成分

Copy all parts of an object

1. 记得实现拷贝构造函数和赋值操作符的时候，调用base的相关函数
2. 可以让拷贝构造函数和赋值操作符调用一个共同的函数，例如init

如果没写赋值运算符的话，编译器就会为你生成一个，条款6则说明了为什么你会经常不喜欢编译器为你生成的这个赋值运算符，所以你会想能否有个两全其美的办法，让编译器生成一个缺省的赋值运算符，然后可以有选择地重写不喜欢的部分。这是不可能的！只要想对赋值过程的某一个部分进行控制，就必须负责做赋值过程中所有的事。

实际编程中，这意味着写赋值运算符时，必须对对象的每一个数据成员赋值：

template<class t>          // 名字和指针相关联的类的模板
class namedptr {           // （源自条款12）
public:namedptr(const string& initname, t *initptr);namedptr& operator=(const namedptr& rhs);private:string name;t *ptr;
};template<class t>
namedptr<t>& namedptr<t>::operator=(const namedptr<t>& rhs)
{if (this == &rhs)return *this;              // 见条款17// assign to all data membersname = rhs.name;             // 给name赋值*ptr = *rhs.ptr;             // 对于ptr，赋的值是指针所指的值，// 不是指针本身return *this;                // 见条款15
}

初写这个类时当然很容易记住上面的原则，但同样重要的是，当类里增加新的数据成员时，也要记住更新赋值运算符函数。例如，打算升级namedptr模板使得名字改变时附带一个时间标记，那就要增加一个新的数据成员，同时需要更新构造函数和赋值运算符。但现实中，因为忙于升级类的具体功能和增加新的成员函数等，这一点往往很容易被忘记。

当涉及到继承时，情况就会更有趣，因为派生类的赋值运算符也必须处理它的基类成员的赋值！看看下面：

class base {
public:base(int initialvalue = 0): x(initialvalue) {}private:int x;
};class derived: public base {
public:derived(int initialvalue): base(initialvalue), y(initialvalue) {}derived& operator=(const derived& rhs);private:int y;
};

逻辑上说，derived的赋值运算符应该象这样：

// erroneous assignment operator
derived& derived::operator=(const derived& rhs)
{if (this == &rhs) return *this;    // 见条款17y = rhs.y;                         // 给derived仅有的数据成员赋值return *this;                      // 见条款15
}

void assignmenttester()
{derived d1(0);     // d1.x = 0, d1.y = 0derived d2(1);     // d2.x = 1, d2.y = 1d1 = d2;           // d1.x = 0, d1.y = 1!
}

// 正确的赋值运算符
derived& derived::operator=(const derived& rhs)
{if (this == &rhs) return *this;base::operator=(rhs);    // 调用this->base::operator=y = rhs.y;return *this;
}

这里只是显式地调用了base::operator=，这个调用和一般情况下的在成员函数中调用另外的成员函数一样，以*this作为它的隐式左值。base::operator=将针对*this的base部分执行它所有该做的工作——正如你所想得到的那种效果。

但如果基类赋值运算符是编译器生成的，有些编译器会拒绝这种对于基类赋值运算符的调用（见条款45）。为了适应这种编译器，必须这样实现derived::operator=：

derived& derived::operator=(const derived& rhs)
{if (this == &rhs) return *this;static_cast<base&>(*this) = rhs;      // 对*this的base部分// 调用operator= y = rhs.y;return *this;
}

这段怪异的代码将*this强制转换为base的引用，然后对其转换结果赋值。这里只是对derived对象的base部分赋值。还要注意的重要一点是，转换的是base对象的引用，而不是base对象本身。如果将*this强制转换为base对象，就要导致调用base的拷贝构造函数，创建出来的新对象（见条款m19）就成为了赋值的目标，而*this保持不变。这不是所想要的结果。

不管采用哪一种方法，在给derived对象的base部分赋值后，紧接着是derived本身的赋值，即对derived的所有数据成员赋值。

另一个经常发生的和继承有关的类似问题是在实现派生类的拷贝构造函数时。看看下面这个构造函数，其代码和上面刚讨论的类似：

class base 
{
public:base(int initialvalue = 0): x(initialvalue) {}base(const base& rhs): x(rhs.x) {}private:int x;
};class derived: public base 
{
public:derived(int initialvalue): base(initialvalue), y(initialvalue) {}derived(const derived& rhs)      // 错误的拷贝: y(rhs.y) {}                    // 构造函数private:int y;
};

类derived展现了一个在所有c++环境下都会产生的bug：当derived的拷贝创建时，没有拷贝其基类部分。当然，这个derived对象的base部分还是创建了，但它是用base的缺省构造函数创建的，成员x被初始化为0（缺省构造函数的缺省参数值），而没有顾及被拷贝的对象的x值是多少！

为避免这个问题，derived的拷贝构造函数必须保证调用的是base的拷贝构造函数而不是base的缺省构造函数。这很容易做，只要在derived的拷贝构造函数的成员初始化列表里对base指定一个初始化值：

class derived: public base {
public:derived(const derived& rhs): base(rhs), y(rhs.y) {}//...
};

现在，当用一个已有的同类型的对象来拷贝创建一个derived对象时，它的base部分也将被拷贝了。

3. 资源管理(主要内存管理)

c++中涉及到的内存的管理问题可以归结为两方面：正确地得到它 和 有效地使用它。好的程序员会理解这两个问题为什么要以这样的顺序列出。因为执行得再快、体积再小的程序如果它不按你所想象地那样去执行，那也一点用处都没有。“正确地得到”的意思是正确地调用内存分配和释放程序；而“有效地使用”是指写特定版本的内存分配和释放程序。这里，“正确地得到”显得更重要一些。

然而说到正确性，c++其实从c继承了一个很严重的头疼病，那就是内存泄露隐患。虚拟内存是个很好的发明，但虚拟内存也是有限的，并不是每个人都可以最先抢到它。

在c中，只要用malloc分配的内存没有用free返回，就会产生内存泄露。在c++中，肇事者的名字换成了new和delete，但情况基本上是一样的。当然，因为有了析构函数的出现，情况稍有改善，因为析构函数为所有将被摧毁的对象提供了一个方便的调用delete的场所。但这同时又带来了更多的烦恼，因为new和delete是隐式地调用构造函数和析构函数的。而且，因为可以在类内和类外自定义new和delete操作符，这又带来了复杂性，增加了出错的机会。下面的条款(还有条款m8)将告诉你如何避免产生那些普遍发生的问题。

条款13：以对象管理资源

2. 为了防止资源泄漏，请使用RAII对象，在构造函数里面获得资源，在析构函数里面释放资源
3. shared_ptr，unique_lock都是RAII对象

条款14：在资源管理类中小心copy行为

常见的RAII对象copy行为

• 禁止copy
• 引用计数
• 深度复制
• 转移资源拥有权

条款15：在资源管理类中提供对原始资源的访问

用户可能需要原始资源作为参数传入某个接口。有两种方式：

1. 提供显示调用接口
2. 提供隐式转换接口(不推荐)

条款16：成对使用new和delete要采用相同的格式

new和delete对应；new []和delete []对应

//前面还分配了4个字节代表数组的个数
int *A = new int[10];//前面分配了8个字节，分别代表对象的个数和Object的大小
Object *O = new Object[10];

下面的语句有什么错？
        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
//  因为addresslines是个数组，使用new:
string *pal = new addresslines; // 注意"new addresslines"返回string*, 和 "new string[4]"返回的一样
delete时必须以数组形式与之对应：
delete pal;      // 错误!
delete [] pal;   // 正确

为了避免混乱，最好杜绝对数组类型用typedefs。这其实很容易，因为标准c++库(见条款49)包含有stirng和vector模板，使用他们将会使对数组的需求减少到几乎零。举例来说，addresslines可以定义为一个字符串(string)的向量(vector)，即addresslines可定义为vector<string>类型。

条款17：以独立的语句将newd对象置入智能指针

C++ 智能指针：http://blog.csdn.net/freeking101/article/details/54707663

4. 类和函数设计与声明

在程序中声明一个新类将导致产生一种新的类型：类的设计就是类型设计。可能你对类型设计没有太多经验，因为大多数语言没有为你提供实践的机会。在c++中，这却是很基本的特性，不是因为你想去做才可以这么做，而是因为每次你声明一个类的时候实际上就在做，无论你想不想做。

设计一个好的类很具有挑战性，因为设计好的类型很具有挑战性。好的类型具有自然的语法，直观的语义和高效的实现。在c++中，一个糟糕的类的定义是无法实现这些目标的。即使一个类的成员函数的性能也是由这些成员函数的声明和定义决定的。

那么，怎么着手设计高效的类呢？首先，必须清楚你面临的问题。实际上，设计每个类时都会遇到下面的问题，它的答案将影响到你的设计。

• 对象将如何被创建和摧毁？它将极大地影响构造函数和析构函数的设计，以及自定义的operator new, operator new[], operator delete, 和operator delete[]。（条款m8描述了这些术语的区别）
• 对象初始化和对象赋值有什么不同？答案决定了构造函数和赋值运算符的行为以及它们之间的区别。
• 通过值来传递新类型的对象意味着什么？记住，拷贝函数负责对此做出回答。
• 新类型的合法值有什么限制？这些限制决定了成员函数（特别是构造函数和赋值运算符）内部的错误检查的种类。它可能还影响到函数抛出的例外的种类以及函数的例外规范（参见条款m14），如果你使用它们的话。
• 新类型符合继承关系吗？如果是从已有的类继承而来，那么新类的设计就要受限于这些类，特别是受限于被继承的类是虚拟的还是非虚拟的。如果新类允许被别的类继承，这将影响到函数是否要声明为虚拟的。
• 允许哪种类型转换？如果允许类型a的对象隐式转换为类型b的对象，就要在类a中写一个类型转换函数，或者，在类b中写一个可以用单个参数来调用的非explicit构造函数。如果只允许显式转换，就要写函数来执行转换功能，但不用把它们写成类型转换运算符和或单参数的非explicit构造函数。（条款m5讨论了用户自定义转换函数的优点和缺点）
• 什么运算符和函数对新类型有意义？答案决定了将要在类接口中声明什么函数。
• 哪些运算符和函数要被明确地禁止？它们需要被声明为private。
• 谁有权访问新类型的成员？这个问题有助于决定哪些成员是公有的，哪些是保护的，哪些私有的。它还有助于确定哪些类和/或函数必须是友元，以及将一个类嵌套到另一个类中是否有意义。
• 新类型的通用性如何？也许你实际上不是在定义一个新的类型，而是在定义一整套的类型。如果是这样，就不要定义一个新类，而要定义一个新的类模板。

条款18：让接口容易被正确使用，不易被误用

• 1. 好的接口很容易被正确使用，不容易被误用。努力达成这些性质(例如 explicit关键字)
• 2. “促进正确使用” 的办法包括接口的一致性，以及与内置类型的行为兼容
• 3. “防治误用” 的办法包括建立新类型，限制类型上的操作，束缚对象值，以及消除用户的资源管理责任
• 4. shared_ptr 支持定制类型 deleter（删除器），需要灵活使用

类的用户接口是指使用这个类的程序员所能访问得到的接口。典型的接口里只有函数存在，因为在用户接口里放上数据成员会有很多缺点（见条款22）。

哪些函数该放在类的接口里呢？有时这个问题会使你发疯，因为有两个截然不同的目标要你去完成。一方面，设计出来的类要易于理解，易于使用，易于实现。这意味着函数的数量要尽可能地少，每一个函数都完成各自不同的任务。另一方面，类的功能要强大，要方便使用，这意味着要不时增加函数以提供对各种通用功能的支持。你会怎样决定哪些函数该放进类里，哪些不放呢？

试试这个建议：类接口的目标是完整且最小。

一个完整的接口是指那种允许用户做他们想做的任何合理的事情的接口。也就是说，对用户想完成的任何合理的任务，都有一个合理的方法去实现，即使这个方法对用户来说没有所想象的那样方便。相反，一个最小的接口，是指那种函数尽可能少、每两个函数都没有重叠功能的接口。如果能提供一个完整、最小的接口，用户就可以做任何他们想做的事，但类的接口不必再那样复杂。

追求接口的完整看起来很自然，但为什么要使接口最小呢？为什么不让用户做任何他们想做的事，增加更多的函数，使大家都高兴呢？

撇开处世原则方面的因素不谈——牵就你的用户真的正确吗？——充斥着大量函数的类的接口从技术上来说有很多缺点。第一，接口中函数越多，以后的潜在用户就越难理解。他们越难理解，就越不愿意去学该怎么用。一个有10个函数的类好象对大多数人来说都易于使用，但一个有100个函数的类对许多程序员来说都难以驾驭。在扩展类的功能使之尽可能地吸引用户的时候，注意不要去打击用户学习使用它们的积极性。

大的接口还会带来混淆。假设在一个人工智能程序里建立一个支持识别功能的类。其中一个成员函数叫think（想），后来有些人想把函数名叫做ponder（深思），另外还一些人喜欢叫ruminate（沉思）。为了满足所有人的需要，你提供了三个函数，虽然他们做同样的事。那么想想，以后某个使用这个类的用户会怎么想呢？这个用户会面对三个不同的函数，每个函数好象都是做相同的事。真的吗？难道这三个函数有什么微妙的不同，效率上，通用性上，或可靠性上？如果没有不同，为什么会有三个函数？这样的话，这个用户不但不感激你提供的灵活性，还会纳闷你究竟在想（或者深思，或者沉思）些什么？

大的类接口的第二个缺点是难以维护（见条款m32）。含有大量函数的类比含有少量函数的类更难维护和升级，更难以避免重复代码（以及重复的bug），而且难以保持接口的一致性。同时，也难以建立文档。

最后，长的类定义会导致长的头文件。因为程序在每次编译时都要读头文件（见条款34），类的定义太长会导致项目开发过程中浪费大量的编译时间。

概括起来就是说，无端地在接口里增加函数不是没有代价的，所以在增加一个新函数时要仔细考虑：它所带来的方便性（只有在接口完整的前提下才应该考虑增加一个新函数以提供方便性）是否超过它所带来的额外代价，如复杂性，可读性，可维护性和编译时间等。

但太过吝啬也没必要。在最小的接口上增加一些函数有时是合理的。如果一个通用的功能用成员函数实现起来会更高效，这将是把它增加到接口中的好理由。（但，有时不会，参见条款m16）如果增加一个成员函数使得类易于使用，或者可以防止用户错误，也都是把它加入到接口中的有力依据。

看一个具体的例子：一个类模板，实现了用户自定义下标上下限的数组功能，另外提供上下限检查选项。模板的开头部分如下所示：

template<class t>
class Array {
public:enum boundscheckingstatus {no_check_bounds = 0, check_bounds = 1};Array(int lowbound, int highbound, boundscheckingstatus check = no_check_bounds);Array(const Array& rhs);~Array();Array& operator=(const Array& rhs);private:int lbound, hbound;         // 下限, 上限vector<t> data;             // 数组内容; 关于vector，// 请参见条款49boundscheckingstatus checkingbounds;
};

目前为止声明的成员函数是基本上不用想（或深思，沉思）就该声明的。一个允许用户确定每个数组上下限的构造函数，一个拷贝构造函数，一个赋值运算符和一个析构函数。析构函数被声明为非虚拟的，意味着这个类将不作为基类使用（见条款14）。

对于赋值运算符的声明，第一眼看上去会觉得目的不那么明确。毕竟，c++中固定类型的数组是不允许赋值的，所以好象也应该不允许Array对象赋值（参见条款27）。但另一方面，数组似的vector模板（存在于标准库——参见条款49）允许vector对象间赋值。在本例中，决定遵循vector的规定，正如下面将会看到的，这个决定将影响到类的接口的其他部分。

老的c程序员看到这个接口会被吓退：怎么竟然不支持固定大小的数组声明？很容易增加一个构造函数来实现啊：

Array(int size, boundscheckingstatus check = no_check_bounds);

Array<int> a(10, 20);      // 下标上下限为：10到20
//...
for (int i = a的下标下限; i <= a的下标上限; ++i)cout << "a[" << i << "] = " << a[i] << '\n';

for (int i = a.lowbound(); i <= a.highbound(); ++i)cout << "a[" << i << "] = " << a[i] << '\n';

条款19：设计class犹如设计type

条款20：宁以pass-by-refrence-to-const替换pass-by-value

1. 尽量以pass-by-reference-to-const替换pass-by-value，比较高效，并且可以避免切割问题
2. 以上规则并不使用内置类型，以及STL迭代器，和函数对象。它们采用pass-by-value更合适(其实采用pass-by-reference-to-const也可以)

C语言中，什么都是通过传值来实现的，c++继承了这一传统并将它作为默认方式。除非明确指定，函数的形参总是通过“实参的拷贝”来初始化的，函数的调用者得到的也是函数返回值的拷贝。

正如我在本书的导言中所指出的，“通过值来传递一个对象”的具体含义是由这个对象的类的拷贝构造函数定义的。这使得传值成为一种非常昂贵的操作。例如，看下面这个（只是假想的）类的结构：

class Person 
{
public:Person();                         // 为简化，省略参数~Person(); //...
private:string name, address;
};class Student: public Person 
{
public:Student();                        // 为简化，省略参数~Student();//...
private:string schoolname, schooladdress;
};

现在定义一个简单的函数returnstudent，它取一个Student参数（通过值）然后立即返回它（也通过值）。定义完后，调用这个函数：
        Student returnstudent(Student s) { return s; }
        Student plato;                      // plato（柏拉图）在socrates（苏格拉底）门下学习
        returnstudent(plato);           // 调用returnstudent
这个看起来无关痛痒的函数调用过程，其内部究竟发生了些什么呢？

简单地说就是：首先，调用了Student的拷贝构造函数用以将s初始化为plato；然后再次调用Student的拷贝构造函数用以将函数返回值对象初始化为s；接着，s的析构函数被调用；最后，returnstudent返回值对象的析构函数被调用。所以，这个什么也没做的函数的成本是两个Student的拷贝构造函数加上两个Student析构函数。

但没完，还有。。。Student对象中有两个string对象，所以每次构造一个Student对象时必须也要构造两个string对象。student对象还是从Person对象继承而来的，所以每次构造一个Student对象时也必须构造一个Person对象。一个Person对象内部有另外两个string对象，所以每个Person的构造也必然伴随另两个string的构造。所以，通过值来传递一个Student对象最终导致调用了一个Student拷贝构造函数，一个Person拷贝构造函数，四个string拷贝构造函数。当Student对象被摧毁时，每个构造函数对应一个析构函数的调用。所以，通过值来传递一个Student对象的最终开销是六个构造函数和六个析构函数。因为returnstudent函数使用了两次传值（一次对参数，一次对返回值），这个函数总共调用了十二个构造函数和十二个析构函数！

在c++编译器的设计者眼里，这是最糟糕的情况。编译器可以用来消除一些对拷贝构造函数的调用（c++标准——见条款50——描述了具体在哪些条件下编译器可以执行这类的优化工作，条款m20给出了例子）。一些编译器也这样做了。但在不是所有编译器都普遍这么做的情况下，一定要对通过值来传递对象所造成的开销有所警惕。

为避免这种潜在的昂贵的开销，就不要通过值来传递对象，而要通过引用：

const student& returnstudent(const student& s)
{ return s; }

这会非常高效：没有构造函数或析构函数被调用，因为没有新的对象被创建。

通过引用来传递参数还有另外一个优点：它避免了所谓的“切割问题（slicing problem）”。当一个派生类的对象作为基类对象被传递时，它（派生类对象）的作为派生类所具有的行为特性会被“切割”掉，从而变成了一个简单的基类对象。这往往不是你所想要的。例如，假设设计这么一套实现图形窗口系统的类：

class window 
{
public:string name() const;             // 返回窗口名virtual void display() const;    // 绘制窗口内容
};class windowwithscrollbars: public window 
{
public:virtual void display() const;
};

每个window对象都有一个名字，可以通过name函数得到；每个窗口都可以被显示，着可以通过调用display函数实现。display声明为virtual意味着一个简单的window基类对象被显示的方式往往和价格昂贵的windowwithscrollbars对象被显示的方式不同（见条款36，37，m33）。

现在假设写一个函数来打印窗口的名字然后显示这个窗口。下面是一个用错误的方法写出来的函数：

// 一个受“切割问题”困扰的函数
void printnameanddisplay(window w)
{cout << w.name();w.display();
}

想象当用一个windowwithscrollbars对象来调用这个函数时将发生什么：
        windowwithscrollbars wwsb;
        printnameanddisplay(wwsb);
参数w将会作为一个windows对象而被创建（它是通过值来传递的，记得吗？），所有wwsb所具有的作为windowwithscrollbars对象的行为特性都被“切割”掉了。printnameanddisplay内部，w的行为就象是一个类window的对象（因为它本身就是一个window的对象），而不管当初传到函数的对象类型是什么。尤其是，printnameanddisplay内部对display的调用总是window::display，而不是windowwithscrollbars::display。

解决切割问题的方法是通过引用来传递w：

// 一个不受“切割问题”困扰的函数
void printnameanddisplay(const window& w)
{cout << w.name();w.display();
}

现在w的行为就和传到函数的真实类型一致了。为了强调w虽然通过引用传递但在函数内部不能修改，就要采纳条款21的建议将它声明为const。

传递引用是个很好的做法，但它会导致自身的复杂性，最大的一个问题就是别名问题，这在条款17进行了讨论。另外，更重要的是，有时不能用引用来传递对象，参见条款23。最后要说的是，引用几乎都是通过指针来实现的，所以通过引用传递对象实际上是传递指针。因此，如果是一个很小的对象——例如int——传值实际上会比传引用更高效。

条款21：必须返回对象时，别返回其reference

1. 不要返回pointer或者reference指向一个on stack对象(被析构)
2. 不要返回pointer或者reference指向一个on heap对象(需要用户delete，我觉得必要的时候也不是不可以)
3. 不要返回pointer或者reference指向local static对象，却需要多个这样的对象(static只能有一份)

据说爱因斯坦曾提出过这样的建议：尽可能地让事情简单，但不要过于简单。在c++语言中相似的说法应该是：尽可能地使程序高效，但不要过于高效。

一旦程序员抓住了“传值”在效率上的把柄（参见条款20），他们会变得十分极端，恨不得挖出每一个隐藏在程序中的传值操作。岂不知，在他们不懈地追求纯粹的“传引用”的过程中，他们会不可避免地犯另一个严重的错误：传递一个并不存在的对象的引用。这就不是好事了。

看一个表示有理数的类，其中包含一个友元函数，用于两个有理数相乘：

class Rational 
{
public:Rational(int numerator = 0, int denominator = 1);//...
private:int n, d;              // 分子和分母// 参见条款21：为什么返回值是constfriend const Rational operator*(const Rational& lhs, const Rational& rhs)     
};inline const Rational operator*(const Rational& lhs, const Rational& rhs)
{return Rational(lhs.n * rhs.n, lhs.d * rhs.d);
}

// 写此函数的第一个错误方法
inline const Rational& operator*(const Rational& lhs, const Rational& rhs)
{Rational result(lhs.n * rhs.n, lhs.d * rhs.d);return result;
}

// 写此函数的第二个错误方法
inline const Rational& operator*(const Rational& lhs, const Rational& rhs)
{Rational *result = new Rational(lhs.n * rhs.n, lhs.d * rhs.d);return *result;
}

Rational w, x, y, z;
w = x * y * z;
//两个对operator*的调用都产生了没有名字的临时值，程序员无法看到，因而无法删除。（再次参见条款31）

// 写此函数的第三个错误方法
inline const Rational& operator*(const Rational& lhs, const Rational& rhs)
{static Rational result;      // 将要作为引用返回的静态对象lhs和rhs 相乘，结果放进result；return result;
}

bool operator==(const Rational& lhs, const Rational& rhs);    // Rationals的operator==                   
Rational a, b, c, d;
//...
if ((a * b) == (c * d)) {//处理相等的情况;
} 
else {//处理不相等的情况;
}

inline const Rational operator*(const Rational& lhs, const Rational& rhs)
{return Rational(lhs.n * rhs.n, lhs.d * rhs.d);
}

条款22：将成员变量申明为private

2. 切记将成员变量声明为private。
3. protected并不比public更有封装性(用户可能继承你的base class)

首先，从“一致性”的角度来看这个问题。如果public接口里都是函数，用户每次访问类的成员时就用不着抓脑袋去想：是该用括号还是不该用括号呢？——用括号就是了！因为每个成员都是函数。一生中，这可以避免你多少次抓脑袋啊！

你不买“一致性”的帐？那你总得承认采用函数可以更精确地控制数据成员的访问权这一事实吧？如果使数据成员为public，每个人都可以对它读写；如果用函数来获取或设定它的值，就可以实现禁止访问、只读访问和读写访问等多种控制。甚至，如果你愿意，还可以实现只写访问：

class AccessLevels 
{
public:int getreadonly() const{ return readonly; }  void setreadwrite(int value) { readwrite = value; }int getreadwrite() const { return readwrite; }  void setwriteonly(int value) { writeonly = value; }private:int noaccess;             // 禁止访问这个int    int readonly;             // 可以只读这个int    int readwrite;            // 可以读/写这个int    int writeonly;            // 可以只写这个int
};

还没说服你？那只得搬出这门重型大炮：功能分离（functional abstraction）。如果用函数来实现对数据成员的访问，以后就有可能用一段计算来取代这个数据成员，而使用这个类的用户却一无所知。

例如，假设写一个用自动化仪器检测汽车行驶速度的应用程序。每辆车行驶过来时，计算出的速度值添加到一个集中了当前所有的汽车速度数据的集合里：

class SpeedDataCollection 
{
public:void addvalue(int speed);       // 添加新速度值double averagesofar() const;    // 返回平均速度
};

现在考虑怎么实现成员函数averagesofar（另见条款m18）。一种方法是用类的一个数据成员来保存当前收集到的所有速度数据的运行平均值。只要averagesofar被调用，就返回这个数据成员的值。另一个不同的方法则是在averagesofar每次被调用时才通过检查集合中的所有的数据值计算出结果。（关于这两个方法的更全面的讨论参见条款m17和m18。）

第一种方法——保持一个运行值——使得每个speeddatacollection对象更大，因为必须为保存运行值的数据成员分配空间。但averagesofar实现起来很高效：它可以是一个仅用返回数据成员值的内联函数（见条款33）。相反，每次调用时都要计算平均值的方案则使得averagesofar运行更慢，但每个speeddatacollection对象会更小。

谁能说哪个方法更好？在内存很紧张的机器里，或在不是频繁需要平均值的应用程序里，每次计算平均值是个好方案。在频繁需要平均值的应用程序里，速度是最根本的，内存不是主要问题，保持一个运行值的方法更可取。重要之处在于，用成员函数来访问平均值，就可以使用任何一种方法，它具有极大价值的灵活性，这是那个在public接口里包含平均值数据成员的方案所不具有的。

所以，结论是，在public接口里放上数据成员无异于自找麻烦，所以要把数据成员安全地隐藏在与功能分离的高墙后。如果现在就开始这么做，那我们就可以无需任何代价地换来一致性和精确的访问控制。

条款23：宁以non-member，non-friend替换member函数

作者说多一个成员函数，就多一分破坏封装性，好像有点道理，但是我们都没有这样遵守。直接写member函数方便一些。

分清成员函数，非成员函数和友元函数

成员函数和非成员函数最大的区别在于：成员函数可以是虚拟的，而非成员函数不行。所以，如果有个函数必须进行动态绑定（见条款38），就要采用虚拟函数，而虚拟函数必定是某个类的成员函数。关于这一点就这么简单。如果函数不必是虚拟的，情况就稍微复杂一点。

看下面表示有理数的一个类：

class Rational 
{
public:Rational(int numerator = 0, int denominator = 1);int numerator() const;int denominator() const;private://...
};

class Rational 
{
public://...const Rational operator*(const Rational& rhs) const;
};

class Rational 
{
public:explicit Rational(int numerator = 0,     // 此构造函数为int denominator = 1);  // explicit//...const Rational operator*(const Rational& rhs) const;  //...
};

那么，下面的语句都不能通过编译：
        result = onehalf * 2;             // 错误!
        result = 2 * onehalf;             // 错误!
这不会为混合运算提供支持，但至少两条语句的行为一致了。

然而，我们刚才研究的这个类是要设计成可以允许固定类型到Rational的隐式转换的——这就是为什么Rational的构造函数没有声明为explicit的原因。这样，编译器将执行必要的隐式转换使上面result的第一个赋值语句通过编译。实际上，如果需要的话，编译器会对每个函数的每个参数执行这种隐式类型转换。但它只对函数参数表中列出的参数进行转换，决不会对成员函数所在的对象（即，成员函数中的*this指针所对应的对象）进行转换。这就是为什么这个语句可以工作：
        result = onehalf.operator*(2);      // converts int -> Rational
而这个语句不行：
        result = 2.operator*(onehalf);      // 不会转换 int -> Rational
第一种情形操作的是列在函数声明中的一个参数，而第二种情形不是。

尽管如此，你可能还是想支持混合型的算术操作，而实现的方法现在应该清楚了：使operator*成为一个非成员函数，从而允许编译器对所有的参数执行隐式类型转换：

class Rational 
{//...          // contains no operator*
};// 在全局或某一名字空间声明，
// 参见条款m20了解为什么要这么做
const Rational operator*(const Rational& lhs, const Rational& rhs)
{return Rational(lhs.numerator() * rhs.numerator(), lhs.denominator() * rhs.denominator());
}Rational onefourth(1, 4);
Rational result;result = onefourth * 2;           // 工作良好
result = 2 * onefourth;           // 万岁, 它也工作了!

这当然是一个完美的结局，但还有一个担心：operator*应该成为Rational类的友元吗？

这种情况下，答案是不必要。因为operator*可以完全通过类的公有（public）接口来实现。上面的代码就是这么做的。只要能避免使用友元函数就要避免，因为，和现实生活中差不多，友元（朋友）带来的麻烦往往比它（他/她）对你的帮助多。

然而，很多情况下，不是成员的函数从概念上说也可能是类接口的一部分，它们需要访问类的非公有成员的情况也不少。

让我们回头再来看看本书那个主要的例子，string类。如果想重载operator>>和operator<<来读写string对象，你会很快发现它们不能是成员函数。如果是成员函数的话，调用它们时就必须把string对象放在它们的左边：

// 一个不正确地将operator>>和
// operator<<作为成员函数的类
class string 
{
public:string(const char *value);//  ...istream& operator>>(istream& input);ostream& operator<<(ostream& output);private:char *data;
};string s;
s >> cin;                   // 合法, 但有违常规
s << cout;                  // 同上

这会把别人弄糊涂。所以这些函数不能是成员函数。注意这种情况和前面的不同。这里的目标是自然的调用语法，前面关心的是隐式类型转换。所以，如果来设计这些函数，就象这样：

istream& operator>>(istream& input, string& string)
{delete [] string.data;read from input into some memory, and make string.datapoint to itreturn input;
}ostream& operator<<(ostream& output, const string& string)
{return output << string.data;
}

注意上面两个函数都要访问string类的data成员，而这个成员是私有（private）的。但我们已经知道，这个函数一定要是非成员函数。这样，就别无选择了：需要访问非公有成员的非成员函数只能是类的友元函数。

本条款得出的结论如下。假设f是想正确声明的函数，c是和它相关的类：

• 虚函数必须是成员函数。如果f必须是虚函数，就让它成为c的成员函数。
• operator>>和operator<<决不能是成员函数。如果f是operator>>或operator<<，让f成为非成员函数。如果f还需要访问c的非公有成员，让f成为c的友元函数。
• 只有非成员函数对最左边的参数进行类型转换。如果f需要对最左边的参数进行类型转换，让f成为非成员函数。如果f还需要访问c的非公有成员，让f成为c的友元函数。
• 其它情况下都声明为成员函数。如果以上情况都不是，让f成为c的成员函数。
  

条款24：若所有参数都需要类型转换，请为此采用non-member函数

条款25：考虑写一个不抛出异常的swap函数

1. 当 std::swap 对你的类型效率不高时(std::swap调用拷贝构造函数和赋值操作符，如果是深拷贝，效率不会高)，提供一个swap成员函数，并确定不会抛出异常。
   

   class Obj{Obj(const Obj&){ /* 深拷贝 */ } Obj& operator= (const Obj&){ /* 深拷贝 */ }
   private:OtherClass *p;
   };

2. 如果提供一个member swap，也该提供一个non-member swap用来调用前者

3. 调用 swap 时应该针对std::swap使用using声明式，然后调用swap不带任何"命名空间修饰”

   void doSomething(Obj& o1, Obj& o2){
   //这样可以让编译器自己决定调用哪个swap，万一用户没有实现针对Obj的swap，还能调用std::swap
   using std::swap;swap(o1, o2);
   }

4. 不要往std命名空间里面加东西

在函数重载和设定参数缺省值间慎重选择

会对函数重载和设定参数缺省值产生混淆的原因在于，它们都允许一个函数以多种方式被调用：

        void f();	    // f被重载void f(int x);f();	// 调用f()f(10);	// 调用f(int)void g(int x = 0);	// g 有一个缺省参数值g();	// 调用g(0)g(10);	// 调用g(10)

int max(int a,int b = std::numeric_limits::min(),int c = std::numeric_limits::min(),int d = std::numeric_limits::min(),int e = std::numeric_limits::min())
{int temp = a > b ? a : b;temp = temp > c ? temp : c;temp = temp > d ? temp : d;return temp > e ? temp : e;
}

现在可以放松了。std::numeric_limits<int>::min()是c++标准库用一种特有的新方法所表示的一个在c里已经定义了的东西，即c在<limits.h>中定义的int_min宏所表示的那个东西——处理你的c++原代码的编译器所产生的int的最小可能值。是的，它的句法背离了c所具有的简洁，但在那些冒号以及其它奇怪的句法背后，是有道理可循的。
假设想写一个函数模板，其参数为固定数字类型，模板产生的函数可以打印用“实例化类型”表示的最小值。这个模板可以这么写：
template
void printminimumvalue()
{
    cout << 表示为t类型的最小值;
}
如果只是借助<limits.h>和<float.h>来写这个函数会觉得很困难，因为不知道t是什么，所以不知道该打印int_min还是dbl_min，或其它什么类型的值。
为避开这些困难，标准c++库（见条款49）在头文件<limits> 
中定义了一个类模板numeric_limits，这个类模板本身也定义了一些静态成员函数。每个函数返回的是“实例化这个模板的类型”的信息。也就是说，numeric_limits<int>中的函数返回的信息是关于类型int的，numeric_limits<double> 
中的函数返回的信息是关于类型double的。numeric_limits中有一个函数叫min，min返回可表示为“实例化类型”的最小值，所以numeric_limits<int>::min()返回的是代表整数类型的最小值。
有了numeric_limits（和标准库中其它东西一样，numeric_limits存在于名字空间std中；numeric_limits本身在头文件<limits>中），写printminimumvalue就可以象下面这样容易：
template
void printminimumvalue()
{
    cout << std::numeric_limits::min();
}

采用基于numeric_limits的方法来表示“类型相关常量”看起来开销很大，其实不然。因为原代码的冗长的语句不会反映到生成的目标代码中。实际上，对numeric_limits的调用根本就不产生任何指令。想知道怎么回事，看看下面，这是numeric_limits<int>::min的一个很简单的实现：
#include 
namespace std 
{
    inline int numeric_limits<int>::min() throw ()
    { return int_min; }
}

因为此函数声明为inline，对它的调用会被函数体代替（见条款33）。它只是个int_min，也就是说，它本身仅仅是个简单的“实现时定义的常量”的#define。所以即使本条款开头的那个max函数看起来好象对每个缺省参数进行了函数调用，其实只不过是用了另一种聪明的方法来表示一个类型相关常量而已（本例中常量值为int_min）。象这样一些高效巧妙的应用在c++标准库里俯拾皆是，这可以参考条款49。
回到max函数上来：最关键的一点是，不管函数的调用者提供几个参数，max计算时采用的是相同（效率很低）的算法。在函数内部任何地方都不用在意哪些参数是“真”的，哪些是缺省值；而且，所选用的缺省值不可能影响到所采用的算法计算的正确性。这就是使用缺省参数值的方案可行的原因。
对很多函数来说，会找不到合适的缺省值。例如，假设想写一个函数来计算最多可达5个int的平均值。这里就不能用缺省参数，因为函数的结果取决于传入的参数的个数：如果传入3个值，就要将总数除以3；如果传入5个值，就要将总数除以5。另外，假如用户没有提供某个参数时，没有一个“神奇的数字”可以作为缺省值，因为所有可能的int都可以是有效参数。这种情况下就别无选择：必须重载函数：
double avg(int a);
double avg(int a, int b);
double avg(int a, int b, int c);
double avg(int a, int b, int c, int d);
double avg(int a, int b, int c, int d, int e);

另一种必须使用重载函数的情况是：想完成一项特殊的任务，但算法取决于给定的输入值。这种情况对于构造函数很常见：“缺省”构造函数是凭空（没有输入）构造一个对象，而拷贝构造函数是根据一个已存在的对象构造一个对象：

// 一个表示自然数的类
class Natural 
{
public:Natural(int initvalue);Natural(const Natural& rhs);private:unsigned int value;void init(int initvalue);void error(const string& msg);
};inline void Natural::init(int initvalue) { value = initvalue; }Natural::Natural(int initvalue)
{if (initvalue > 0) init(initvalue);else error("illegal initial value");
}inline Natural::Natural(const Natural& x)
{ init(x.value); }

避免对指针和数字类型重载

快速抢答：什么是“零”？

更明确地说，下面的代码会发生什么？

void f(int x);
void f(string *ps);f(0);   // 调用f(int)还是f(string*)?

void * const null = 0;	// 可能的null定义f(0);			 // 还是调用f(int)
f(static_cast(null));	 // 调用f(string*)
f(static_cast(0));	 // 调用f(string*)

f(0);			// 调用f(int)
f(null);		// 错误! — 类型不匹配
f(static_cast(null));	// 正确, 调用f(string*)

#define null 0
或
#define null ((void*) 0)

#define null 0l		// null现在是一个long intvoid f(int x);
void f(string *p);f(null);		// 错误!——歧义

#define null 0lvoid f(long int x);	// 这个f现在的参数为long
void f(string *p);f(null);		// 正确, 调用f(long int)

// 一个可以产生null指针对象的类的第一步设计class NullClass 
{
public:template	                        // 为所有类型的toperator t*() const { return 0; }	// 产生operator t*；每个函数返回一个null指针 
};const NullClass null;			// null是类型NullClass的一个对象
void f(int x);				// 和以前一样
void f(string *p);			// 同上
f(null);				// 将null转换为string*, 然后调用f(string*)

const class {			// 这是一个const对象...
public:template			// 可以转换任何类型的null非成员指针operator t*() const		{ return 0; }template			// 可以转换任何类型的null成员指针operator t c::*() const	{ return 0; }private:void operator&() const;	// 不能取其地址 (见条款27)} null;		//名字为null

这就是所看到的真实的代码，虽然在实际编程中有可能想给类一个名字。如果不给名字，编译器里指向null类型的信息也确实很难理解。

成员模板的用法的另一个例子参见条款m28。

重要的一点是，以上所有那些产生正确工作的null的设计方案，只有在你自己是调用者的时候才有意义。如果你是设计被调用函数的人，写这样一个给别人使用的null其实没有多大的用处，因为你不能强迫你的调用者去使用它。例如，即使为你的用户提供了上面开发的那个null，你还是不能防止他们这样做：
        f(0);     // 还是调用f(int),因为0还是int
它还是和本条款最前面的出现的问题一样。
所以，作为重载函数的设计者，归根结底最基本的一条是，只要有可能，就要避免对一个数字和一个指针类型重载。

当心潜在的二义性

每个人都有思想。有些人相信自由经济学，有些人相信来生。有些人甚至相信COBOL是一种真正的程序设计语言。C++也有一种思想：它认为潜在的二义性不是一种错误。

这是潜在二义性的一个例子：

class B;		// 对类B提前声明		
class A 
{
public:A(const B&);	// 可以从B构造而来的类A
};class B 
{
public:operator A() const;	// 可以从A转换而来的类B
};

void f(const A&);
B b;
f(b);			// 错误!——二义

class Base1 
{
public:int doIt();
};class Base2 
{
public:void doIt();
};class Derived: public Base1, public Base2  	
{	//...
};Derived d;
d.doIt();		// 错误!——二义

class Base1 { ... };	// 同上
class Base2 
{
private:void doIt(); // 此函数现在为private
};class Derived: public Base1, public Base2
{ ... };		// 同上Derived d;
int i = d.doIt();	// 错误! — 还是二义!

划分全局名字空间

全局空间最大的问题在于它本身仅有一个。在大的软件项目中，经常会有不少人把他们定义的名字都放在这个单一的空间中，从而不可避免地导致名字冲突。例如，假设library1.h定义了一些常量，其中包括：
        const double lib_version = 1.204;
类似的，library2.h也定义了：
        const int lib_version = 3;
很显然，如果某个程序想同时包含library1.h和library2.h就会有问题。对于这类问题，你除了嘴里骂几句，或给作者发报复性邮件，或自己编辑头文件来消除名字冲突外，也没其它什么办法。

但是，作为程序员，你可以尽力使自己写的程序库不给别人带来这些问题。例如，可以预先想一些不大可能造成冲突的某种前缀，加在每个全局符号前。当然得承认，这样组合起来的标识符看起来不是那么令人舒服。

另一个比较好的方法是使用c++ namespace。namespace本质上和使用前缀的方法一样，只不过避免了别人总是看到前缀而已。所以，不要这么做：
        const double sdmbook_version = 2.0;      // 在这个程序库中, 每个符号以"sdm"开头
        class sdmhandle { ... };                 
        sdmhandle& sdmgethandle();             // 为什么函数要这样声明？参见条款47
而要这么做：

namespace sdm 
{const double book_version = 2.0;class handle { ... };handle& gethandle();
}

void f1()
{using namespace sdm;           // 使得sdm中的所有符号不用加修饰符就可以使用cout << book_version;          // 解释为sdm::book_version//...handle h = gethandle();        // handle解释为sdm::handle, gethandle解释为sdm::gethandle//...                            
}void f2()
{using sdm::book_version;        // 使得仅book_version不用加修饰符就可以使用cout << book_version;           // 解释为 sdm::book_version//...handle h = gethandle();         // 错误! handle和gethandle都没有引入到本空间//...                             
}void f3()
{cout << sdm::book_version;      // 使得book_version 在本语句有效//...                             double d = book_version;        // 错误! book_version 不在本空间handle h = gethandle();         // 错误! handle和gethandle 都没有引入到本空间//...                            
}

namespace acmewindowsystem 
{//...typedef int handle;//...
}

只要不引用符号handle，使用sdm和acmewindowsystem时就不会有冲突。假如真的要引用，可以明确地指明是哪个名字空间的handle：

void f()
{using namespace sdm;                 // 引入sdm里的所有符号using namespace acmewindowsystem;    // 引入acme里的所有符号//...   // 自由地引用sdm// 和acme里除handle之外// 的其它符号handle h;                            // 错误! 哪个handle?  sdm::handle h1;                      // 正确, 没有二义  acmewindowsystem::handle h2;         // 也没有二义  //...
}

假如用常规的基于头文件的方法来做，只是简单地包含sdm.h和acme.h，这样的话，由于handle有多个定义，编译将不能通过。

名字空间的概念加入到c++标准的时间相对较晚，所以有些人会认为它不太重要，可有可无。但这种想法是错误的，因为c++标准库（参见条款49）里几乎所有的东西都存在于名字空间std之中。这可能令你不以为然，但它却以一种直接的方式影响到你：这就是为什么c++提供了那些看起来很有趣的、没有扩展名的头文件，如<iostream>, <string>等。详细介绍参见条款49。

由于名字空间的概念引入的时间相对较晚，有些编译器可能不支持。就算是这样，那也没理由污染全局名字空间，因为可以用struct来近似实现namespace。可以这样做：先创建一个结构用以保存全局符号名，然后将这些全局符号名作为静态成员放入结构中：

// 用于模拟名字空间的一个结构的定义
struct sdm 
{static const double book_version;class handle { ... };static handle& gethandle();
};const double sdm::book_version = 2.0;      // 静态成员的定义

现在，如果有人想访问这些全局符号名，只用简单地在它们前面加上结构名作为前缀：

void f()
{cout << sdm::book_version;    //...    sdm::handle h = sdm::gethandle();    //...
}

// 定义一个模拟名字空间的结构，结构内部包含widgets的类型
// 和函数。widgets对象支持operator+进行加法运算
struct widgets 
{class widget { ... };// 参见条款21：为什么返回conststatic const widget operator+(const widget& lhs, const widget& rhs);//...
};// 为上面所述的widge和operator+ 
// 建立全局（无修饰符的）名称typedef widgets::widget widget;const widget (* const operator+)(const widget&,        // 错误!const widget&);       // operator+不能是指针名widget w1, w2, sum;
sum = w1 + w2;                           // 错误! 本空间没有声明参数为widgets 的operator+
sum = widgets::operator+(w1, w2);        // 合法, 但不是"自然"的语法

5. 实现

c++是一种高度类型化的语言，所以，给出合适的类和模板的定义以及合适的函数声明是整个设计工作中最大的一部分。按理说，只要这部分做好了，类、模板以及函数的实现就不容易出问题。但是，往往人们还是会犯错。

犯错的原因有的是不小心违反了抽象的原则：让实现细节可以提取类和函数内部的数据。有的错误在于不清楚对象生命周期的长短。还有的错误起源于不合理的前期优化工作，特别是滥用inline关键字。最后一种情况是，有些实现策略会导致源文件间的相互联结问题，它可能在小规模范围内很合适，但在重建大系统时会带来难以接受的成本。

所有这些问题，以及与之类似的问题，都可以避免，只要你清楚该注意哪些方面。以下的条款就指明了应该特别注意的几种情况。

条款26：尽可能延后变量定义式出现的时间

C语言推荐在函数开始的时候定义所有变量(最开始的C语言编译器要求，现在并不需要)。

C++推荐在使用对象前才定义对象

条款27：尽量少做类型转换动作

1. 如果可以，尽量避免转型，特别是在注重效率的代码中避免dynamic_cast。
2. 如果转型是必要的，试着将它隐藏于某个函数后。客户可以随时调用该函数，而不需要将转型放入自己的代码。
3. 使用C++风格的转型。

条款28：避免返回handles指向对象内部成分

简单说，就是成员函数返回指针或者非const引用不要指向成员变量，这样会破坏封装性。

条款29：为“异常安全”而努力是值得的

1. "异常安全函数"承诺即使发生异常也不会有资源泄漏。在这个基础下，它有3个级别
   1. 基本保证：抛出异常，需要用户处理程序状态改变(自己写代码保证这个级别就行了把)
   2. 强烈保证：抛出异常，程序状态恢复到调用前
   3. 不抛异常：内置类型的操作就绝不会抛出异常

2. "强烈保证"往往可以通过copy-and-swap实现，但是"强烈保证"并非对所有函数都具有实现意义

   //我反正从来没有这样写过
   void doSomething(Object& obj)
   {
       Object new_obj(obj);new_obj++;swap(obj, new_obj);
   }

条款30：透彻了解inline函数的里里外外

这里插播一个C++处理定义的重要原则，一处定义原则：

• 全局变量，静态数据成员，非内联函数和成员函数只能整个程序定义一次
• 类类型(class，struct,union)，内联函数可以每个翻译单元定义一次
  • template类的成员函数或者template函数，定义在头文件中，编译器可以帮忙去重
  • 普通类的template函数，定义在头文件中，需要加inline

1. inline应该限制在小的，频繁调用的函数上
2. inline只是给编译器的建议，编译器不一定执行

条款31：将文件的编译依存关系降到最低

1. 支持"编译依存最小化"的一般构想是：相依于声明式，不要相依于定义式。基于此构想的两个手段是Handle classes(impl对象提供服务)和Interface classes。

其实就是使用前置声明，下面有个需要注意的点

//Obj.h
class ObjImpl;
class Obj{
public:
private:std::shared_ptr<ObjImpl> pObjImpl;
};//上面的写法会报错，因为编译器会再.h文件里面产生默认的析构函数，
//析构函数要调用ObjImpl的析构函数，然后我们现在只有声明式，不能调用ObjImpl的实现。
//下面的实现才是正确的//Obj.h
class ObjImpl;
class Obj{
public://声明~Obj();
private:std::shared_ptr<ObjImpl> pObjImpl;
};//Obj.cpp
//现在可以看到ObjImpl的实现
#include<ObjImpl>Obj::~Obj(){}

1. 对于STL的对象不需要前置声明。

假设某一天你打开自己的C++程序代码，然后对某个类的实现做了小小的改动。提醒你，改动的不是接口，而是类的实现，也就是说，只是细节部分。然后你准备重新生成程序，心想，编译和链接应该只会花几秒种。毕竟，只是改动了一个类嘛！于是你点击了一下"Rebuild"，或输入make（或其它类似命令）。然而，等待你的是惊愕，接着是痛苦。因为你发现，整个世界都在被重新编译、重新链接！

当这一切发生时，你难道仅仅只是愤怒吗？

问题发生的原因在于，在将接口从实现分离这方面，C++做得不是很出色。尤其是，C++的类定义中不仅包含接口规范，还有不少实现细节。例如：

class Person 
{
public:Person(const string& name, const Date& birthday,const Address& addr, const Country& country);virtual ~Person();//...       // 简化起见，省略了拷贝构造函数和赋值运算符函数string name() const;string birthDate() const;string address() const;string nationality() const;private:string name_;            // 实现细节Date birthDate_;         // 实现细节Address address_;        // 实现细节Country citizenship_;    // 实现细节
};

这很难称得上是一个很高明的设计，虽然它展示了一种很有趣的命名方式：当私有数据和公有函数都想用某个名字来标识时，让前者带一个尾部下划线就可以区别了。这里要注意到的重要一点是，Person的实现用到了一些类，即string， Date，Address和Country；Person要想被编译，就得让编译器能够访问得到这些类的定义。这样的定义一般是通过#include指令来提供的，所以在定义Person类的文件头部，可以看到象下面这样的语句：

#include <string>           // 用于string类型 (参见条款49)
#include "date.h"
#include "address.h"
#include "country.h"

遗憾的是，这样一来，定义Person的文件和这些头文件之间就建立了编译依赖关系。所以如果任一个辅助类（即string， Date，Address和Country）改变了它的实现，或任一个辅助类所依赖的类改变了实现，包含Person类的文件以及任何使用了Person类的文件就必须重新编译。对于Person类的用户来说，这实在是令人讨厌，因为这种情况用户绝对是束手无策。

那么，你一定会奇怪为什么C++一定要将一个类的实现细节放在类的定义中。例如，为什么不能象下面这样定义Person，使得类的实现细节与之分开呢？

class string;         // "概念上" 提前声明string 类型 详见条款49class Date;           // 提前声明
class Address;        // 提前声明
class Country;        // 提前声明class Person 
{
public:Person(const string& name, const Date& birthday,const Address& addr, const Country& country);virtual ~Person();//...                      // 拷贝构造函数, operator=string name() const;string birthDate() const;string address() const;string nationality() const;
};

int main()
{int x;                      // 定义一个int    Person p(...);              // 定义一个Person (为简化省略参数)//... 
}

int main()
{int x;                     // 定义一个int    Person *p;                 // 定义一个Person指针       //...
}

// 编译器还是要知道这些类型名，
// 因为Person的构造函数要用到它们
class string;      // 对标准string来说这样做不对，// 原因参见条款49
class Date;
class Address;
class Country;// 类PersonImpl将包含Person对象的实
// 现细节，此处只是类名的提前声明
class PersonImpl;class Person 
{
public:Person(const string& name, const Date& birthday,const Address& addr, const Country& country);virtual ~Person();...                               // 拷贝构造函数, operator=string name() const;string birthDate() const;string address() const;string nationality() const;private:PersonImpl *impl;                 // 指向具体的实现类
};

现在Person的用户程序完全和string，date，address，country以及person的实现细节分家了。那些类可以随意修改，而Person的用户却落得个自得其乐，不闻不问。更确切的说，它们可以不需要重新编译。另外，因为看不到Person的实现细节，用户不可能写出依赖这些细节的代码。这是真正的接口和实现的分离。

分离的关键在于，"对类定义的依赖" 被 "对类声明的依赖" 取代了。所以，为了降低编译依赖性，我们只要知道这么一条就足够了：只要有可能，尽量让头文件不要依赖于别的文件；如果不可能，就借助于类的声明，不要依靠类的定义。其它一切方法都源于这一简单的设计思想。

下面就是这一思想直接深化后的含义：

• 如果可以使用对象的引用和指针，就要避免使用对象本身。定义某个类型的引用和指针只会涉及到这个类型的声明。定义此类型的对象则需要类型定义的参与。
• 尽可能使用类的声明，而不使用类的定义。因为在声明一个函数时，如果用到某个类，是绝对不需要这个类的定义的，即使函数是通过传值来传递和返回这个类：
  class Date;                   // 类的声明
  Date returnADate();    // 正确 ---- 不需要Date的定义
  void takeADate(Date d); 
  当然，传值通常不是个好主意（见条款22），但出于什么原因不得不这样做时，千万不要还引起不必要的编译依赖性。
  如果你对returnADate和takeADate的声明在编译时不需要Date的定义感到惊讶，那么请跟我一起看看下文。其实，它没看上去那么神秘，因为任何人来调用那些函数，这些人会使得Date的定义可见。"噢" 我知道你在想，"为什么要劳神去声明一个没有人调用的函数呢？" 不对！不是没有人去调用，而是，并非每个人都会去调用。例如，假设有一个包含数百个函数声明的库（可能要涉及到多个名字空间----参见条款28），不可能每个用户都去调用其中的每一个函数。将提供类定义（通过#include 指令）的任务从你的函数声明头文件转交给包含函数调用的用户文件，就可以消除用户对类型定义的依赖，而这种依赖本来是不必要的、是人为造成的。
• 不要在头文件中再（通过#include指令）包含其它头文件，除非缺少了它们就不能编译。相反，要一个一个地声明所需要的类，让使用这个头文件的用户自己（通过#include指令）去包含其它的头文件，以使用户代码最终得以通过编译。一些用户会抱怨这样做对他们来说很不方便，但实际上你为他们避免了许多你曾饱受的痛苦。事实上，这种技术很受推崇，并被运用到C++标准库（参见条款49）中；头文件<iosfwd>就包含了iostream库中的类型声明（而且仅仅是类型声明）。

#include "Person.h"          // 因为是在实现Person类，所以必须包含类的定义// 也必须包含PersonImpl类的定义，否则不能调用它的成员函数。
// 注意PersonImpl和Person含有一样的成员函数，它们的接口完全相同
#include "PersonImpl.h"      Person::Person(const string& name, const Date& birthday,const Address& addr, const Country& country)
{impl = new PersonImpl(name, birthday, addr, country);
}string Person::name() const
{return impl->name();
}

class Person 
{
public:virtual ~Person();virtual string name() const = 0;virtual string birthDate() const = 0;virtual string address() const = 0;virtual string nationality() const = 0;
};

// makePerson是支持Person接口的
// 对象的"虚构造函数" ( "工厂函数")
Person*makePerson(const string& name,         // 用给定的参数初始化一个const Date& birthday,       // 新的Person对象，然后const Address& addr,        // 返回对象指针const Country& country);   

string name;
Date dateOfBirth;
Address address;
Country nation;
//...// 创建一个支持Person接口的对象
Person *pp = makePerson(name, dateOfBirth, address, nation);
...cout  << pp->name()              // 通过Person接口使用对象<< " was born on "         << pp->birthDate()<< " and now lives at "<< pp->address();
//...
delete pp;                       // 删除对象

class Person 
{
public://...        // 同上// makePerson现在是类的成员static Person * makePerson(const string& name,const Date& birthday,const Address& addr,const Country& country);

class RealPerson: public Person 
{
public:RealPerson(const string& name, const Date& birthday,const Address& addr, const Country& country):  name_(name), birthday_(birthday),address_(addr), country_(country){}virtual ~RealPerson() {}string name() const;          // 函数的具体实现没有string birthDate() const;     // 在这里给出，但它们string address() const;       // 都很容易实现string nationality() const;    private:string name_;Date birthday_;Address address_;Country country_;
};

Person * Person::makePerson(const string& name,const Date& birthday,const Address& addr,const Country& country)
{return new RealPerson(name, birthday, addr, country);
}

避免返回内部数据的句柄(即指针)

请看面向对象世界里发生的一幕：

        对象a：亲爱的，永远别变心！
        对象b：别担心，亲爱的，我是const。
然而，和现实生活中一样，a会怀疑，"能相信b吗？" 同样地，和现实生活中一样，答案取决于b的本性：其成员函数的组成结构。

假设b是一个const string对象：

class string 
{
public:string(const char *value);        // 具体实现参见条款11~string();                        // 构造函数的注解参见条款m5operator char *() const;          // 转换string -> char*; 参见条款m5//...private:char *data;
};const string b("hello world");      // b是一个const对象

既然b为const，最好的情况当然就是无论现在还是以后，b的值总是"hello world"。这就寄希望于别的程序员能以合理的方式使用b了。特别是，千万别有什么人象下面这样残忍地将b强制转换掉const（参见条款21）：

string& alsob = const_cast<string&>(b);    // 使得alsob成为b的另一个名字，但不具有const属性     

然而，即使没有人做这种残忍的事，就能保证b永远不会改变吗？看看下面的情形：

char *str = b;               // 调用b.operator char*()
strcpy(str, "hi mom");       // 修改str指向的值

b的值现在还是"hello world"吗？或者，它是否已经变成了对母亲的问候语？答案完全取决于string::operator char*的实现。

下面是一个有欠考虑的实现，它导致了错误的结果。但是，它工作起来确实很高效，所以很多程序员才掉进它的错误陷阱之中：

// 一个执行很快但不正确的实现
inline string::operator char*() const
{ return data; }

这个函数的缺陷在于它返回了一个"句柄"（在本例中，是个指针），而这个句柄所指向的信息本来是应该隐藏在被调用函数所在的string对象的内部。这样，这个句柄就给了调用者自由访问data所指的私有数据的机会。换句话说，有了下面的语句：

char *str = b;

情况就会变成这样：

str------------------------->"hello world\0"
b.data

显然，任何对str所指向的内存的修改都使得b的有效值发生变化。所以，即使b声明为const，而且即使只是调用了b的某个const成员函数，b也会在程序运行过程中得到不同的值。特别是，如果str修改了它所指的值，b也会改变。

string::operator char*本身写的没有一点错，麻烦的是它可以用于const对象。如果这个函数不声明为const，就不会有问题，因为这样它就不能用于象b这样的const对象了。

但是，将一个string对象转换成它相应的char*形式是很合理的一件事，无论这个对象是否为const。所以，还是应该使函数保持为const。这样的话，就得重写这个函数，使得它不返回指向对象内部数据的句柄：

// 一个执行慢但很安全的实现
inline string::operator char*() const
{char *copy = new char[strlen(data) + 1];strcpy(copy, data);  return copy;
}

这个实现很安全，因为它返回的指针所指向的数据只是string对象所指向数据的拷贝；通过函数返回的指针无法修改string对象的值。当然，安全是要有代价的：这个版本的string::operator char* 运行起来比前面那个简单版本要慢；此外，函数的调用者还要记得delete掉返回的指针。

如果不能忍受这个版本的速度，或者担心内存泄露，可以来一点小小的改动：使函数返回一个指向const char的指针：

class string 
{
public:operator const char *() const;  //...  
};inline string::operator const char*() const
{ return data; }

这个函数既快又安全。虽然它和最初给出的那个函数不一样，但它可以满足大多数程序的需要。这个做法还和c++标准组织处理string/char*难题的方案一致：标准string类型中包含一个成员函数c_str，它的返回值是string的const char*版本。关于标准string类型的更多信息参见条款49。

指针并不是返回内部数据句柄的唯一途径。引用也很容易被滥用。下面是一种常见的用法，还是拿string类做例子：

class string 
{
public://...  char& operator[](int index) const{ return data[index]; }private:char *data;
};string s = "i'm not constant";
s[0] = 'x';               // 正确, s不是const
const string cs = "i'm constant";
cs[0] = 'x';              // 修改了const string，但编译器不会通知

注意string::operator[]是通过引用返回结果的。这意味着函数的调用者得到的是内部数据data[index]的另一个名字，而这个名字可以用来修改const对象的内部数据。这个问题和前面看到的相同，只不过这次的罪魁祸首是引用，而不是指针。

这类问题的通用解决方案和前面关于指针的讨论一样：或者使函数为非const，或者重写函数，使之不返回句柄。如果想让string::operator[]既适用于const对象又适用于非const 对象，可以参见条款21。

并不是只有const成员函数需要担心返回句柄的问题，即使是非const成员函数也得承认：句柄的合法性失效的时间和它所对应的对象是完全相同的。这个时间可能比用户期望的要早很多，特别是当涉及的对象是由编译器产生的临时对象时。

例如，看看这个函数，它返回了一个string对象：

string somefamousauthor()   // 随机选择一个作家名并返回之
{switch (rand() % 3)     // rand()在<stdlib.h>中(还有<cstdlib>。参见条款49){case 0:return "margaret mitchell";     // 此作家曾写了 "飘"，一部绝对经典的作品case 1:return "stephen king";          // 他的小说使得许多人彻夜不眠case 2:return "scott meyers";          // 嗯...滥竽充数的一个}                                                                    return "";    // 程序不会执行到这儿，但对于一个有返回值的函数来说，任何执行途径上都要有返回值}

希望你的注意力不要集中在随机数是怎样从rand产生的问题上，也不要嘲笑我把自己和这些作家联系在一起。真正要注意的是，somefamousauthor的返回值是一个string对象，一个临时string对象（参见条款m19）。这样的对象是暂时性的，它们的生命周期通常在函数调用表达式结束时终止。例如上面的情况中，包含somefamousauthor函数调用的表达式结束时，返回值对象的生命周期也就随之结束。

具体看看下面这个使用somefamousauthor的例子，假设string声明了一个上面的operator const char*成员函数：

const char *pc = somefamousauthor();
cout << pc;                   

不论你是否相信，谁也不能预测这段代码将会做些什么，至少不能确定它会做些什么。因为当你想打印pc所指的字符串时，字符串的值是不确定的。造成这一结果的原因在于pc初始化时发生了下面这些事件：

1. 产生一个临时string对象用以保存somefamousauthor的返回值。
2. 通过string的operator const char*成员函数将临时string对象转换为const char*指针，并用这个指针初始化pc。
3. 临时string对象被销毁，其析构函数被调用。析构函数中，data指针被删除（代码详见条款11）。然而，data和pc所指的是同一块内存，所以现在pc指向的是被删除的内存--------其内容是不可确定的。

避免这样的成员函数：其返回值是指向成员的非const指针或引用，但成员的访问级比这个函数要低

使一个成员为private或protected的原因是想限制对它的访问，对吗？劳累的编译器要费九牛二虎之力来确保你设置的访问限制不被破坏，对不对？所以，写个函数来让用户随意地访问受限的成员没多大意义，对不对？如果你确实认为有意义，那么请反复阅读本段，直到你不这样认为为止。

实际编程中很容易违反这条规则，下面是个例子：

class Address { ... };           // 某人居住在此class Person 
{
public:Address& personaddress() { return address; }//...private:Address address;//...
};

成员函数personaddress为调用者提供的是person对象中所包含的address对象，但是，也许是出于效率上的考虑，返回结果采用的是引用，而不是值（见条款22）。遗憾的是，这个成员函数的做法有违当初将person::address声明为private的初衷：

Person scott(...);             // 为简化省略了参数
Address& addr = scott.personaddress();               // 假设addr为全局变量

现在，全局对象addr成为了scott.address的另一个名字，利用它可以随意读写scott.address。实际上，scott.address不再为private，而是public，访问级提升的根源在于成员函数personaddress。当然，本例中给出的address 的访问级是private，如果是protected，情况完全一样。

不仅仅是引用，指针也会产生以上问题。下面的例子和上面相同，只不过这次用的是指针：

class Person 
{
public:address * Personaddress() { return &address; }//...private:address address;//...
};address *addrptr = scott.Personaddress();        // 问题和上面一样

而且，对于指针来说，要担心的不仅仅是数据成员，还要考虑到成员函数。因为返回一个成员函数的指针也是有可能的：

class Person;    // 提前声明// ppmf = "pointer to Person member function"
// (指向Person成员函数的指针)
typedef void (Person::*ppmf)();class Person 
{
public:static ppmf verificationfunction(){ return &Person::verifyaddress; }//...private:address address;    void verifyaddress();
};

如果你过去没试过象上面那样将成员函数指针和typedef结合起来的用法，可能会觉得Person::verificationfunction的声明有点吓人。别害怕，它的全部含义只不过是：

• verificationfunction是一个没有输入参数的成员函数
• 它的返回值是Person类中一个成员函数的指针
• 被指向的函数（即，verificationfunction的返回值）没有输入参数且没有返回值，即void。

不要返回局部对象的引用，也不要返回函数内部用new初始化的指针的引用

本条款听起来很复杂，其实不然。它只是一个很简单的道理，真的，相信我。

先看第一种情况：返回一个局部对象的引用。它的问题在于，局部对象 ----- 顾名思义 ---- 仅仅是局部的。也就是说，局部对象是在被定义时创建，在离开生命空间时被销毁的。所谓生命空间，是指它们所在的函数体。当函数返回时，程序的控制离开了这个空间，所以函数内部所有的局部对象被自动销毁。因此，如果返回局部对象的引用，那个局部对象其实已经在函数调用者使用它之前被销毁了。

当想提高程序的效率而使函数的结果通过引用而不是值返回时，这个问题就会出现。下面的例子和条款23中的一样，其目的在于详细说明什么时候该返回引用，什么时候不该：

class Rational  // 一个有理数类
{          
public:Rational(int numerator = 0, int denominator = 1);~Rational();//...private:int n, d;               // 分子和分母// 注意operator* (不正确地)返回了一个引用friend const Rational& operator*(const Rational& lhs, const Rational& rhs);
};// operator*不正确的实现
inline const Rational& operator*(const Rational& lhs, const Rational& rhs)
{Rational result(lhs.n * rhs.n, lhs.d * rhs.d);return result;
}

这里，局部对象result在刚进入operator*函数体时就被创建。但是，所有的局部对象在离开它们所在的空间时都要被自动销毁。具体到这个例子来说，result是在执行return语句后离开它所在的空间的。所以，如果这样写：
        Rational two = 2;
        Rational four = two * two;       // 同operator*(two, two)

函数调用时将发生如下事件：

1. 局部对象result被创建。
2. 初始化一个引用，使之成为result的另一个名字；这个引用先放在另一边，留做operator*的返回值。
3. 局部对象result被销毁，它在堆栈所占的空间可被本程序其它部分或其他程序使用。
4. 用步骤2中的引用初始化对象four。

// operator*的另一个不正确的实现
inline const Rational& operator*(const Rational& lhs, const Rational& rhs)
{// create a new object on the heapRational *result = new Rational(lhs.n * rhs.n, lhs.d * rhs.d);// return itreturn *result;
}

这个方法的确避免了上面例子中的问题，但却引发了新的难题。大家都知道，为了在程序中避免内存泄漏，就必须确保对每个用new产生的指针调用delete，但是，这里的问题是，对于这个函数中使用的new，谁来进行对应的delete调用呢？

显然，operator*的调用者应该负责调用delete。真的显然吗？遗憾的是，即使你白纸黑字将它写成规定，也无法解决问题。之所以做出这么悲观的判断，是基于两条理由：

第一，大家都知道，程序员这类人是很马虎的。这不是指你马虎或我马虎，而是指，没有哪个程序员不和某个有这类习性的人打交道。想让这样的程序员记住无论何时调用operator*后必须得到结果的指针然后调用delete，这样的几率有多大呢？也是说，他们必须这样使用operator*：

const Rational& four = two * two;      // 得到废弃的指针；将它存在一个引用中
//...
delete &four;                          // 得到指针并删除

Rational one(1), two(2), three(3), four(4);
Rational product;product = one * two * three * four;

product = operator*(operator*(operator*(one, two), three), four);

const Rational& temp1 = one * two;
const Rational& temp2 = temp1 * three;
const Rational& temp3 = temp2 * four;delete &temp1;
delete &temp2;
delete &temp3;

尽可能地推迟变量的定义

C语言中同意把变量要放在模块头部定义的规定；但在C++中，还是取消这种做法吧，它没必要，不自然，而且昂贵。

还记得吗？如果定义了一个有构造函数和析构函数的类型的变量，当程序运行到变量定义之处时，必然面临构造的开销；当变量离开它的生命空间时，又要承担析构的开销。这意味着定义无用的变量必然伴随着不必要的开销，所以只要可能，就要避免这种情况发生。

正如我所知道的，你的编程方式优雅而不失老练。所以你可能会在想，你决不会定义一个无用的变量，所以本条款的建议不适用于你严谨紧凑的编程风格。但别急，看看下面这个函数：当口令够长时，它返回口令的加密版本；当口令太短时，函数抛出logic_error类型的异常（logic_error类型在C++标准库中定义，参见条款49）：

// 此函数太早定义了变量"encrypted"
string encryptPassword(const string& password)
{string encrypted;if (password.length() < MINIMUM_PASSWORD_LENGTH) {throw logic_error("Password is too short");}进行必要的操作，将口令的加密版本  放进encrypted之中;return encrypted;
}

// 这个函数推迟了encrypted的定义，
// 直到真正需要时才定义
string encryptPassword(const string& password)
{if (password.length() < MINIMUM_PASSWORD_LENGTH) {throw logic_error("Password is too short");}string encrypted;进行必要的操作，将口令的加密版本  放进encrypted之中;return encrypted;
}

// 这个函数推迟了encrypted的定义，
// 直到需要时才定义，但还是很低效
string encryptPassword(const string& password)
{//...                      // 同上，检查长度string encrypted;        // 缺省构造encryptedencrypted = password;    // 给encrypted赋值encrypt(encrypted);return encrypted;
}

// 定义和初始化encrypted的最好方式
string encryptPassword(const string& password)
{//...                             // 检查长度string encrypted(password);     // 通过拷贝构造函数定义并初始化encrypt(encrypted);return encrypted;
}

明智地使用内联(inline)

内联函数------多妙的主意啊！它们看起来象函数，运作起来象函数，比宏(macro)要好得多（参见条款1），使用时还不需要承担函数调用的开销。你还能对它们要求更多吗？

然而，你从它们得到的确实比你想象的要多，因为避免函数调用的开销仅仅是问题的一个方面。为了处理那些没有函数调用的代码，编译器优化程序本身进行了专门的设计。所以当内联一个函数时，编译器可以对函数体执行特定环境下的优化工作。这样的优化对"正常"的函数调用是不可能的。

我们还是不要扯得太远。程序世界和现实生活一样，从来就没有免费的午餐，内联函数也不例外。内联函数的基本思想在于将每个函数调用以它的代码体来替换。用不着统计专家出面就可以看出，这种做法很可能会增加整个目标代码的体积。在一台内存有限的计算机里，过分地使用内联所产生的程序会因为有太大的体积而导致可用空间不够。即使可以使用虚拟内存，内联造成的代码膨胀也可能会导致不合理的页面调度行为（系统颠簸），这将使你的程序运行慢得象在爬。（当然，它也为磁盘控制器提供了一个极好的锻炼方式:)）过多的内联还会降低指令高速缓存的命中率，从而使取指令的速度降低，因为从主存取指令当然比从缓存要慢。

另一方面，如果内联函数体非常短，编译器为这个函数体生成的代码就会真的比为函数调用生成的代码要小许多。如果是这种情况，内联这个函数将会确实带来更小的目标代码和更高的缓存命中率！

要牢记在心的一条是，inline指令就象register，它只是对编译器的一种提示，而不是命令。也就是说，只要编译器愿意，它就可以随意地忽略掉你的指令，事实上编译器常常会这么做。例如，大多数编译器拒绝内联"复杂"的函数（例如，包含循环和递归的函数）；还有，即使是最简单的虚函数调用，编译器的内联处理程序对它也爱莫能助。（这一点也不奇怪。virtual的意思是"等到运行时再决定调用哪个函数"，inline的意思是"在编译期间将调用之处用被调函数来代替"，如果编译器甚至还不知道哪个函数将被调用，当然就不能责怪它拒绝生成内联调用了）。以上可以归结为：一个给定的内联函数是否真的被内联取决于所用的编译器的具体实现。幸运的是，大多数编译器都可以设置诊断级，当声明为内联的函数实际上没有被内联时，编译器就会为你发出警告信息（参见条款48）。

假设写了某个函数f并声明为inline，如果出于什么原因，编译器决定不对它内联，那将会发生些什么呢？最明显的一个回答是将f作为一个非内联函数来处理：为f生成代码时就象它是一个普通的"外联"函数一样， 对f的调用也象对普通函数调用那样进行。

理论上来说确实应该这样发生，但理论和现实往往会偏离，现在就属于这种情况。因为，这个方案对解决"被外联的内联"（outlined inline）这一问题确实非常理想，但它加入到C++标准中的时间相对较晚。较早的C++规范（比如ARM------参见条款50）告诉编译器制造商去实现的是另外不同的行为，而且这一旧的行为在现在的编译器中还很普遍，所以必须理解它是怎么一回事。

稍微想一想你就可以记起，内联函数的定义实际上都是放在头文件中。这使得多个要编译的单元（源文件）可以包含同一个头文件，共享头文件内定义的内联函数所带来的益处。下面给出了一个例子，例子中的源文件名以常规的".cpp"结尾，这应该是C++世界最普遍的命名习惯了：

 // 文件example.hinline void f() { ... }          // f的定义...// 文件source1.cpp#include "example.h"             // 包含f的定义...                              // 包含对f的调用// 文件source2.cpp#include "example.h"             // 也包含f的定义...                              // 也调用f 

inline void f() {...}            // 同上
void (*pf)() = f;                // pf指向f
int main()
{f();                           // 对f的内联调用pf();                          // 通过pf对f的非内联调用...
} 

class Base {
public:...
private:string bm1, bm2;   // 基类成员1和2
};
class Derived: public Base {
public:Derived() {}                  // Derived的构造函数是空的，//...                           // ------但，真的是空的吗？
private:string dm1, dm2, dm3;         // 派生类成员1-3
}; 

// 一个Derived构造函数的可能的实现 
Derived::Derived()
{// 如果在堆上创建对象，为其分配堆内存；// operator new的介绍参见条款8if (本对象在堆上)this = ::operator new(sizeof(Derived));Base::Base();                  // 初始化Base部分dm1.string();           // 构造dm1dm2.string();           // 构造dm2dm3.string();           // 构造dm3
} 

class Person {
public:int age() const { return personAge; }//...
private:int personAge;//...
}; 

6. 继承与面向对象设计

很多人认为，继承是面向对象程序设计的全部。这个观点是否正确还有待争论，但本书其它章节的条款数量足以证明，在进行高效的C++程序设计时，还有更多的工具听你调遣，而不仅仅是简单地让一个类从另一个类继承。

然而，设计和实现类的层次结构与C语言中的一切都有着根本的不同。只有在继承和面向对象设计领域，你才最有可能从根本上重新思考软件系统构造的方法。另外，C++提供了多种很令人困惑的面向对象构造部件，包括公有、保护和私有基类；虚拟和非虚拟基类；虚拟和非虚拟成员函数。这些部件不仅互相之间有联系，还和C++的其它部分相互作用。所以，对于每种部件的含义、什么时候该用它们、怎样最好地和C++中非面向对象部分相结合 ---- 要想真正理解这些，就要付出艰苦的努力。

使得事情更趋复杂的另一个原因是，C++中很多不同的部件或多或少地好象都在做相同的事。例如：

• 假如需要设计一组具有共同特征的类，是该使用继承使得所有的类都派生于一个共同的基类呢，还是使用模板使得它们都从一个共同的代码框架中产生？
• 类A的实现要用到类B，是让A拥有一个类型为B的数据成员呢，还是让A私有继承于B？
• 假设想设计一个标准库中没有提供的、类型安全的同族容器类（条款49列出了标准库实际提供的容器类），是使用模板呢，还是最好为某个 "自身用普通（void*）指针来实现" 的类建立类型安全的接口呢？

条款32：public继承是一个is-a模型

在"Some Must Watch While Some Must Sleep"（ W. H. Freeman and Company, 1974）一书中，William Dement讲了一个故事，故事说的是他如何让学生们记住他的课程中最重要的部分。"据说，"，他告诉他的学生，"一般的英国学生除了记得Hastings战役发生在1066年外，再也不记得其它历史。"， "如果一个小孩不记得别的历史，" Dement强调说，"也一定记得1066这个日子。" 但对于他班上的学生来说，只有很少一些话题可以引起他们的兴趣，比如，安眠药会引起失眠之类。所以他哀求他的学生，即使忘掉他在课堂上讲授的其它任何东西，也要记住那些仅有的几个重要的历史事件。而且，他在整个学期不停地对学生灌输这一基本观点。

学期结束时，期末考试的最后一道题是，"请写下你从课程中学到的一辈子都会记住的东西"。当Dement评改试卷时，他大吃一惊。几乎所有学生都写下了 "1066"。

所以，在这里我也以极度颤抖的声音告诉你，C++面向对象编程中一条重要的规则是：公有继承意味着 "是一个" 。一定要牢牢记住这条规则。

当写下类D（"Derived" ）从类B（"Base"）公有继承时，你实际上是在告诉编译器（以及读这段代码的人）：类型D的每一个对象也是类型B的一个对象，但反之不成立；你是在说：B表示一个比D更广泛的概念，D表示一个比B更特定概念；你是在声明：任何可以使用类型B的对象的地方，类型D的对象也可以使用，因为每个类型D的对象是一个类型B的对象。相反，如果需要一个类型D的对象，类型B的对象就不行：每个D "是一个" B， 但反之不成立。

C++采用了公有继承的上述解释。看这个例子：

class Person { ... };class Student: public Person { ... };

从日常经验中我们知道，每个学生是人，但并非每个人是学生。这正是上面的层次结构所声明的。我们希望，任何对 "人" 成立的事实 ---- 如都有生日 ----也对 "学生" 成立；但我们不希望，任何对 "学生" 成立的事实 ---- 如都在某一学校上学 ----也对 "人" 成立。人的概念比学生的概念更广泛；学生是一种特定类型的人。

在C++世界中，任何一个其参数为Person类型的函数（或Person的指针或Person的引用）可以实际取一个Student对象（或Student的指针或Student的引用）：

void dance(const Person& p);        // 任何人可以跳舞
void study(const Student& s);       // 只有学生才学习
Person p;                           // p是一个人
Student s;                          // s是一个学生
dance(p);                           // 正确，p是一个人
dance(s);                           // 正确，s是一个学生，一个学生"是一个"人
study(s);                           // 正确
study(p);                           // 错误! p不是学生

只是公有继承才会这样。也就是说，只是Student公有继承于Person时，C++的行为才会象我所描述的那样。私有继承则是完全另外一回事（见条款42），至于保护继承，好象没有人知道它是什么含义。另外，Student "是一个" Person的事实并不说明Student的数组 "是一个" Person数组。关于这一话题的讨论参见条款M3。

公有继承和 "是一个" 的等价关系听起来简单，但在实际应用中，可能不会总是那么直观。有时直觉会误导你。例如，有这样一个事实：企鹅是鸟；还有这样一个事实：鸟会飞。如果想简单地在C++中表达这些事实，我们会这样做：

class Bird 
{
public:virtual void fly();       // 鸟会飞  //...
};class Penguin:public Bird     // 企鹅是鸟
{      //...
};

class Bird 
{//...         // 没有声明fly函数
}; class FlyingBird: public Bird 
{
public:virtual void fly();//...
};class NonFlyingBird: public Bird 
{//...      //  没有声明fly函数
};class Penguin: public NonFlyingBird 
{//...       //  没有声明fly函数
};

void error(const string& msg);      // 在别处定义class Penguin: public Bird 
{
public:virtual void fly() { error("Penguins can't fly!"); }  //...
};

解释型语言如Smalltalk喜欢采用这种方法，但这里要认识到的重要一点是，上面的代码所说的可能和你所想的是完全不同的两回事。它不是说，"企鹅不会飞"，而是说，"企鹅会飞，但让它们飞是一种错误"。

怎么区分二者的不同？这可以从检测到错误发生的时间来区分。"企鹅不会飞" 的指令是由编译器发出的，"让企鹅飞是一种错误" 只能在运行时检测到。

为了表示 "企鹅不会飞" 这一事实，就不要在Penguin对象中定义fly函数：

class Bird 
{//...     // 没有声明fly函数                            
};class NonFlyingBird: public Bird 
{//...    // 没有声明fly函数                              
};class Penguin: public NonFlyingBird 
{//...     // 没有声明fly函数
};

Penguin p;
p.fly();    // 错误!

"当然可以！" 你会不屑地说，"每个人都知道一个正方形是一个矩形，但反过来通常不成立。" 确实如此，至少在高中时可以这样认为。但我不认为我们还是高中生。

看看下面的代码：

class Rectangle 
{
public:virtual void setHeight(int newHeight);virtual void setWidth(int newWidth);virtual int height() const;          // 返回当前值virtual int width() const;           // 返回当前值//...};void makeBigger(Rectangle& r)          // 增加r面积的函数
{                                      int oldHeight = r.height();r.setWidth(r.width() + 10);          // 对r的宽度增加10assert(r.height() == oldHeight);     // 断言r的高度未变
}         

很明显，断言永远不会失败。makeBigger只是改变了r的宽度，高度从没被修改过。
现在看下面的代码，它采用了公有继承，使得正方形可以被当作矩形来处理：

class Square: public Rectangle { ... };
Square s;
//...
assert(s.width() == s.height());      // 这对所有正方形都成立
makeBigger(s);                        // 通过继承，s "是一个" 矩形所以可以增加它的面积                                     
assert(s.width() == s.height());      // 这还是对所有正方形成立

• 调用makeBigger前，s的宽和高相等；
• makeBigger内部，s的宽度被改变，高度未变；
• 从makeBigger返回后，s的高度又和宽度相等。（注意s是通过引用传给makeBigger的，所以makeBigger修改了s本身，而不是s的拷贝）

条款33：避免遮掩继承而来的名称--隐藏与覆写

Avoid hiding inherited names

子作用域会遮掩父作用域的名称。一般来讲，我们可以有以下几层作用域

1. global作用域
2. namespace作用域
   1. Base class作用域
      1. Drive class作用域
         • 成员函数
           • 控制块作用域
   2. 非成员函数作用域
      • 控制块作用域

当发生继承时，基类是一个作用域，派生类是在基类作用域中的另一个作用域。

注意：遮掩的是上一层作用域的名称，重载(不同参数)的函数也会直接遮掩

在函数中局部声明的名字将屏蔽在全局作用域内声明的同名名字。这个关于变量名字的性质对于函数名同样成立。

一般的作用域规则同样适用于重载函数名。如果局部地声明一个函数，则该函数将屏蔽而不是重载在外层作用域中声明的同名函数。由此推论，每一个版本的重载函数都应在同一个作用域中声明。

void print(const string &);
void print(double);       // overloads the print function
void fooBar(int ival)
{void print(int);   // new scope: hides previous instances of printprint("Value: ");  // error: print(const string &) is hiddenprint(ival);       // ok: print(int) is visibleprint(3.14);       // ok: calls print(int); print(double) is hidden
}

函数 fooBar 中的 print(int) 声明将屏蔽 print 的其他声明，就像只有一个有效的 print 函数一样：该函数仅带有一个 int 型形参。在这个作用域或嵌套在这个作用域里的其他作用域中，名字 print 的任何使用都将解释为这个print 函数实例。

调用 print 时，编译器首先检索这个名字的声明，找到只有一个 int 型形参的print 函数的局部声明。一旦找到这个名字，编译器将不再继续检查这个名字是否在外层作用域中存在，即编译器将认同找到的这个声明即是程序需要调用的函数，余下的工作只是检查该名字的使用是否有效。

第一个函数调用传递了一个字符串字面值，但是函数的形参却是 int 型的。字符串字面值无法隐式地转换为 int 型，因而该调用是错误的。print(conststring&) 函数与这个函数调用匹配，但已被屏蔽，因此不在解释该调用时考虑。当传递一个 double 数据调用 print 函数时，编译器重复了同样的匹配过程：首先检索到 print(int) 局部声明，然后将 double 型的实参隐式转换为 int型。因此，该调用合法。

另一种情况是，在与其他 print 函数相同的作用域中声明 print(int)，这样，它就成为 print 函数的另一个重载版本。此时，所有的调用将以不同的方式解释：

void print(const string &);
void print(double);   // overloads print function
void print(int);      // another overloaded instance
void fooBar2(int ival)
{print("Value: "); // ok: calls print(const string &)print(ival);      // ok: print(int)print(3.14);      // ok: calls print (double)
}

现在，编译器在检索名字 print 时，将找到这个名字的三个函数。每一个调用都将选择与其传递的实参相匹配的 print 版本。

在类中 基类和派生类不同作用域的隐藏和覆写

（隐藏就是内层作用域中的名字屏蔽掉外层作用域中的同名名字。覆写就是派生类重写基类的虚函数）

class Base{
public:void f1();
}class Drive{
public://会遮掩f1()，子类并没有继承f1()void f1(int);
}Drive d;
d.f1();  //错误
d.f1(3); //正确

可以通过using声明式或者inline转交解决这一问题

class Base{
public:void f1();
}//using 声明式
class Drive{
public:using Base::f1;void f1(int);
}//inline转交
class Drive{
public:void f1(){Base::f1();}void f1(int);
}

其实这一条款主要是和作用域相关

条款34：区分接口继承和实现继承

Differentiate between inheritance of interface and inheritance of implementation

1. 纯虚函数：提供接口继承
   1. Drived class必须实现纯虚函数
   2. 不能构造含有纯虚函数的类
   3. 纯虚函数可以有成员变量
   4. 可以给纯虚函数提供定义(wtf)
2. 虚函数：提供 接口继承 和 默认的实现继承
3. 非虚函数：提供了接口继承和强制的实现继承(最好不要在Drived class重新定义非虚函数)

public继承 的概念看起来很简单，进一步分析，会发现它由两个可分的部分组成：函数接口的继承和函数实现的继承。

这两种继承类型的区别和本书简介中所讨论的函数声明和函数定义间的区别是完全一致的。

作为类的设计者，有时希望派生类只继承成员函数的接口（也就是声明）；有时希望派生类同时继承函数的接口和实现，但允许派生类改写实现；有时则希望同时继承接口和实现，并且不允许派生类改写任何东西。

为了更好地体会这些选择间的区别，看下面这个类层次结构，它用来表示一个图形程序中的几何形状：

class Shape 
{
public:virtual void draw() const = 0;  virtual void error(const string& msg);  int objectID() const;  //...
};class Rectangle: public Shape { ... };
class Ellipse: public Shape { ... };

纯虚函数draw使得Shape成为一个抽象类。所以，用户不能创建Shape类的实例，只能创建它的派生类的实例。但是，从Shape（公有）继承而来的所有类都受到Shape的巨大影响，因为：

成员函数的接口总会被继承。正如条款32所说明的，公有继承的含义是 "是一个（is-a）" ，所以对基类成立的所有事实也必须对派生类成立。因此，如果一个函数适用于某个类，也必将适用于它的子类。

Shape类中声明了三个函数。第一个函数，draw，在某一画面上绘制当前对象。第二个函数，error，被其它成员函数调用，用于报告出错信息。第三个函数，objectID，返回当前对象的一个唯一整数标识符（条款17给出了一个怎样使用这种函数的例子）。每个函数以不同的方式声明：draw是一个纯虚函数；error是一个简单的（非纯?）虚函数；objectID是一个非虚函数。这些不同的声明各有什么含义呢？

声明一个纯虚函数目的是为了让派生类只继承函数接口。

首先看纯虚函数draw。纯虚函数最显著的特征是：它们必须在继承了它们的任何具体类中重新声明，而且它们在抽象类中往往没有定义。把这两个特征放在一起，就会认识到：声明或者定义纯虚函数的目的在于，使派生类仅仅只是继承函数的接口。

这对Shape::draw函数来说非常有意义，因为，让所有Shape对象都可以被绘制是很合理，但Shape类无法为Shape::draw提供一个合理的缺省实现。例如，绘制椭园的算法就和绘制矩形的算法大不一样。打个比方来说，上面Shape::draw的声明就象是在告诉子类的设计者，"你必须提供一个draw函数，但我不知道你会怎样实现它。"

顺便说一句，为一个纯虚函数提供定义也是可能的。也就是说，你可以为Shape::draw提供实现，C++编译器也不会阻拦，但调用它的唯一方式是通过类名完整地指明是哪个调用：

Shape *ps = new Shape;           // 错误! Shape是抽象的Shape *ps1 = new Rectangle;      // 正确
ps1->draw();                     // 调用Rectangle::drawShape *ps2 = new Ellipse;        // 正确
ps2->draw();                     // 调用Ellipse::drawps1->Shape::draw();              // 调用Shape::draw
ps2->Shape::draw();              // 调用Shape::draw

一般来说，除了能让你在鸡尾酒会上给你的程序员同行留下深刻印象外，了解这种用法一般没大的作用。然而，正如后面将看到的，它可以被应用为一种机制，为简单的（非纯）虚函数提供 "比一般做法更安全" 的缺省实现。

有时，声明一个除纯虚函数外什么也不包含的类很有用。这样的类叫协议类（Protocol class），它为派生类仅提供函数接口，完全没有实现。协议类在条款34中介绍过，并将在条款43再次提及。

声明虚函数（非纯虚函数）的目的是为了让派生类继承该函数的接口和缺省实现
简单虚函数的情况和纯虚函数有点不一样。照例，派生类继承了函数的接口，但简单虚函数一般还提供了实现，派生类可以选择改写它们或不改写它们。思考片刻就可以认识到：声明简单虚函数的目的在于，使派生类继承函数的接口和缺省实现。

具体到Shape::error，这个接口是在说，每个类必须提供一个出错时可以被调用的函数，但每个类可以按它们认为合适的任何方式处理错误。如果某个类不想做什么特别的事，可以借助于Shape类中提供的缺省出错处理函数。也就是说，Shape::error的声明是在告诉子类的设计者，"你必须支持error函数，但如果你不想写自己的版本，可以借助Shape类中的缺省版本。"

实际上，为简单虚函数同时提供函数声明和缺省实现是很危险的。想知道为什么，看看XYZ航空公司的这个飞机类的层次结构。XYZ公司只有两种飞机，A型和B型，而且两种机型的飞行方式完全一样。所以，XYZ设计了这样的层次结构：

class Airport  // 表示飞机
{ //... 
};      class Airplane 
{
public:virtual void fly(const Airport& destination);   //...    
};void Airplane::fly(const Airport& destination)
{//飞机飞往某一目的地的缺省代码
}class ModelA: public Airplane { /* ... */ };
class ModelB: public Airplane { /* ... */ };

为了表明所有飞机都必须支持fly函数，而且因为不同型号的飞机原则上都需要对fly有不同的实现， 所以Airplane::fly被声明为virtual。但是，为了避免在ModelA类和ModelB类中写重复的代码，缺省的飞行行为是由Airplane::fly函数提供的，ModelA和ModelB继承了这一函数。

这是典型的面向对象设计。两个类享有共同的特征（实现fly的方式），所以这一共同特征被转移到基类，并让这两个类来继承这一特征。这种设计使得共性很清楚，避免了代码重复，将来容易增强功能，并易于长期维护 ---- 所有这一切正是面向对象技术高度吹捧的。XYZ公司真得为此而骄傲。

现在假设XYZ公司发了大财，决定引进一种新型飞机，C型。C型和A型、B型有区别，特别是，飞行方式不一样。

XYZ的程序员在上面的层次结构中为C型增加了一个类，但因为急于使新型飞机投入使用，他们忘了重新定义fly函数：

class ModelC: public Airplane {//...                          // 没有声明fly函数
};

Airport JFK(...);              // JFK是纽约市的一个机场
Airplane *pa = new ModelC;
//...
pa->fly(JFK);                  // 调用Airplane::fly!

这里的问题不在于Airplane::fly具有缺省行为，而在于ModelC可以不用明确地声明就可以继承这一行为。幸运的是，可以很容易做到为子类提供缺省行为、同时只是在子类想要的时候才给它们。窍门在于切断虚函数的接口和它的缺省实现之间的联系。下面是一种方法：

class Airplane {
public:virtual void fly(const Airport& destination) = 0;//...protected:void defaultFly(const Airport& destination);
};void Airplane::defaultFly(const Airport& destination)
{//飞机飞往某一目的地的缺省代码
}

class ModelA: public Airplane {
public:virtual void fly(const Airport& destination){ defaultFly(destination); }//...
};class ModelB: public Airplane {
public:virtual void fly(const Airport& destination){ defaultFly(destination); }//...
};

class ModelC: public Airplane {
public:virtual void fly(const Airport& destination);//...
};void ModelC::fly(const Airport& destination)
{//ModelC飞往某一目的地的代码
}

class Airplane {
public:virtual void fly(const Airport& destination) = 0;//...
};void Airplane::fly(const Airport& destination)
{//飞机飞往某一目的地的缺省代码
}class ModelA: public Airplane {
public:virtual void fly(const Airport& destination){ Airplane::fly(destination); }//...
};class ModelB: public Airplane {
public:virtual void fly(const Airport& destination){ Airplane::fly(destination); }//...
};class ModelC: public Airplane {
public:virtual void fly(const Airport& destination);//...
};void ModelC::fly(const Airport& destination)
{ModelC飞往某一目的地的代码
}

非虚函数
最后，来谈谈Shape的非虚函数，objectID。当一个成员函数为非虚函数时，它在派生类中的行为就不应该不同。实际上，非虚成员函数表明了一种特殊性上的不变性，因为它表示的是不会改变的行为 ---- 不管一个派生类有多特殊。所以，

· 声明非虚函数的目的在于，使派生类继承函数的接口和强制性实现。

可以认为，Shape::objectID的声明就是在说，"每个Shape对象有一个函数用来产生对象的标识符，并且对象标识符的产生方式总是一样的。这种方式由Shape::objectID的定义决定，派生类不能改变它。" 因为非虚函数表示一种特殊性上的不变性，所以它决不能在子类中重新定义，关于这一点条款37进行了讨论。

理解了纯虚函数、简单虚函数和非虚函数在声明上的区别，就可以精确地指定你想让派生类继承什么：仅仅是接口，还是接口和一个缺省实现？或者，接口和一个强制实现？因为这些不同类型的声明指的是根本不同的事，所以在声明成员函数时一定要从中慎重选择。只有这样做，才可以避免没经验的程序员常犯的两个错误。

第一个错误是把所有的函数都声明为非虚函数。这就使得派生类没有特殊化的余地；非虚析构函数尤其会出问题（参见条款14）。当然，设计出来的类不准备作为基类使用也是完全合理的（条款M34就给出了一个你会这样做的例子）。这种情况下，专门声明一组非虚成员函数是适当的。但是，把所有的函数都声明为非虚函数，大多数情况下是因为对虚函数和非虚函数之间区别的无知，或者是过分担心虚函数对程序性能的影响（参见条款M24）。而事实上是：几乎任何一个作为基类使用的类都有虚函数（再次参见条款14）。

如果担心虚函数的开销，请允许我介绍80-20定律（参见条款M16）。它指出，在一个典型的程序中，80%的运行时间都花在执行20%的代码上。这条定律很重要，因为它意味着，平均起来，80%的函数调用可以是虚函数，并且它们不会对程序的整体性能带来哪怕一丁点可以觉察到的影响。所以，在担心是否承担得起虚函数的开销之前，不妨将注意力集中在那20%会真正带来影响的代码上。

另一个常见的问题是将所有的函数都声明为虚函数。有时这没错 ---- 比如，协议类（Protocol class）就是证据（参见条款34）。但是，这样做往往表现了类的设计者缺乏表明坚定立场的勇气。一些函数不能在派生类中重定义，只要是这种情况，就要旗帜鲜明地将它声明为非虚函数。不能让你的函数好象可以为任何人做任何事 ---- 只要他们花点时间重新定义所有的函数。记住，如果有一个基类B，一个派生类D，和一个成员函数mf，那么下面每个对mf的调用都必须工作正常：

D *pd = new D;
B *pb = pd;pb->mf();                    // 通过基类指针调用mf
pd->mf();                    // 通过派生类指针调用mf

条款35：考虑virtual函数以外的选择

non-virtual interface：提供非虚接口

class Object{
public:void Interface(){···doInterface()；···}
private/protected:virtual doInterface(){}
}

优点：

1. 可以在调用虚函数的前后，做一些准备工作(抽出一段重复代码)
2. 提供良好的ABI兼容性

聊一聊ABI兼容性

我们知道，程序库的优势之一是库版本升级，只要保证借口的一致性，用户不用修改任何代码。

一般一个设计完好的程序库都会提供一份C语言接口，为什么呢，我们来看看C++ ABI有哪些脆弱性。

1. 虚函数的调用方式，通常是 vptr/vtbl 加偏移量调用

//Object.h
class Object{
public:
···virtual print(){}//第3个虚函数
···
}//用户代码
int main(){Object *p = new Object;p->print();                    //编译器：vptr[3]()
}//如果加了虚函数，用户代码根据偏移量找到的是newfun函数
//Object.h
class Object{
public:
···virtual newfun()//第3个虚函数virtual print(){}//第4个虚函数
···
}

1. name mangling 名字粉碎实现重载

C++没有为name mangling制定标准。例如void fun(int)，有的编译器定为fun_int_，有的编译器指定为fun%int%。

因此，C++接口的库要求用户必须和自己使用同样的编译器(这个要求好过分)

1. 其实C语言接口也不完美

例如struct和class。编译阶段，编译器将struct或class的对象对成员的访问通过偏移量来实现

使用std::fun提供回调

class Object{
public:void Interface(){···doInterface()；···}
private/protected:std::function<void()> doInterface;
}

古典策略模式

用另外一个继承体系替代

class Object{
public:void Interface(){···p->doInterface()；···}
private/protected:BaseInterface *p;
}class BaseInterface{
public:virtual void doInterface(){}
}

条款36：不要再重新定义继承过来的非虚函数

有两种方法来看待这个问题：理论的方法和实践的方法。让我们先从实践的方法开始。毕竟，理论家一般都很耐心。

假设类D公有继承于类B，并且类B中定义了一个公有成员函数mf。mf的参数和返回类型不重要，所以假设都为void。换句话说，我这么写：

class B 
{
public:void mf();//...
};class D: public B { ... };

class D: public B 
{
public:void mf();                  // 隐藏了B::mf; 参见条款50//...
};pB->mf();                     // 调用B::mf
pD->mf();                     // 调用D::mf

• 适用于B对象的一切也适用于D对象，因为每个D的对象 "是一个" B的对象。
• B的子类必须同时继承mf的接口和实现，因为mf在B中是非虚函数。

条款37: 决不要重新定义继承而来的缺省参数值

class Base{ 
public:virtual void print(int a = 1) {cout <<"Base "<< a <<endl;};int a;
};class Drive : public Base{
public:void print(int a = 2){cout << "Drive " << a <<endl;}
};                                                                                 int main(){                                                                        Base *b = new Drive;                                                             b->print();   //   vptr[0](1)
}//Drive 1

1. 缺省参数值是静态绑定
2. 虚函数是动态绑定
3. 遵守这条规定防止出错

让我们从一开始就把问题简化。缺省参数只能作为函数的一部分而存在，另外你只有两种函数可以继承：虚函数和非虚函数。因此，重定义缺省参数值的唯一方法是重定义一个继承而来的函数。然而，重定义继承而来的非虚函数是一种错误（参见条款37），所以，我们完全可以把讨论的范围缩小为 "继承一个有缺省参数值的虚函数" 的情况。

既然如此，本条款的理由就变得非常明显：虚函数是动态绑定，而缺省参数值是静态绑定的。

什么意思？你可能会说你不懂这些最新的面向对象术语；或者，过度劳累的你一时想不起静态和动态绑定的区别。那么，让我们来复习一下。

对象的静态类型是指你声明的存在于程序代码文本中的类型。看下面这个类层次结构：

enum ShapeColor { RED, GREEN, BLUE };// 一个表示几何形状的类
class Shape 
{
public:// 所有的形状都要提供一个函数绘制它们本身virtual void draw(ShapeColor color = RED) const = 0;//...
};class Rectangle: public Shape 
{
public:// 注意：定义了不同的缺省参数值 ---- 不好!virtual void draw(ShapeColor color = GREEN) const;//...
};class Circle: public Shape 
{
public:virtual void draw(ShapeColor color) const;//...
};

现在看看这些指针：

Shape *ps;                      // 静态类型 = Shape*
Shape *pc = new Circle;         // 静态类型 = Shape*
Shape *pr = new Rectangle;      // 静态类型 = Shape*

这个例子中， ps， pc，和pr都被声明为Shape指针类型，所以它们都以此作为自己的静态类型。注意，这和它们真的所指向的对象的类型绝对没有关系 ---- 它们的静态类型总是Shape*。

对象的动态类型是由它当前所指的对象的类型决定的。即，对象的动态类型表示它将执行何种行为。上面的例子中，pc的动态类型是Circle*，pr的动态类型是Rectangle*。至于ps，实际上没有动态类型，因为它（还）没有指向任何对象。

动态类型，顾名思义，可以在程序运行时改变，典型的方法是通过赋值：

ps = pc;                        // ps的动态类型现在是Circle*
ps = pr;                        // ps的动态类型现在是Rectangle*

虚函数是动态绑定的，意思是说，虚函数通过哪个对象被调用，具体被调用的函数就由那个对象的动态类型决定：

pc->draw(RED);                  // 调用Circle::draw(RED)
pr->draw(RED);                  // 调用Rectangle::draw(RED)

我知道这些都是老掉牙的知识了，你当然也了解虚函数。（如果想知道它们是怎么实现的，参见条款M24）但是，将虚函数和缺省参数值结合起来分析就会产生问题，因为，如上所述，虚函数是动态绑定的，但缺省参数是静态绑定的。这意味着你最终可能调用的是一个定义在派生类，但使用了基类中的缺省参数值的虚函数：

pr->draw();                     // 调用Rectangle::draw(RED)!

这种情况下，pr的动态类型是Rectangle*，所以Rectangle的虚函数被调用 ---- 正如我们所期望的那样。Rectangle::draw中，缺省参数值是GREEN。但是，由于pr的静态类型是Shape*，这个函数调用的参数值是从Shape类中取得的，而不是Rectangle类！所以结果将十分奇怪并且出人意料，因为这个调用包含了Shape和Rectangle类中Draw的声明的组合。你当然不希望自己的软件以这种方式运行啦；至少，用户不希望这样，相信我。

不用说，ps， pc，和pr都是指针的事实和产生问题的原因无关。如果它们是引用，问题也会继续存在。问题仅仅出在，draw是一个虚函数，并且它的一个缺省参数在子类中被重新定义了。

为什么C++坚持这种有违常规的做法呢？答案和运行效率有关。如果缺省参数值被动态绑定，编译器就必须想办法为虚函数在运行时确定合适的缺省值，这将比现在采用的在编译阶段确定缺省值的机制更慢更复杂。做出这种选择是想求得速度上的提高和实现上的简便，所以大家现在才能感受得到程序运行的高效；当然，如果忽视了本条款的建议，就会带来混乱。

条款38: 通过复合塑模出has-a或者"根据某物实现出"

Model "has-a" or "is-implemented-in-terms-of（根据某物实现出）" through composition

复合（composition）是类型之间的一种关系，当某种类型的对象内含有其他类型的对象时，便是这种关系。也称为 "分层"(Layering)。简单的说：就是使某个类的对象成为另一个类的数据成员，从而实现将一个类构筑在另一个类之上。

class Address { ... };           // 某人居住之处
class PhoneNumber { ... };
class Person {
public://...private:string name;                   // 下层对象Address address;               // 同上PhoneNumber voiceNumber;       // 同上PhoneNumber faxNumber;         // 同上
};

本例中，Person类被认为是置于string，Address和PhoneNumber类的上层，因为它包含那些类型的数据成员。"分层" 这一术语有很多同义词，它也常被称为：构成(composition)，包含(containment)或嵌入(embedding)。

条款35解释了公有继承的含义是 "是一个"。对应地，分层的含义是 "有一个" 或 "用...来实现"。

上面的Person类展示了 "有一个" 的关系。一个Person对象 "有一个" 名字，地址，电话号码和传真号码。你不能说，一个人 "是一个" 名字或一个人 "是一个" 地址；你得说，一个人 "有一个" 名字， "有一个" 地址，等等。大多数人对区分这些没什么困难，所以混淆 "是一个" 和 "有一个" 的情况相对来说比较少见。

稍微有点麻烦的是区分 "是一个" 和 "用...来实现"。例如，假设需要一个类模板，用来表示任意对象的集合，并且集合中没有重复元素。程序设计中，重用（Reuse）是再好不过的一件事了，而且你也许已经读过条款49中关于C++标准库的总体介绍，那么，你的第一反应一定是想采用标准库中的set模板。是啊，既然可以使用别人所写的东西，为什么还要再去写一个新的模板呢？

但是，深入研究set的帮助文档后，你会发现，set的下述限制将不能满足你的程序要求：set要求包含在它内部的元素必须是完全有序的，即，对set中的任两个元素a和b来说，一定可以确定：要么a<b，要么b<a。对许多类型来说，这个要求很容易满足，而且，对象间完全有序使得set可以在性能方面提供某些保证，这一点很吸引人。（参见条款49了解标准库在性能上更多的保证）然而，你所需要的是更广泛的东西：一个类似set的类，但对象不必完全有序；用C++标准所包装的术语来说，它们只需要所谓的 "相等可比较性"：对于同种类型的a和b对象来说，要能确定是否a==b。这种要求更简单，它更适合于那些表示颜色这类东西的类型。总不能说红色比绿色更少或绿色比红色更少吧？看来，对你的程序来说，还是得需要自己来写个模板。

当然，重用还是件好事。作为数据结构专家，你知道，在实现集合的众多选择中，一个最简单的办法是采用链表。你一定猜到了什么。对，标准库中正有这么一个list模板（用来产生链表类）！所以可以重用它。

具体来说，你决定让自己的Set模板从list继承。即，Set<T>将从list<T>继承。因为，在你的实现中，Set对象实际上将是list对象。于是你这样声明Set模板：

// Set中错误地使用了list
template<class T>
class Set: public list<T> { ... };

// Set中使用list的正确方法
template<class T>
class Set {
public:bool member(const T& item) const;void insert(const T& item);void remove(const T& item);int cardinality() const;private:list<T> rep;                       // 表示一个Set
};

template<class T>
bool Set<T>::member(const T& item) const
{ return find(rep.begin(), rep.end(), item) != rep.end(); }template<class T>
void Set<T>::insert(const T& item)
{ if (!member(item)) rep.push_back(item); }template<class T>
void Set<T>::remove(const T& item)
{list<T>::iterator it = find(rep.begin(), rep.end(), item);if (it != rep.end()) rep.erase(it);
}template<class T>
int Set<T>::cardinality() const
{ return rep.size(); }

条款39：明智而审慎的使用private继承

条款32 说明，C++将公有继承视为 "是一个(is-a)" 的关系。它是通过这个例子来证实的：假如某个类层次结构中，Student类从Person类公有继承，为了使某个函数成功调用，编译器可以在必要时隐式地将Student转换为Person。这个例子很值得再看一遍，只是现在，公有继承换成了私有继承：

class Person { ... };
class Student: private Person { ... }; // 这一次我们使用私有继承void dance(const Person& p);  // 每个人会跳舞
void study(const Student& s); // 只有学生才学习Person p;  // p是一个人
Student s; // s是一个学生
dance(p);  // 正确, p是一个人
dance(s);  // 错误！一个学生不是一个人

在弄清含义之前，让我们先看看私有继承有那些行为特征呢？"

关于私有继承的规则

• 第一个规则：private 继承 和 公有继承相反，如果两个类之间的继承关系为私有，编译器一般不会将派生类对象（如Student）转换成基类对象（如Person）。这就是上面的代码中为对象s调用dance会失败的原因。
• 第二个规则：从私有基类继承而来的成员都成为了派生类的私有成员，即使它们在基类中是保护或公有成员。

这为我们引出了私有继承的含义：私有继承意味着 "用...来实现"。如果使类D私有继承于类B，这样做是因为你想利用类B中已经存在的某些代码，而不是因为类型B的对象和类型D的对象之间有什么概念上的关系。因而，私有继承纯粹是一种实现技术。用条款36引入的术语来说，私有继承意味着只是继承实现，接口会被忽略。如果D私有继承于B，就是说D对象在实现中用到了B对象，仅此而已。私有继承在软件 "设计" 过程中毫无意义，只是在软件 "实现" 时才有用。

私有继承意味着 "用...来实现" 这一事实会给程序员带来一点混淆，因为条款38指出，"分层" 也具有相同的含义。怎么在二者之间进行选择呢？答案很简单：尽可能地使用分层，必须时才使用私有继承。什么时候必须呢？这往往是指有保护成员和/或虚函数介入的时候 ---- 但这个问题过一会儿再深入讨论。

条款41提供了一种方法来写一个Stack 模板，此模板生成的类保存不同类型的对象。你应该熟悉一下那个条款。模板是C++最有用的组成部分之一，但一旦开始经常性地使用它，你会发现，如果实例化一个模板一百次，你就可能实例化了那个模板的代码一百次。例如Stack模板，构成Stack<int>成员函数的代码和构成Stack<double>成员函数的代码是完全分开的。有时这是不可避免的，但即使模板函数实际上可以共享代码，这种代码重复还是可能存在。这种目标代码体积的增加有一个名字：模板导致的 "代码膨胀"。这不是件好事。

对于某些类，可以采用通用指针来避免它。采用这种方法的类存储的是指针，而不是对象，实现起来就是：

• 创建一个类，它存储的是对象的void*指针。
• 创建另外一组类，其唯一目的是用来保证类型安全。这些类都借助第一步中的通用类来完成实际工作。

class GenericStack 
{
public:GenericStack();~GenericStack();void push(void *object);void * pop();bool empty() const;private:struct StackNode {void *data; // 节点数据StackNode *next; // 下一节点StackNode(void *newData, StackNode *nextNode): data(newData), next(nextNode) {}};StackNode *top; // 栈顶GenericStack(const GenericStack& rhs); // 防止拷贝和GenericStack& operator=(const GenericStack& rhs); // 赋值(参见条款27)
};

仅仅有GenericStack这一个类是没有什么用处的，但很多人会很容易误用它。例如，对于一个用来保存int的堆栈，一个用户会错误地将一个指向Cat对象的指针压入到这个堆栈中，但编译却会通过，因为对void*参数来说，指针就是指针。

class IntStack { // int接口类
public:void push(int *intPtr) { s.push(intPtr); }int * pop() { return static_cast<int*>(s.pop()); }bool empty() const { return s.empty(); }private:GenericStack s; // 实现
};class CatStack { // cat接口类
public:void push(Cat *catPtr) { s.push(catPtr); }Cat * pop() { return static_cast<Cat*>(s.pop()); }bool empty() const { return s.empty(); }private:GenericStack s; // 实现
};

class GenericStack 
{
protected:GenericStack();~GenericStack();void push(void *object);void * pop();bool empty() const;private://... // 同上
};GenericStack s; // 错误! 构造函数被保护class IntStack: private GenericStack 
{
public:void push(int *intPtr) { GenericStack::push(intPtr); }int * pop() { return static_cast<int*>(GenericStack::pop()); }bool empty() const { return GenericStack::empty(); }
};class CatStack: private GenericStack 
{
public:void push(Cat *catPtr) { GenericStack::push(catPtr); }Cat * pop() { return static_cast<Cat*>(GenericStack::pop()); }bool empty() const { return GenericStack::empty(); }
};IntStack is; // 正确
CatStack cs; // 也正确

template<class T>
class Stack: private GenericStack 
{
public:void push(T *objectPtr) { GenericStack::push(objectPtr); }T * pop() { return static_cast<T*>(GenericStack::pop()); }bool empty() const { return GenericStack::empty(); }
};

条款40: 明智而审慎地使用多继承

首先我们来了解一下多重继承的内存布局。

//包含A对象
class A{ };
//包含A,B对象
class B:public A{ };
//包含A,C对象
class C:public A{ };
//包含A,A,B,C,D对象
class D:public B, public C{ }

由于菱形继承，基类被构造了两次。其实，C++也提供了针对菱形继承的解决方案的

//包含A对象
class A{ };
//包含A,B对象
class B:virtual public A{ };
//包含A,C对象
class C:virtual public A{ };
//包含A,B,C,D对象
class D:public B, public C{ }

使用虚继承，B,C对象里面会产生一个指针指向唯一一份A对象。这样付出的代价是必须再运行期根据这个指针的偏移量寻找A对象。

多重继承唯一的那么一点点用就是一个Base class提供public继承，另一个Base class提供private继承。(还是没什么用啊，干嘛不适用复合)

要看是谁来说，多继承（MI）要么被认为是神来之笔，要么被当成是魔鬼的造物。支持者宣扬说，它是对真实世界问题进行自然模型化所必需的；而批评者争论说，它太慢，难以实现，功能却不比单继承强大。更让人为难的是，面向对象编程语言领域在这个问题上至今仍存在分歧：C++，Eiffel 和 the Common LISP Object System (CLOS)提供了MI；Smalltalk，Objective C和Object Pascal没有提供；而Java只是提供有限的支持。可怜的程序员该相信谁呢？

在相信任何事情之前，首先得弄清事实。C++中，关于MI一条不容争辩的事实是，MI的出现就象打开了潘朵拉的盒子，带来了单继承中绝对不会存在的复杂性。其中，最基本的一条是二义性（参见条款26）。如果一个派生类从多个基类继承了一个成员名，所有对这个名字的访问都是二义的；你必须明确地说出你所指的是哪个成员。下面的例子取自ARM（参见条款50）中的一个专题讨论：

class Lottery 
{
public:virtual int draw();    //...    
};class GraphicalObject 
{
public:virtual int draw();    //...    
};class LotterySimulation: public Lottery, public GraphicalObject 
{    //...   // 没有声明draw   
};LotterySimulation *pls = new LotterySimulation;pls->draw();                   // 错误! ---- 二义
pls->Lottery::draw();          // 正确
pls->GraphicalObject::draw();  // 正确

这段代码看起来很笨拙，但起码可以工作。遗憾的是，想避免这种笨拙很难。即使其中一个被继承的draw函数是私有成员从而不能被访问，二义还是存在。（对此有一个很好的理由来解释，但完整的说明在条款26中提供，所以此处不再重复。）

显式地限制修饰成员不仅很笨拙，而且还带来限制。当显式地用一个类名来限制修饰一个虚函数时，函数的行为将不再具有虚拟的特征。相反，被调用的函数只能是你所指定的那个，即使调用是作用在派生类的对象上：

class SpecialLotterySimulation: public LotterySimulation 
{
public:virtual int draw();   //...    
};pls = new SpecialLotterySimulation;pls->draw();                        // 错误! ---- 还是有二义
pls->Lottery::draw();               // 调用Lottery::draw
pls->GraphicalObject::draw();       // 调用GraphicalObject::draw

注意，在这种情况下，即使pls指向的是SpecialLotterySimulation对象，也无法（没有 "向下转换" ---- 参见条款39）调用这个类中定义的draw函数。

没完，还有呢。Lottery和GraphicalObject中的draw函数都被声明为虚函数，所以子类可以重新定义它们（见条款36），但如果LotterySimulation想对二者都重新定义那该怎么办？令人沮丧的是，这不可能，因为一个类只允许有唯一一个没有参数、名称为draw的函数。（这个规则有个例外，即一个函数为const而另一个不是的时候 ---- 见条款21）

从某一方面来说，这个问题很严重，严重到足以成为修改C++语言的理由。ARM中就讨论了一种可能，即，允许被继承的虚函数可以 "改名" ；但后来又发现，可以通过增加一对新类来巧妙地避开这个问题：

class AuxLottery: public Lottery 
{
public:virtual int lotteryDraw() = 0;    virtual int draw() { return lotteryDraw(); }
};class AuxGraphicalObject: public GraphicalObject 
{
public:virtual int graphicalObjectDraw() = 0;   virtual int draw() { return graphicalObjectDraw(); }
};class LotterySimulation: public AuxLottery,public AuxGraphicalObject {
public:virtual int lotteryDraw();virtual int graphicalObjectDraw();    //...    
};

这两个新类， AuxLottery和AuxGraphicalObject，本质上为各自继承的draw函数声明了新的名字。新名字以纯虚函数的形式提供，本例中即lotteryDraw和graphicalObjectDraw；函数是纯虚拟的，所以具体的子类必须重新定义它们。另外，每个类都重新定义了继承而来的draw函数，让它们调用新的纯虚函数。最终效果是，在这个类体系结构中，有二义的单个名字draw被有效地分成了无二义但功能等价的两个名字：lotteryDraw和graphicalObjectDraw：

LotterySimulation *pls = new LotterySimulation;Lottery *pl = pls;
GraphicalObject *pgo = pls;// 调用LotterySimulation::lotteryDraw
pl->draw();// 调用LotterySimulation::graphicalObjectDraw
pgo->draw();

class B { ... };
class C { ... };
class D: public B, public C { ... };

class A { ... };
class B : virtual public A { ... };   // B 虚继承 A
class C : virtual public A { ... };   // C 虚继承 B
class D: public B, public C { ... };  // D 继承 A 和 B

钻石可能是女孩最好的朋友，也许不是；但肯定的是，象这样一种钻石形状的继承结构绝对不可能成为我们的朋友。如果创建了象这样的层次结构，就会立即面临这样一个问题：是不是该让A成为虚基类呢？即，从A的继承是否应该是虚拟的呢？现实中，答案几乎总是 ---- 应该；只有极少数情况下会想让类型D的对象包含A的数据成员的多个拷贝。正是认识到这一事实，上面的B和C将A声明为虚基类。

遗憾的是，在定义B和C的时候，你可能不知道将来是否会有类去同时继承它们，而且知不知道这一点实际上对正确地定义这两个类没有必要。对类的设计者来说，这实在是进退两难。如果不将A声明为B和C的虚基类，今后D的设计者就有可能需要修改B和C的定义，以便更有效地使用它们。通常，这很难做到，因为A，B和C的定义往往是只读的。例如这样的情况：A，B和C在一个库中，而D由库的用户来写。

另一方面，如果真的将A声明为B和C的虚基类，往往会在空间和时间上强加给用户额外的开销。因为虚基类常常是通过对象指针来实现的，并非对象本身。自不必说，内存中对象的分布是和编译器相关的，但一条不变的事实是：如果A作为 "非虚" 基类，类型D的对象在内存中的分布通常占用连续的内存单元；如果A作为 "虚" 基类，有时，类型D的对象在内存中的分布占用连续的内存单元，但其中两个单元包含的是指针，指向包含虚基类数据成员的内存单元：

A是非虚基类时D对象通常的内存分布：

           A部分+ B部分+ A部分 + C部分 + D部分

A是虚基类时D对象在某些编译器下的内存分布：

                           ------------------------------------------------
                           |                                                   |
                           |                                                  +
          B部分 + 指针 + C部分 + 指针 + D部分 + A部分
                                                      |                       +
                                                      |                        |
                                                      ------------------------

即使编译器不采用这种特殊的实现策略，使用虚继承通常也会带来某种空间上的惩罚。

考虑到这些因素，看来，在进行高效的类设计时如果涉及到MI，作为库的设计者就要具有超凡的远见。然而现在的年代，常识都日益成为了稀有品，因而你会不明智地过多依赖于语言特性，这就不仅要求设计者能够预计得到未来的需要，而且简直就是要你做到彻底的先知先觉（参见条款M32）。

当然，这也可以说成是在虚函数和非虚函数间选择，但还是有重大的不同。条款36说明，虚函数具有定义明确的高级含义，非虚函数也同样具有定义明确的高级含义，而且它们的含义有显著的不同，所以在清楚自己想对子类的设计者传达什么含义的基础上，在二者之间作出选择是可能的。但是，决定基类是否应该是虚拟的，则缺乏定义明确的高级含义；相反，决定通常取决于整个继承的层次结构，所以除非知道了整个层次结构，否则无法做出决定。如果正确地定义出个类之前需要清楚地知道将来怎么使用它，这种情况下将很难设计出高效的类。

就算避开了二义性问题，并且解决了是否应该从基类虚拟继承的疑问，还是会有许多复杂性问题等着你。为了长话短说，在此我仅提出应该记住的其它两点：

• 向虚基类传递构造函数参数。非虚继承时，基类构造函数的参数是由紧临的派生类的成员初始化列表指定的。因为单继承的层次结构只需要非虚基类，继承层次结构中参数的向上传递采用的是一种很自然的方式：第n层的类将参数传给第n-1层的类。但是，虚基类的构造函数则不同，它的参数是由继承结构中最底层派生类的成员初始化列表指定的。这就造成，负责初始化虚基类的那个类可能在继承图中和它相距很远；如果有新类增加到继承结构中，执行初始化的类还可能改变。（避免这个问题的一个好办法是：消除对虚基类传递构造函数参数的需要。最简单的做法是避免在这样的类中放入数据成员。这本质上是Java的解决之道：Java中的虚基类（即，"接口"）禁止包含数据）
• 虚函数的优先度。就在你自认为弄清了所有的二义之时，它们却又在你面前摇身一变。再次看看关于类A，B，C和D的钻石形状的继承图。假设A定义了一个虚成员函数mf，C重定义了它；B和D则没有重定义mf：

根据以前的讨论，你会认为下面有二义：

D *pd = new D;
pd->mf();   // A::mf或者C::mf?

class Person 
{
public:virtual ~Person();virtual string name() const = 0;virtual string birthDate() const = 0;virtual string address() const = 0;virtual string nationality() const = 0;
};

这个类的用户在编程时必须使用Person的指针或引用，因为抽象类不能被实例化。

为了创建 "可以作为Person对象而使用" 的对象，Person的用户使用工厂函数（factory function，参见条款34）来实例化具体的子类：

// 工厂函数，从一个唯一的数据库ID
// 创建一个Person对象
Person * makePerson(DatabaseID personIdentifier);
DatabaseID askUserForDatabaseID();
DatabaseID pid = askUserForDatabaseID();
Person *pp = makePerson(pid);    // 创建支持Person接口的对象
...                              // 通过Person的成员函数// 操作*pp
delete pp;                       // 删除不再需要的对象

这就带来一个问题：makePerson返回的指针所指向的对象如何创建呢？显然，必须从Person派生出某种具体类，使得makePerson可以对其进行实例化。

假设这个类被称为MyPerson。作为一个具体类，MyPerson必须实现从Person继承而来的纯虚函数。这可以从零做起，但如果已经存在一些组件可以完成大多数或全部所需的工作，那么从软件工程的角度来说，能利用这些组件将再好不过。例如，假设已经有一个和数据库有关的旧类PersonInfo，它提供的功能正是MyPerson所需要的：

class PersonInfo 
{
public:PersonInfo(DatabaseID pid);virtual ~PersonInfo();virtual const char * theName() const;virtual const char * theBirthDate() const;virtual const char * theAddress() const;virtual const char * theNationality() const;virtual const char * valueDelimOpen() const;       // 看下文virtual const char * valueDelimClose() const;    //...};

可以断定这是一个很旧的类，因为它的成员函数返回的是const char*而不是string对象。但是，如果鞋合脚，为什么不穿呢？这个类的成员函数名暗示，这双鞋穿上去会很舒服。

随之你会发现，当初设计PersonInfo是用来方便地以各种不同格式打印数据库字段，每个字段值的开头和结尾用特殊字符串分开。默认情况下，字段值的起始分隔符和结束分隔符为括号，所以字段值 "Ring-tailed Lemur" 将会这样被格式化：

[Ring-tailed Lemur]

因为括号不是所有PersonInfo的用户都想要的，虚函数valueDelimOpen和valueDelimClose允许派生类指定它们自己的起始分隔符和结束分隔符。PersonInfo类的theName，theBirthDate，theAddress以及theNationality的实现将调用这两个虚函数，在它们的返回值中添加适当的分隔符。拿PersonInfo::name作为例子，代码看起来象这样：

const char * PersonInfo::valueDelimOpen() const
{return "[";                   // 默认起始分隔符
}const char * PersonInfo::valueDelimClose() const
{return "]";                   // 默认结束分隔符
}const char * PersonInfo::theName() const
{// 为返回值保留缓冲区。因为是静态// 类型，它被自动初始化为全零。static char value[MAX_FORMATTED_FIELD_VALUE_LENGTH];// 写起始分隔符strcpy(value, valueDelimOpen());//将对象的名字字段值添加到字符串中// 写结束分隔符strcat(value, valueDelimClose());return value;
}

有些人会挑剔PersonInfo::theName的设计（特别是使用了固定大小的静态缓冲区 ---- 参见条款23），但请将你的挑剔放在一边，关注这一点：首先，theName调用valueDelimOpen，生成它将要返回的字符串的起始分隔符；然后，生成名字值本身；最后，调用valueDelimClose。因为valueDelimOpen和valueDelimClose是虚函数，theName返回的结果既依赖于PersonInfo，也依赖于从PersonInfo派生的类。

作为MyPerson的实现者，这是条好消息，因为在研读Person文档的细则时你发现，name及其相关函数需要返回的是不带修饰的值，即，不允许带分隔符。也就是说，如果一个人来自Madagascar，调用这个人的nationality函数将返回"Madagascar"，而不是 "[Madagascar]"。

MyPerson和PersonInfo之间的关系是，PersonInfo刚好有些函数使得MyPerson易于实现。仅次而已。没看到有 "是一个" 或 "有一个" 的关系。它们的关系是 "用...来实现"，而且我们知道，这可以用两种方式来表示：通过分层（见条款40）和通过私有继承（见条款42）。条款42指出，分层一般来说是更好的方法，但在有虚函数要被重新定义的情况下，需要使用私有继承。现在的情况是，MyPerson需要重新定义valueDelimOpen和valueDelimClose，所以不能用分层，而必须用私有继承：MyPerson必须从PersonInfo私有继承。

但MyPerson还必须实现Person接口，因而需要公有继承。这导致了多继承一个很合理的应用：将接口的公有继承和实现的私有继承结合起来：

class Person {     // 这个类指定了需要被实现的接口
public:virtual ~Person();virtual string name() const = 0;virtual string birthDate() const = 0;virtual string address() const = 0;virtual string nationality() const = 0;
};class DatabaseID { /* ...  */ };  // 被后面的代码使用；
// 细节不重要class PersonInfo {   // 这个类有些有用的函数，可以用来实现Person接口
public:PersonInfo(DatabaseID pid);virtual ~PersonInfo();virtual const char * theName() const;virtual const char * theBirthDate() const;virtual const char * theAddress() const;virtual const char * theNationality() const;virtual const char * valueDelimOpen() const;virtual const char * valueDelimClose() const;//...    
};class MyPerson: public Person,  // 注意，使用了多继承private PersonInfo {
public:MyPerson(DatabaseID pid): PersonInfo(pid) {}// 继承来的虚分隔符函数的重新定义const char * valueDelimOpen() const { return ""; }const char * valueDelimClose() const { return ""; }// 所需的Person成员函数的实现string name() const{ return PersonInfo::theName(); }string birthDate() const{ return PersonInfo::theBirthDate(); }string address() const{ return PersonInfo::theAddress(); }string nationality() const{ return PersonInfo::theNationality(); }
};

用图形表示，看起来象下面这样：

这种例子证明，MI会既有用又易于理解，尽管可怕的钻石形状继承图不会明显消失。

然而，必须当心诱惑。有时你会掉进这样的陷阱中：对某个需要改动的继承层次结构来说，本来用一个更基本的重新设计可以更好，但你却为了追求速度而去使用MI。例如，假设为可以活动的卡通角色设计一个类层次结构。至少从概念上来说，让各种角色能跳舞唱歌将很有意义，但每一种角色执行这些动作时方式都不一样。另外，跳舞唱歌的缺省行为是什么也不做。

所有这些用C++来表示就象这样：

class CartoonCharacter 
{
public:virtual void dance() {}virtual void sing() {}
};

虚函数自然地体现了这样的约束：唱歌跳舞对所有CartoonCharacter对象都有意义。什么也不做的缺省行为通过类中那些函数的空定义来表示（参见条款36）。假设有一个特殊类型的卡通角色是蚱蜢，它以自己特殊的方式跳舞唱歌：

class Grasshopper: public CartoonCharacter 
{
public:virtual void dance();    // 定义在别的什么地方virtual void sing();     // 定义在别的什么地方
};

现在假设，在实现了Grasshopper类后，你又想为蟋蟀增加一个类：

class Cricket: public CartoonCharacter 
{
public:virtual void dance();virtual void sing();
};

class Cricket: public CartoonCharacter,private Grasshopper 
{
public:virtual void dance();virtual void sing();
};

然后准备对Grasshopper类做必要的修改。特别是，需要声明一些新的虚函数让Cricket重新定义：

class Grasshopper: public CartoonCharacter 
{
public:virtual void dance();virtual void sing();protected:virtual void danceCustomization1();virtual void danceCustomization2();virtual void singCustomization();
};

蚱蜢跳舞现在被定义成象这样：

void Grasshopper::dance()
{执行共同的跳舞动作;danceCustomization1();执行更多共同的跳舞动作;danceCustomization2();执行最后共同的跳舞动作;
}

蚱蜢唱歌的设计与此类似。很明显，Cricket类必须修改一下，因为它必须重新定义新的虚函数：

class Cricket:public CartoonCharacter,private Grasshopper {
public:virtual void dance() { Grasshopper::dance(); }virtual void sing() { Grasshopper::sing(); }protected:virtual void danceCustomization1();virtual void danceCustomization2();virtual void singCustomization();
};

这看来很不错。当需要Cricket对象去跳舞时，它执行Grasshopper类中共同的dance代码，然后执行Cricket类中定制的dance代码，接着继续执行Grasshopper::dance中的代码，等等。

然而，这个设计中有个严重的缺陷，这就是，你不小心撞上了 "奥卡姆剃刀" ---- 任何一种奥卡姆剃刀都是有害的思想，William of Occam的尤其如此。奥卡姆者鼓吹：如果没有必要，就不要增加实体。现在的情况下，实体就是指的继承关系。如果你相信多继承比单继承更复杂的话（我希望你相信），Cricket类的设计就没必要复杂。（译注：1) William of Occam(1285-1349)，英国神学家，哲学家。2) 奥卡姆剃刀(Occam's razor)是一种思想，主要由William of Occam提出。之所以将它称为 "奥卡姆剃刀"，是因为William of Occam经常性地、很锐利地运用这一思想。）

问题的根本之处在于，Cricket类和Grasshopper类之间并非 "用...来实现" 的关系。而是，Cricket类和Grasshopper类之间享有共同的代码。特别是，它们享有决定唱歌跳舞行为的代码 ---- 蚱蜢和蟋蟀都有这种共同的行为。

说两个类具有共同点的方式不是让一个类从另一个类继承，而是让它们都从一个共同的基类继承，蚱蜢和蟋蟀之间的公共代码不属于Grasshopper类，也不属于Cricket，而是属于它们共同的新的基类，如，Insect:

class CartoonCharacter { /* ... */ };class Insect: public CartoonCharacter 
{
public:virtual void dance();    // 蚱蜢和蟋蟀virtual void sing();     // 的公共代码protected:virtual void danceCustomization1() = 0;virtual void danceCustomization2() = 0;virtual void singCustomization() = 0;
};class Grasshopper: public Insect 
{
protected:virtual void danceCustomization1();virtual void danceCustomization2();virtual void singCustomization();
};class Cricket: public Insect 
{
protected:virtual void danceCustomization1();virtual void danceCustomization2();virtual void singCustomization();
};

可以看到，这个设计更清晰。只是涉及到单继承，此外，只是用到了公有继承。Grasshopper和Cricket定义的只是定制功能；它们从Insect一点没变地继承了dance和sing函数。William of Occam一定会很骄傲。

尽管这个设计比采用了MI的那个方案更清晰，但初看可能会觉得比使用MI的还要逊色。毕竟，和MI的方案相比，这个单继承结构中引入了一个全新的类，而使用MI就不需要。如果没必要，为什么要引入一个额外的类呢？

这就将你带到了多继承诱人的本性面前。表面看来，MI好象使用起来更容易。它不需要增加新的类，虽然它要求在Grasshopper类中增加一些新的虚函数，但这些函数在任何情况下都是要增加的。

设想有个程序员正在维护一个大型C++类库，现在需要在库中增加一个新的类，就象Cricket类要被增加到现有的的CartoonCharacter/Grasshopper层次结构中一样。程序员知道，有大量的用户使用现有的层次结构，所以，库的变化越大，对用户的影响越大。程序员决心将这种影响降低到最小。对各种选择再三考虑之后，程序员认识到，如果增加一个从Grasshopper到Cricket的私有继承连接，层次结构中将不需要任何其它变化。程序员不禁因为这个想法露出了微笑，暗自庆幸今后可以大量地增加功能，而代价仅仅只是增加很小一点复杂性。

现在设想这个负责维护的程序员是你。那么，请抵御这一诱惑！

避免 "向下转换" 继承层次

在当今喧嚣的经济时代，关注一下我们的金融机构是个不错的主意。所以，看看下面这个有关银行帐户的协议类(Protocol class )（参见条款31）：

class Person { ... };class BankAccount 
{
public:BankAccount(const Person *primaryOwner,const Person *jointOwner);virtual ~BankAccount();virtual void makeDeposit(double amount) = 0;virtual void makeWithdrawal(double amount) = 0;virtual double balance() const = 0;//...
};

class SavingsAccount: public BankAccount 
{
public:SavingsAccount(const Person *primaryOwner,const Person *jointOwner);~SavingsAccount();void creditInterest();                // 给帐户增加利息//...
};

// 不能通过编译的循环（如果你以前从没见过使用 "迭代子" 的代码，参见下文）
for (list<BankAccount*>::iterator p = allAccounts.begin(); p != allAccounts.end(); ++p) 
{(*p)->creditInterest();      // 错误!
}

// 可以通过编译的循环，但很糟糕
for (list<BankAccount*>::iterator p = allAccounts.begin(); p != allAccounts.end(); ++p) 
{static_cast<SavingsAccount*>(*p)->creditInterest();
}

class CheckingAccount: public BankAccount 
{
public:void creditInterest();    // 给帐户增加利息...
};

for (list<BankAccount*>::iterator p = allAccounts.begin(); p != allAccounts.end(); ++p) 
{if (*p 指向一个 SavingsAccount)static_cast<SavingsAccount*>(*p)->creditInterest();elsestatic_cast<CheckingAccount*>(*p)->creditInterest();  
}

class BankAccount { ... };      // 同上// 一个新类，表示要支付利息的帐户
class InterestBearingAccount: public BankAccount 
{
public:virtual void creditInterest() = 0;//...
};class SavingsAccount: public InterestBearingAccount 
{//...                           // 同上
};class CheckingAccount: public InterestBearingAccount 
{//...                           // as above
};

因为存款和支票账户都要支付利息，所以很自然地想到把这一共同行为转移到一个公共的基类中。但是，如果假设不是所有的银行帐户都需要支付利息（以我的经验，这当然是个合理的假设），就不能把它转移到BankAccount类中。所以，要为BankAccount引入一个新的子类InterestBearingAccount，并使SavingsAccoun和CheckingAccount从它继承。

存款和支票账户都要支付利息的事实是通过InterestBearingAccount的纯虚函数creditInterest来体现的，它要在子类SavingsAccount和CheckingAccount中重新定义。

有了新的类层次结构，就可以这样来重写循环代码：

// 好一些，但还不完美
for (list<BankAccount*>::iterator p = allAccounts.begin(); p != allAccounts.end(); ++p) 
{static_cast<InterestBearingAccount*>(*p)->creditInterest();
}

// 银行中所有要支付利息的帐户
list<InterestBearingAccount*> allIBAccounts;// 可以通过编译且现在将来都可以工作的循环
for (list<InterestBearingAccount*>::iterator p = allIBAccounts.begin(); p != allIBAccounts.end(); ++p) 
{(*p)->creditInterest();
}

class BankAccount {
public:virtual void creditInterest() {}//...
};class SavingsAccount: public BankAccount { ... };
class CheckingAccount: public BankAccount { ... };
list<BankAccount*> allAccounts;
// 看啊，没有转换!
for (list<BankAccount*>::iterator p = allAccounts.begin(); p != allAccounts.end(); ++p) 
{(*p)->creditInterest();
}

class BankAccount { ... };          // 和本条款开始时一样class SavingsAccount:               // 同上public BankAccount { ... };class CheckingAccount:              // 同上public BankAccount { ... };list<BankAccount*> allAccounts;     // 看起来应该熟悉些了吧...void error(const string& msg);      // 出错处理函数; // 见下文// 嗯，至少转换很安全
for (list<BankAccount*>::iterator p = allAccounts.begin(); p != allAccounts.end(); ++p) 
{// 尝试将*p安全转换为SavingsAccount*；// psa的定义信息见下文if (SavingsAccount *psa = dynamic_cast<SavingsAccount*>(*p)) {psa->creditInterest();}// 尝试将它安全转换为CheckingAccountelse if (CheckingAccount *pca = dynamic_cast<CheckingAccount*>(*p)) {pca->creditInterest();}// 未知的帐户类型else {error("Unknown account type!");}
}

for (list<BankAccount*>::iterator p = allAccounts.begin(); p != allAccounts.end(); ++p) 
{SavingsAccount *psa;        // 传统定义CheckingAccount *pca;       // 传统定义if (psa = dynamic_cast<SavingsAccount*>(*p)) {psa->creditInterest();}else if (pca = dynamic_cast<CheckingAccount*>(*p)) {pca->creditInterest();}else {error("Unknown account type!");}
}

区分继承和模板

考虑下面两个设计问题：

• 作为一位立志献身计算机科学的学生，你想设计一个类来表示对象的堆栈。这将需要多个不同的类，因为每个堆栈中的元素必须是同类的，即，它里面包含的必须只是同种类型的对象。例如，会有一个类来表示int的堆栈，第二个类来表示string的堆栈，第三个类来表示string的堆栈的堆栈，等等。你也许对设计一个最小的类接口（参见条款18）很感兴趣，所以会将对堆栈的操作限制在：创建堆栈，销毁堆栈，将对象压入堆栈，将对象弹出堆栈，以及检查堆栈是否为空。设计中，你不会借助标准库中的类（包括stack ---- 参见条款49），因为你渴望亲手写这些代码。重用（Reuse）是一件美事，但当你的目标是探究事情的工作原理时，那就只有挖地三尺了。
• 作为一位爱猫的宠物迷，你想设计一个类来表示猫。这也将需要多个不同的类，因为每个品种的猫都会有点不同。和所有对象一样，猫可以被创建和销毁，但，正如所有猫迷所知道的，猫所做的其它事不外乎吃和睡。然而，每一种猫吃和睡都有各自惹人喜爱的方式。

答案涉及到"类的行为" 和 "类所操作的对象的类型"之间的关系。对于堆栈和猫来说，要处理的都是各种不同的类型（堆栈包含类型为T的对象，猫则为品种T），但你必须问自己这样一个问题：类型T影响类的行为吗？如果T不影响行为，你可以使用模板。如果T影响行为，你就需要虚函数，从而要使用继承。

下面的代码通过定义一个链表来实现Stack类，假设堆栈的对象类型为T：

class Stack {
public:Stack();~Stack();void push(const T& object);T pop();bool empty() const;             // 堆栈为空?private:struct StackNode {              // 链表节点T data;                       // 此节点数据StackNode *next;              // 链表中下一节点// StackNode构造函数，初始化两个域StackNode(const T& newData, StackNode *nextNode): data(newData), next(nextNode) {}};StackNode *top;                 // 堆栈顶部Stack(const Stack& rhs);               // 防止拷贝和Stack& operator=(const Stack& rhs);    // 赋值(见条款27)
};

于是，Stack对象将构造如下所示的数据结构：

Stack对象 top--> data+next--> data+next--> data+next--> data+next
------------------------------------------------------------------------------------
StackNode对象

链表本身是由StackNode对象构成的，但那只是Stack类的一个实现细节，所以StackNode被声明为Stack的私有类型。注意StackNode有一个构造函数，用来确保它所有的域都被正确初始化。即使你闭着眼睛都可以写出一个链表，但也不要忽视了C++的一些新特性，如struct中的构造函数。

下面看看你对Stack成员函数的实现。和许多原型（prototype）的实现（离制作成软件产品相差太远）一样，这里没有错误检查，因为在原型世界里，没有东西会出错。

Stack::Stack(): top(0) {}      // 顶部初始化为nullvoid Stack::push(const T& object)
{top = new StackNode(object, top);    // 新节点放在
}                                      // 链表头部T Stack::pop()
{StackNode *topOfStack = top;    // 记住头节点top = top->next;T data = topOfStack->data;      // 记住节点数据delete topOfStack;return data;
}Stack::~Stack()                   // 删除堆栈中所有对象
{while (top) {StackNode *toDie = top;       // 得到头节点指针top = top->next;              // 移向下一节点delete toDie;                 // 删除前面的头节点}
}bool Stack::empty() const
{ return top == 0; }

这些代码毫无吸引人之处。实际上，唯一有趣的一点在于：即使对T一无所知，你还是能够写出每个成员函数。（上面的代码中实际上有个假设，即，假设可以调用T的拷贝构造函数；但正如条款45所说明的，这是一个绝对合理的假设）不管T是什么，对构造，销毁，压栈，出栈，确定栈是否为空等操作所写的代码不会变。除了 "可以调用T的拷贝构造函数" 这一假设外，stack的行为在任何地方都不依赖于T。这就是模板类的特点：行为不依赖于类型。

将stack类转化成一个模板就很简单了，即使是Dilbert的老板都会写：

template<class T> 
class Stack 
{//...        // 完全和上面相同
};

class Cat 
{
public:virtual ~Cat();                     // 参见条款14virtual void eat() = 0;             // 所有的猫吃食virtual void sleep() = 0;           // 所有的猫睡觉
};

class Siamese: public Cat 
{
public:void eat();void sleep();//...
};class BritishShortHairedTabby: public Cat 
{
public:void eat();void sleep();//...
};

class Stack {      // a stack of anything
public:virtual void push(const ??? object) = 0;virtual ??? pop() = 0;//...
};

但也许你做事喜欢偷偷摸摸。或许你认为自己可以通过使用通用(void*)指针来骗过编译器。但事实证明，现在这种情况下，通用指针也帮不上忙。因为你无法避开这一条件：派生类虚函数的声明永远不能和它在基类中的声明相抵触。但是，通用指针可以帮助解决另外一个不同的问题，它和模板所生成的类的效率有关。详细介绍参见条款42。

讲完了堆栈和猫，下面将本条款得到的结论总结如下：

• 当对象的类型不影响类中函数的行为时，就要使用模板来生成这样一组类。
• 当对象的类型影响类中函数的行为时，就要使用继承来得到这样一组类。

说你想说的；理解你所说的

在本章关于 "继承和面向对象设计" 的简介中，我曾强调，理解不同的面向对象构件在C++中的含义十分重要。这和仅仅知道C++语言的规则有很大的不同。例如，C++规则说，如果类D从类B公有继承，从D的指针到B的指针就有一个标准转换；B的公有成员函数将被继承为D的公有成员函数，等等。这些规则都是正确的，但在将设计思想转化为C++的过程中，它们起不到任何作用。相反，你需要知道，公有继承意味着 "是一个"，如果D从B公有继承，类型D的每一个对象也 "是一个" 类型B的对象。因而，如果想在设计中表示 "是一个"，就自然会想到使用公有继承。

"说出你想说的" 只是成功的一半。事情的另一面是 "理解你所说的"，这一点同样重要。例如，将成员函数声明为非虚函数会给子类带来限制，如果没有认识到这一点就随便这样做将是不负责任的行为 ---- 除非你完全是有意这么做。声明一个非虚成员函数，你实际上是在说这个函数表示了一种特殊性上的不变性；如果不明白这一点，将会给程序带来灾难。

公有继承和 "是一个" 的等价性，以及非虚成员函数和 "特殊性上的不变性" 的等价性，是C++构件如何和设计思想相对应的例子。下面的列表总结了这些对应关系中最重要的几个。

• 共同的基类意味着共同的特性。如果类D1和类D2都把类B声明为基类，D1和D2将从B继承共同的数据成员和/或共同的成员函数。见条款40。
• 公有继承意味着 "是一个"。如果类D公有继承于类B，类型D的每一个对象也是一个类型B的对象，但反过来不成立。见条款32。
• 私有继承意味着 "用...来实现"。如果类D私有继承于类B，类型D的对象只不过是用类型B的对象来实现而已；类型B和类型D的对象之间不存在概念上的关系。见条款39。
• 分层意味着 "有一个" 或 "用...来实现"。如果类A包含一个类型B的数据成员，类型A的对象要么具有一个类型为B的部件，要么在实现中使用了类型B的对象。见条款38。

• 纯虚函数意味着仅仅继承函数的接口。如果类C声明了一个纯虚函数mf，C的子类必须继承mf的接口，C的具体子类必须为之提供它们自己的实现。见条款34。
• 简单虚函数意味着继承函数的接口加上一个缺省实现。如果类C声明了一个简单（非纯）虚函数mf，C的子类必须继承mf的接口；如果需要的话，还可以继承一个缺省实现。见条款33。
• 非虚函数意味着继承函数的接口加上一个强制实现。如果类C声明了一个非虚函数mf，C的子类必须同时继承mf的接口和实现。实际上，mf定义了C的 "特殊性上的不变性"。见条款35。

7. 模版与泛型编程

C++模板：http://blog.csdn.net/freeking101/article/details/61200317

条款41：了解隐式接口和编译期多态

• 接口：强制用户实现某些函数
• 多态：相同的函数名，却有不同的实现

1. 继承和模板都支持接口和多态
2. 对继承而言，接口是显式的，以函数为中心，多态发生在运行期；
3. 对模板而言，接口是隐式的，多态表现在template具象化和函数重载

条款42：了解typename的双重意义

1. 声明template参数时，前缀关键字class和typename可以互换
2. 使用typename表明嵌套类型(防止产生歧义)

条款43：学习处理模板化基类内的名称

Know how to access names in templatized base classes

template <typename T>
class Base{                                                                      public:                                                                          void print(T a) {cout <<"Base "<< a <<endl;};                                  };template<typename T>                                                             
class Drive : public Base<T>{                                                    
public:                                                                          void printf(T a){                                                          //error 编译器不知道基类有print函数print(a);  } 
};//解决方案
//this->print();
//using Base<T>::print
//base<T>::print直接调用

条款44：将参数无关代码抽离template

1. 非类型模板参数造成的代码膨胀：以函数参数或者成员变量替换
2. 类型模板参数造成的代码膨胀：特化它们，让含义相近的类型模板参数使用同一份底层代码。例如int，long, const int

条款45：运用成员函数模版接收所有兼容类型

我们来考虑一下智能指针的拷贝构造函数和赋值操作符怎么实现。它需要子类的智能指针能够隐式转型为父类智能指针

template<typename T>
class shared_ptr{
public://拷贝构造函数，接受所有能够从U*隐式转换到T*的参数template<typename U>shared_ptr(shared_ptr<U> const &rh):p(rh.get()){...}//赋值操作符，接受所有能够从U*隐式转换到T*的参数template<typename U>shared_ptr& operator= (shared_ptr<U> const &rh):p(rh.get()){...}//声明正常的拷贝构造函数shared_ptr(shared_ptr const &rh)；shared_ptr& operator= (shared_ptr const &rh);
private:T *p;
}

1. 使用成员函数模版生成“可接受所有兼容类型”的函数
2. 即使有了“泛化拷贝构造函数”和“泛化的赋值操作符”，仍然需要声明正常的拷贝构造函数和赋值操作符
3. 在一个类模版内，template名称可被用来作为作为“template和其参数”的简略表达式

条款46：所有参数需要类型转换的时候请为模版定义非成员函数

1. 当我们编写一个模版类，某个相关函数都需要类型转换，需要把这个函数定义为非成员函数
2. 但是模版的类型推导遇见了问题，需要把这个函数声明为友元函数帮助推导
3. 模版函数只有声明编译器不会帮忙具现化，所以我们需要实现的是友元模版函数

template <class T>
class Rational
{…friend Rational operator* (const Rational& a, const Rational& b){return Rational (a.GetNumerator() * b.GetNumerator(),a.GetDenominator() * b.GetDenominator());}…
}

条款47：请使用traits classes表现类型信息

template<typename T>
class type_traits;template<>
class type_traits<int>{
public:static int size = 4;
}template<>
class type_traits<char>{
public:static int size = 1;
}template<>
class type_traits<double>{static int size = 8;
}template<typename T>
int ccSizeof(T){return type_traits<T>::size;
}

1. traits采用类模版和特化的方式，为不同的类型提供了相同的类型抽象(都由size)
2. 为某些类型提供编译期测试，例如is_fundamental

条款48：认识模版元编程

本质上就是函数式编程

//上楼梯，每次上一步或者两步，有多少种
int climb(int n){if(n == 1)return 1;if(n == 2)return 2;return climb(n - 1) + climb(n - 2);
}//元编程，采用类模版
template<int N>
class Climb{
public:const static int n = Climb<N-1>::n + Climb<N-2>::n;
};template<>
class Climb<2>{
public:const static int n = 2;
};template<>
class Climb<1>{
public:const static int n = 1;
};

1. C++元编程可以将计算转移到编译期，执行速度迅速(缺陷？)

8. 定制 new 和 delete

尽量用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，其后果是不可预测的。大家都知道“不可预测”的意思：它可能在开发阶段工作良好，在测试阶段工作良好，但也可能会最后在你最重要的客户的脸上爆炸。

其实，在c++程序里使用malloc和free没有错，只要保证用malloc得到的指针用free，或者用new得到的指针最后用delete来操作就可以了。千万别不要把new和free或malloc和delete混起来用，那只会自找麻烦。既然malloc和free对构造函数和析构函数一无所知，把malloc/free和new/delete混起来用又象嘈杂拥挤的晚会那样难以控制，那么，你最好就什么时候都一心一意地使用new和delete吧。

条款49：了解new-handler的行为

new和malloc对比：

1. new构造对象，malloc不会
2. new分配不出内存会抛异常，malloc返回NULL
3. new分配不出内存可以调用用户设置的new-handler，malloc没有

namespace std{typedef void (*new_handler)();//返回旧的handlernew_handler set_new_handler(new_handler p) throw();
}

• 可以为每个类设置专属new handler

operator new在无法完成内存分配请求时会抛出异常(以前的做法一般是返回0，即空指针)。大家都知道，处理内存不够所产生的异常真可以算得上是个道德上的行为，但实际做起来又会象刀架在脖子上那样痛苦。所以，你有时会不去管它，也许一直没去管它。但你心里一定还是深深地隐藏着一种罪恶感：万一new真的产生了异常怎么办？

你会很自然地想到处理这种情况的一种方法，即回到以前的老路上去，使用预处理。例如，c的一种常用的做法是，定义一个类型无关的宏来分配内存并检查分配是否成功。对于c++来说，这个宏看起来可能象这样：

#define new(ptr, type)	\
try { (ptr) = new type; }	\
catch (std::bad_alloc&) { assert(0); }

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：

#include<iostream>
using namespace std;// function to call if operator new can't allocate enough memory
void nomorememory()
{cerr << "unable to satisfy request for memory\n";abort();
}int main(int argc, char *argv[])
{set_new_handler(nomorememory);int *pbigdataarray = new int[1000000000];return 0;
}

假如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)。

处理内存分配失败的情况时采取什么方法，取决于要分配的对象的类：

class x {
public:static void outofmemory();	...	
};class y {
public:static void outofmemory();	...	
};x* p1 = new x;	// 若分配成功，调用x::outofmemory
y* p2 = new y;	// 若分配不成功，调用y::outofmemory

class x {
public:static new_handler set_new_handler(new_handler p);static void * operator new(size_t size);private:static new_handler currenthandler;
};

new_handler x::set_new_handler(new_handler p) throw()
{std::new_handler oldhandler = currenthandler;currenthandler = p;return oldhandler;
}

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来恢复最初的全局出错处理函数。最后返回分配成功的内存的指针。 

void * x::operator new(size_t size)
{// 安装x的new_handler    new_handler globalhandler =	std::set_new_handler(currenthandler);void *memory;try { 	// 尝试分配内存memory = ::operator new(size);}catch (std::bad_alloc&) { 	// 恢复旧的new_handlerstd::set_new_handler(globalhandler);      throw;	// 抛出异常}std::set_new_handler(globalhandler);	// 恢复旧的new_handlerreturn 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 0template<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

条款50：了解new和delete合理的替换时机

C++中对象的构造和析构经历了都两个阶段

1. operator new, operator delete：分配和释放内存
2. 调用构造函数，调用析构函数

替换new和delete的理由，就是需要收集分配内存的资源信息

条款51：编写new和delete时需要固守的常规

1. operator new应该内含一个无穷循环尝试分配内存，如果无法满足，就调用new-handler。class版本要处理“比正确大小更大的(错误)申请”
2. operator deleter应该处理Null。classz专属版本还要处理“比正确大小更小的(错误)申请”

自己重写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();}
}

class base 
{
public:static void * operator new(size_t size);...
};class derived: public base       // derived类没有声明operator new
{ ... };                         // derived *p = new derived;        // 调用base::operator new

void * base::operator new(size_t size)
{if (size != sizeof(base))             // 如果数量“错误”，让标准operator newreturn ::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;  //如果指针为空，返回释放rawmemory指向的内存;return;
}

class base 
{      // 和前面一样，只是这里声明了
public:            // operator deletestatic 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;
}

条款52：new 与 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()处理;// 详见条款51if (size != sizeof(airplane)) return ::operator new(size);airplane *p = headoffreelist;  // p指向自由链表的表头 // 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;
}

如果你读了条款51，就会知道在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; // 见条款 8if (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。

析构函数里对指针成员调用delete

大多数情况下，执行动态内存分配的的类都在构造函数里用new分配内存，然后在析构函数里用delete释放内存。最初写这个类的时候当然不难做，你会记得最后对在所有构造函数里分配了内存的所有成员使用delete。

然而，这个类经过维护、升级后，情况就会变得困难了，因为对类的代码进行修改的程序员不一定就是最早写这个类的人。而增加一个指针成员意味着几乎都要进行下面的工作：

• 在每个构造函数里对指针进行初始化。对于一些构造函数，如果没有内存要分配给指针的话，指针要被初始化为0(即空指针)。
• 删除现有的内存，通过赋值操作符分配给指针新的内存。
• 在析构函数里删除指针。

避免隐藏标准形式的new

因为内部范围声明的名称会隐藏掉外部范围的相同的名称，所以对于分别在类的内部和全局声明的两个相同名字的函数f来说，类的成员函数会隐藏掉全局函数：

void f();   // 全局函数class T {
public:void f(); // 成员函数
};T t;f();     // 调用 f
t.f();  // 调用 t::f

class T 
{
public:void f();// operator new的参数指定一个// new-hander(new的出错处理)函数static void * operator new(size_t size, new_handler p);
};void specialerrorhandler();    // 定义在别的地方T *p1 = new (specialerrorhandler) t;     // 调用T::operator newT *p2 = new t;                      // 错误!

class T 
{
public:void f();static void * operator new(size_t size, new_handler p);static void * operator new(size_t size){ return ::operator new(size); }
};T *p1 = new (specialerrorhandler) T;      // 调用 T::operator new(size_t, new_handler)
T* p2 = new T;   // 调用 T::operator new(size_t)

另一种方法是为每一个增加到operator new的参数提供缺省值(见条款24)：

class T 
{
public:void f();static void * operator new(size_t size, new_handler p = 0);  // p缺省值为0
};T *p1 = new (specialerrorhandler) T;               // 正确
T* p2 = new T;                                     // 也正确

无论哪种方法，如果以后想对“标准”形式的new定制新的功能，只需要重写这个函数。
调用者重新编译链接后就可以使用新功能了。

9. 杂项讨论

进行高效的C++程序设计有很多准则，其中有一些很难归类。本章就是专门为这些准则而安排的。不要因此而小看了它们的重要性。要想写出高效的软件，就必须知道：编译器在背后为你（给你?）做了些什么，怎样保证非局部的静态对象在被使用前已经被初始化，能从标准库得到些什么，从何处着手深入理解语言底层的设计思想。本书最后的这个章节，我将详细说明这些问题，甚至更多其它问题。

尽量用<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试试看！

你所写的表示有理数的类的代码可能象下面这样：

#include<iostream>
using namespace std;class Rational
{
public:Rational(int n = 0, int d = 1){}private:int n, d;friend istream& operator >>(istream& in,  Rational&);friend ostream& operator <<(ostream& out, const Rational&);
};istream& operator >>(istream& in, Rational& r)
{in >> r.n >> r.d;return in;
}ostream& operator <<(ostream& out, const Rational& r)
{out << r.n << '/' << r.d;return out;
}int main(int argc, char *argv[])
{int i;Rational r; // r 是个有理数cout<<"input i(int): ";cin >> i;cout<<"input two int: ";cin >> r;cout << i << endl << r <<endl;return 0;
}

上面的代码涉及到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>少两个字，这也是很多人用它的原因。:)

条款53：不要轻视编译器的警告

很多程序员日常总是不理睬编译器警告。毕竟，如果问题很严重，就会是个错误，不是吗？这种想法在其它语言中相对来说没什么害处，但在C++中，可以肯定的一点是，编译器的设计者肯定比你更清楚到底发生了什么。例如，大家可能都犯过这个错误：

class B 
{
public:virtual void f() const;
};class D: public B 
{
public:virtual void f();
};

本来是想用D::f重新定义虚函数B::f，但有个错误：在B中，f是一个const成员函数，但在D中没有被声明为const。据我所知，有个编译器会这么说：

warning: D::f() hides virtual B::f()

对于这条警告，很多缺乏经验的程序员会这样自言自语，"D::f当然会隐藏B::f ---- 本来就应该是这样！" 错了。编译器想告诉你的是：声明在B中的f没有在D中重新声明，它被完全隐藏了（参见条款50：为什么这样）。忽视这条编译器警告几乎肯定会导致错误的程序行为。你会不停地调试去找原因，而这个错误实际上早就被编译器发现了。

当然，在对某个编译器的警告信息积累了经验之后，你会真正理解不同的信息所表示的含义（唉，往往和它们表面看上去的意思不同）。一旦有了这些经验，你会对很多警告不予理睬。这没问题，但重要的是，在忽略一个警告之前，你一定要准确理解它想告诉你的含义。

只要谈到警告，就要想到警告是和编译器紧密相关的，所以在编程时不要马马虎虎，寄希望于编译器为你找出每一条错误。例如上面隐藏了函数的那段代码，当它通过不同的（但使用很广泛的）编译器时可能不会产生警告。编译器是用来将C++转换成可执行格式的，并不是你的私人保镖。你想得到那样的安全？去用Ada吧。

条款54：熟悉 TR1 在内的标准程序库

// 当c是vector、string，删除value
c.erase(remove(c.begin(), c.end(), value), c.end());// 判断value是否满足某个条件，删除
bool assertFun(valuetype);
c.erase(remove_if(c.begin(), c.end(), assertFun), c.end());// 有时候我们不得不遍历去完成，并删除
for(auto it = c.begin(); it != c.end(); ){if(assertFun(*it)){···it = c.erase(it);}else++it;
}

c.remove(value);// 判断value是否满足某个条件，删除    
c.remove(assertFun);

c.erase(value)for(auto it = c.begin(); it != c.end(); ){if(assertFun(*it)){···c.erase(it++);}else++it;
}    

C++标准库很大。非常大。难以置信的大。怎么个大法？这么说吧：在C++标准中，关于标准库的规格说明占了密密麻麻300多页，这还不包括标准C库，后者只是 "作为参考"（老实说，原文就是用的这个词）包含在C++库中。

当然，并非总是越大越好，但在现在的情况下，确实越大越好，因为大的库会包含大量的功能。标准库中的功能越多，开发自己的应用程序时能借助的功能就越多。C++库并非提供了一切（很明显的是，没有提供并发和图形用户接口的支持），但确实提供了很多。几乎任何事你都可以求助于它。

在归纳标准库中有些什么之前，需要介绍一下它是如何组织的。因为标准库中东西如此之多，你（或象你一样的其他什么人）所选择的类名或函数名就很有可能和标准库中的某个名字相同。为了避免这种情况所造成的名字冲突，实际上标准库中的一切都被放在名字空间std中（参见条款28）。但这带来了一个新问题。无数现有的C++代码都依赖于使用了多年的伪标准库中的功能，例如，声明在<iostream.h>，<complex.h>，<limits.h>等头文件中的功能。现有软件没有针对使用名字空间而进行设计，如果用std来包装标准库导致现有代码不能用，将是一种可耻行为。（这种釜底抽薪的做法会让现有代码的程序员说出比 "可耻" 更难听的话）

慑于被激怒的程序员会产生的破坏力，标准委员会决定为包装了std的那部分标准库构件创建新的头文件名。生成新头文件的方法仅仅是将现有C++头文件名中的 .h 去掉，方法本身不重要，正如最后产生的结果不一致也并不重要一样。所以<iostream.h>变成了<iostream>，<complex.h>变成了<complex>，等等。对于C头文件，采用同样的方法，但在每个名字前还要添加一个c。所以C的<string.h>变成了<cstring>，<stdio.h>变成了<cstdio>，等等。最后一点是，旧的C++头文件是官方所反对使用的（即，明确列出不再支持），但旧的C头文件则没有（以保持对C的兼容性）。实际上，编译器制造商不会停止对客户现有软件提供支持，所以可以预计，旧的C++头文件在未来几年内还是会被支持。

所以，实际来说，下面是C++头文件的现状：

• 旧的C++头文件名如<iostream.h>将会继续被支持，尽管它们不在官方标准中。这些头文件的内容不在名字空间std中。
• 新的C++头文件如<iostream>包含的基本功能和对应的旧头文件相同，但头文件的内容在名字空间std中。（在标准化的过程中，库中有些部分的细节被修改了，所以旧头文件和新头文件中的实体不一定完全对应。）
• 标准C头文件如<stdio.h>继续被支持。头文件的内容不在std中。
• 具有C库功能的新C++头文件具有如<cstdio>这样的名字。它们提供的内容和相应的旧C头文件相同，只是内容在std中。

所有这些初看有点怪，但不难习惯它。最大的挑战是把字符串头文件理清楚：<string.h>是旧的C头文件，对应的是基于char*的字符串处理函数；<string>是包装了std的C++头文件，对应的是新的string类（看下文）；<cstring>是对应于旧C头文件的std版本。如果能掌握这些（我相信你能），其余的也就容易了。

关于标准库，需要知道的第二点是，库中的一切几乎都是模板。看看你的老朋友iostream。（如果你和iostream不是朋友，转到条款2，看看你为什么要和它发展关系）iostream帮助你操作字符流，但什么是字符？是char吗？是wchar_t？是Unicode字符？一些其它的多字节字符？没有明显正确的答案，所以标准库让你去选。所有的流类（stream class）实际上是类模板，在实例化流类的时候指定字符类型。例如，标准库将cout类型定义为ostream，但ostream实际上是一个basic_ostream<char>类型定义（typedef ）。

类似的考虑适用于标准库中其它大部分类。string不是类，它是类模板：类型参数限定了每个string类中的字符类型。complex不是类，它是类模板：类型参数限定了每个complex类中实数部分和虚数部分的类型。vector不是类，它是类模板。如此不停地进行下去。

在标准库中你无法避开模板，但如果只是习惯于和char类型的流和字符串打交道，通常可以忽略它们。这是因为，对这些组件的char实例，标准库都为它们定义了typedef，这样你就可以在编程时继续使用cin，cout，cerr等对象，以及istream，ostream，string等类型，不必担心cin的真实类型是basic_istream<char>以及string的真实类型是basic_string<char>。

标准库中很多组件的模板化和上面所建议的大不相同。再看看那个概念上似乎很直观的string。当然，可以基于 "它所包含的字符类型" 确定它的参数，但不同的字符集在细节上有不同，例如，特殊的文件结束字符，拷贝它们的数组的最有效方式，等等。这些特征在标准中被称为traits，它们在string实例中通过另外一个模板参数指定。此外，string对象要执行动态内存分配和释放，但完成这一任务有很多不同的方法（参见条款10）。哪一个最好？你得选择：string模板有一个Allocator参数，Allocator类型的对象被用来分配和释放string对象所使用的内存。

这里有一个basic_string模板的完整声明，以及建立在它之上的string类型定义（typedef）；你可以在<string>头文件中找到它（或与之相当的什么东西）：

namespace std 
{template<class charT,class traits = char_traits<charT>,class Allocator = allocator<charT> >
class basic_string;typedef basic_string<char> string;}

注意，basic_string的traits和Allocator参数有缺省值。这在标准库中是很典型的做法。它为使用者提供了灵活性， 但对于这种灵活性所带来的复杂性，那些只想做 "正常" 操作的"典型" 用户却又可以避开。换句话说，如果只想使用象C字符串那样的字符串对象，就可以使用string对象，而不用在意实际上是在用basic_string<char, char_traits<char>, allocator<char> >类型的对象。

是的，通常可以这么做，但有时还是得稍稍看看底层。例如，条款34指出，声明一个类而不提供定义具有优点；它还指出，下面是一种声明string类型的错误方法：

class string; // 会通过编译，但
// 你不会这么做

先不要考虑名字空间，这里真正的问题在于：string不是一个类，而是一个typedef。如果可以通过下面的方法解决问题就太好了：

typedef basic_string<char> string;

但这又不能通过编译。"你所说的basic_string是什么东西？" 编译器会奇怪 ---- 当然，它可能会用不同的语句来问你。所以，为了声明string，首先得声明它所依赖的所有模板。如果可以这么做的话，就会象下面这样：

template<class charT> struct char_traits;template<class T> class allocator;template<class charT,class traits = char_traits<charT>,class Allocator = allocator<charT> >
class basic_string;typedef basic_string<char> string;

然而，你不能声明string。至少不应该。这是因为，标准库的实现者声明的stirng（或std名字空间中任何其它东西）可以和标准中所指定的有所不同，只要最终提供的行为符合标准就行。例如，basic_string的实现可以增加第四个模板参数，但这个参数的缺省值所产生的代码的行为要和标准中所说的原始的basic_string一致。

那到底该怎么办？不要手工声明string（或标准库中其它任何部分）。相反，只用包含一个适当的头文件，如<string>。

有了头文件和模板的这些知识，现在可以看看标准C++库中有哪些主要组件：

• 标准C库。它还在，你还可以用它。虽然有些地方有点小的修修补补，但无论怎么说，还是那个用了多年的C库。
• Iostream。和 "传统" Iostream的实现相比，它已经被模板化了，继承层次结构也做了修改，增强了抛出异常的能力，可以支持string（通过stringstream类）和国际化（通过locales ---- 见下文）。当然，你期望Iostream库所具有的东西几乎全都继续存在。也就是说，它还是支持流缓冲区，格式化标识符，操作子和文件，还有cin，cout，cerr和clog对象。这意味着可以把string和文件当做流，还可以对流的行为进行更广泛的控制，包括缓冲和格式化。
• String。string对象在大多数应用中被用来消除对char*指针的使用。它们支持你所期望的那些操作（例如，字符串连接，通过operator[]对单个字符进行常量时间级的访问，等等），它们可以转换成char*，以保持和现有代码的兼容性，它们还自动处理内存管理。一些string的实现采用了引用计数（参见条款M29），这会带来比基于char*的字符串更佳的性能（时间和空间上）。
• 容器。不要再写你自己的基本容器类！标准库提供了下列高效的实现：vector（就象动态可扩充的数组），list（双链表），queue， stack，deque，map，set和bitset。唉，竟然没有hash table（虽然很多制造商作为扩充提供），但多少可以作为补偿的一点是， string是容器。这很重要，因为它意味着对容器所做的任何操作（见下文）对string也适用。

• 算法。标准容器当然好，如果存在易于使用它们的方法就更好。标准库就提供了大量简易的方法（即，预定义函数，官方称为算法(algorithm) ---- 实际上是函数模板），其中的大多数适用于库中所有的容器 ---- 以及内建数组（built-in arrays）！

• 对国际化的支持。不同的文化以不同的方式行事。和C库一样，C++库提供了很多特性有助于开发出国际化的软件。但虽然从概念上来说和C类似，其实C++的方法还是有所不同。例如，C++为支持国际化广泛使用了模板，还利用了继承和虚函数，这些一定不会让你感到奇怪。

• 对数字处理的支持。FORTRAN的末日可能就快到了。C++库为复数类（实数和虚数部分的精度可以是float，double或long double）和专门针对数值编程而设计的特殊数组提供了模板。例如，valarray类型的对象可用来保存可以任意混叠(aliasing)的元素。这使得编译器可以更充分地进行优化，尤其是对矢量计算机来说。标准库还对两种不同类型的数组片提供了支持，并提供了算法计算内积(inner product)，部分和(partial sum)，临差(adjacent difference)等。

• 诊断支持。标准库支持三种报错方式：C的断言（参见条款7），错误号，例外。为了有助于为例外类型提供某种结构，标准库定义了下面的例外类（exception class）层次结构：

条款55：熟悉 Boost 库

弄清C++在幕后为你所写、所调用的函数

一个空类什么时候不是空类？ ---- 当C++编译器通过它的时候。如果你没有声明下列函数，体贴的编译器会声明它自己的版本。这些函数是：一个拷贝构造函数，一个赋值运算符，一个析构函数，一对取址运算符。另外，如果你没有声明任何构造函数，它也将为你声明一个缺省构造函数。所有这些函数都是公有的。换句话说，如果你这么写：

class Empty{};

和你这么写是一样的：

class Empty 
{
public:Empty();                        // 缺省构造函数Empty(const Empty& rhs);        // 拷贝构造函数~Empty();                       // 析构函数 ---- 是否// 为虚函数看下文说明Empty&operator=(const Empty& rhs);    // 赋值运算符Empty* operator&();             // 取址运算符const Empty* operator&() const;
};

现在，如果需要，这些函数就会被生成，但你会很容易就需要它们。下面的代码将使得每个函数被生成：

const Empty e1;                     // 缺省构造函数析构函数
Empty e2(e1);                       // 拷贝构造函数
e2 = e1;                            //  赋值运算符
Empty *pe2 = &e2;                   // 取址运算符(非const)
const Empty *pe1 = &e1;             //  取址运算符(const)

inline Empty::Empty() {}inline Empty::~Empty() {}inline Empty * Empty::operator&() { return this; }inline const Empty * Empty::operator&() const
{ return this; }

至于拷贝构造函数和赋值运算符，官方的规则是：缺省拷贝构造函数（赋值运算符）对类的非静态数据成员进行 "以成员为单位的" 逐一拷贝构造（赋值）。即，如果m是类C中类型为T的非静态数据成员，并且C没有声明拷贝构造函数（赋值运算符），m将会通过类型T的拷贝构造函数（赋值运算符）被拷贝构造（赋值）---- 如果T有拷贝构造函数（赋值运算符）的话。如果没有，规则递归应用到m的数据成员，直至找到一个拷贝构造函数（赋值运算符）或固定类型（例如，int，double，指针，等）为止。默认情况下，固定类型的对象拷贝构造（赋值）时是从源对象到目标对象的 "逐位" 拷贝。对于从别的类继承而来的类来说，这条规则适用于继承层次结构中的每一层，所以，用户自定义的构造函数和赋值运算符无论在哪一层被声明，都会被调用。

我希望这已经说得很清楚了。

但怕万一没说清楚，还是给个例子。看这样一个NamedObject模板的定义，它的实例是可以将名字和对象联系起来的类：

template<class T>
class NamedObject 
{
public:NamedObject(const char *name, const T& value);NamedObject(const string& name, const T& value);    //...private:string nameValue;T objectValue;
};

因为NamedObject类声明了至少一个构造函数，编译器将不会生成缺省构造函数；但因为没有声明拷贝构造函数和赋值运算符，编译器将生成这些函数（如果需要的话）。

看下面对拷贝构造函数的调用：

NamedObject<int> no1("Smallest Prime Number", 2);

NamedObject<int> no2(no1); // 调用拷贝构造函数

编译器生成的拷贝构造函数必须分别用no1.nameValue和no1.objectValue来初始化no2.nameValue和no2.objectValue。nameValue的类型是string，string有一个拷贝构造函数（你可以在标准库中查看string来证实 ---- 参见条款49），所以no2.nameValue初始化时将调用string的拷贝构造函数，参数为no1.nameValue。另一方面，NamedObject<int>::objectValue的类型是int（因为这个模板实例中，T是int），int没有定义拷贝构造函数，所以no2.objectValue是通过从no1.objectValue拷贝每一个比特(bit)而被初始化的。

编译器为NamedObject<int>生成的赋值运算符也以同样的方式工作，但通常，编译器生成的赋值运算符要想如上面所描述的那样工作，与此相关的所有代码必须合法且行为上要合理。如果这两个条件中有一个不成立，编译器将拒绝为你的类生成operator=，你就会在编译时收到一些诊断信息。

例如，假设NamedObject象这样定义，nameValue是一个string的引用，objectValue是一个const T：

template<class T>
class NamedObject 
{
public:// 这个构造函数不再有一个const名字参数，因为nameValue// 现在是一个非const string的引用。char*构造函数// 也不见了，因为引用要指向的是stringNamedObject(string& name, const T& value);//...         // 同上，假设没有// 声明operator=
private:string& nameValue;           // 现在是一个引用const T objectValue;         // 现在为const
};

现在看看下面将会发生什么：

string newDog("Persephone");
string oldDog("Satch");NamedObject<int> p(newDog, 2);      // 正在我写本书时，我们的爱犬Persephone即将过她的第二个生日
NamedObject<int> s(oldDog, 29);     // 家犬Satch如果还活着，会有29岁了（从我童年时算起）
p = s;                              // p中的数据成员将会发生些什么呢？

赋值之前，p.nameValue指向某个string对象，s.nameValue也指向一个string，但并非同一个。赋值会给p.nameValue带来怎样的影响呢？赋值之后，p.nameValue应该指向 "被s.nameValue所指向的string" 吗，即，引用本身应该被修改吗？如果是这样，那太阳从西边出来了，因为C++没有办法让一个引用指向另一个不同的对象（参见条款M1）。或者，p.nameValue所指的string对象应该被修改吗？ 这样的话，含有 "指向那个string的指针或引用" 的其它对象也会受影响，也就是说，和赋值没有直接关系的其它对象也会受影响。这是编译器生成的赋值运算符应该做的吗？

面对这样的难题，C++拒绝编译这段代码。如果想让一个包含引用成员的类支持赋值，你就得自己定义赋值运算符。对于包含const成员的类（例如上面被修改的类中的objectValue）来说，编译器的处理也相似；因为修改const成员是不合法的，所以编译器在隐式生成赋值函数时也会不知道怎么办。还有，如果派生类的基类将标准赋值运算符声明为private， 编译器也将拒绝为这个派生类生成赋值运算符。因为，编译器为派生类生成的赋值运算符也应该处理基类部分（见条款16和M33），但这样做的话，就得调用对派生类来说无权访问的基类成员函数，这当然是不可能的。

以上关于编译器生成函数的讨论引发了这样的问题：如果想禁止使用这些函数，那该怎么办呢？也就是说，假如你永远不想让类的对象进行赋值，所以有意不声明operator=，那该怎么做呢？这个小难题的解决方案正是条款27讨论的主题。指针成员和编译器生成的拷贝构造函数及赋值运算符之间的相互影响经常被人忽视，关于这个话题的讨论请查看条款11。

宁可编译和链接时出错，也不要运行时出错

除了极少数情况下会使C++抛出异常（例如，内存耗尽 ---- 见条款7）外，运行时错误的概念和C++没什么关系，就象在C中一样。没有下溢，上溢，除零检查；没有数组越界检查，等等。一旦程序通过了编译和链接，你就得靠自己了 ---- 一切后果自负。这很象跳伞运动，一些人从中找到了刺激，另一些人则吓得摔成了残废。这一思想背后的动机当然在于效率：没有运行时检查，程序会更小更快。

处理这类事情有另一个不同的方法。一些语言如Smalltalk和LISP通常在编译链接期间只是检查极少一些错误，但却提供了强大的运行时系统来处理执行期间的错误。不象C++，这些语言几乎都是解释型的，在提供额外灵活性的同时，它们也带来了性能上的损失。

不要忘了你是在用C++编程。即使发现Smalltalk/LISP的方法很吸引人，也要忘掉它们。常说要坚持党的路线，现在的情况下，它的含义就是要避免运行时错误。只要有可能，就要让出错检查从运行时退回到链接时，或者，最理想的是，编译时。

这种方法带来的好处不仅仅在于程序的大小和速度，还有可靠性。如果程序通过了编译和链接而没有产生错误信息，你就可以确信程序中没有编译器和链接器能检查得到的任何错误，仅此而已。（当然，另一个可能性是，编译器或链接器有问题，但不要拿这种可能性来困扰我们。）

对于运行时错误来说，情况大不一样。在某次运行期间程序没有产生任何运行时错误，你就能确信另一次不同的运行期内不会产生错误吗？比如：在另一次运行中，你以不同的顺序做事，或者采用不同的数据，或者运行更长或更短时间，等等。你可以不停地测试自己的程序直到面色发紫，但你还是不能覆盖所有的可能性。因而，运行时发现错误比在编译链接期间检查错误更不能让人放心。

通常，对设计做一点小小的改动，就可以在编译期间消除可能产生的运行时错误。这常常涉及到在程序中增加新的数据类型（参见条款M33）。例如，假设想写一个类来表示时间中的日期，最初的做法可能象这样：

class Date 
{
public:Date(int day, int month, int year);   //...    
};

准备实现这个构造函数，面临的一个问题是对day和month值的合法性检查。让我们来看看，对于传给month的值来说，怎么做可以免于对它进行合法性检查呢？

一个明显的办法是采用枚举类型而不用整数：

enum Month { Jan = 1, Feb = 2, /* ... , */  Nov = 11, Dec = 12 };class Date {
public:Date(int day, Month month, int year);    //...    
};

遗憾的是，这不会换来多少好处，因为枚举类型不需要初始化：

Month m;
Date d(22, m, 1857); // m是不确定的

所以，Date构造函数还是得验证month参数的值。

既想免除运行时检查，又要保证足够的安全性，你就得用一个类来表示month，你就得保证只有合法的month才被创建：

class Month 
{
public:static const Month Jan() { return 1; }static const Month Feb() { return 2; }//...static const Month Dec() { return 12; }int asInt() const           // 为了方便，使Month{ return monthNumber; }     // 可以被转换为intprivate:Month(int number): monthNumber(number) {}const int monthNumber;
};class Date {
public:Date(int day, const Month& month, int year);//...
};

这个设计在几个方面的特点综合确定了它的工作方式。首先，Month构造函数是私有的。这防止了用户去创建新的month。可供使用的只能是Month的静态成员函数返回的对象，再加上它们的拷贝。第二，每个Month对象为const，所以它们不能被改变（否则，很多地方会忍不住将一月转换成六月，特别是在北半球）。最后一点，得到Month对象的唯一办法是调用函数或拷贝现有的Month（通过隐式Month拷贝构造函数 ---- 见条款45）。这样，就可以在任何时间任何地方使用Month对象；不必担心无意中使用了没有被初始化的对象。（否则就可能有问题。条款47进行了说明）

有了这些类，用户几乎不可能指定一个非法的month，甚至完全不可能 ---- 如果不出现下面这种可恶的情况的话：

Month *pm; // 定义未被初始化的指针

Date d(1, *pm, 1997); // 使用未被初始化的指针!

但这种情况所涉及的是另一个问题，即通过未被初始化的指针取值，其结果是不可确定的。（参见条款3，看看我对 "不确定行为" 的感受）遗憾的是，我没有办法来防止或检查这种异端行为。但是，如果假设这种情况永远不会发生，或者如果我们不考虑这种情况下软件的行为，Date构造函数对它的Month参数就可以免于合法性检查。另一方面，构造函数还是必须检查day参数的合法性 ---- 九月，四月，六月和十一月各有多少天呢？

Date的例子将运行时检查用编译时检查来取代。你可能想知道什么时候可以使用链接时检查。实际上，不是经常这么做。C++用链接器来保证所需要的函数只被定义一次（参见条款45，"需要" 一个函数会带来什么）。它还使用链接器来保证静态对象（参见条款47）只被定义一次。你可以用同样的方法使用链接器。例如，条款27说明，对于一个显式声明的函数，如果想有意禁止对它进行定义，链接器检查就很有用。

但不要过于强求。想消除所有的运行检查是不切实际的。例如，任何允许交互式输入的程序都要进行输入验证。同样地，某个类中如果包含需要执行上下限检查的数组，每次访问数组时就要对数组下标进行检查。尽管如此，将检查从运行时转移到编译或链接时一直是值得努力的目标，只要实际可行，就要追求这一目标。这样做的奖赏是，程序会更小，更快，更可靠。

确保非局部静态对象在使用前被初始化

大家都是成年人了，所以用不着我来告诉你们：使用未被初始化的对象无异于蛮干。事实上，关于这个问题的整个想法会让你觉得可笑；构造函数可以确保对象在创建时被初始化，难道不是这样吗？

唔，是，也不是。在某个特定的被编译单元（即，源文件）中，可能一切都不成问题；但如果在某个被编译单元中，一个对象的初始化要依赖于另一个被编译单元中的另一个对象的值，并且这第二个对象本身也需要初始化，事情就会变得更复杂。

例如，假设你已经写了这样一个程序库，它提供一个文件系统的抽象，其中可能包括一个功能，使得互联网上的文件看起来就象在本地一样。既然程序库使得整个世界看起来象一个单独的文件系统，你就可以在程序库的名字空间（见条款28）中创建一个专门的对象，theFileSystem，这样，用户任何时候需要和程序库所提供的文件系统交互，都可以使用它：

class FileSystem { ... };            // 在个类在你的程序库中
FileSystem theFileSystem;    // 程序库用户和这个对象交互

因为theFileSystem表示的是很复杂的东西，所以它的构造重要而且必需；在theFileSystem还没构造之前就使用它会造成不可确定的行为。（然而，参考条款M17，象theFileSystem这样的对象，其初始化可以被有效、安全地延迟。）

现在假设某个程序库的用户创建了一个类，表示文件系统中的目录。很自然地，这个类使用了theFileSystem：

class Directory  // 由程序库的用户创建
{ 
public:Directory();//...
};Directory::Directory()
{//通过调用theFileSystem的成员函数//创建一个Directory对象;
}

进一步假设用户想为临时文件专门创建一个全局Directory对象：
        Directory tempDir;                  // 临时文件目录
现在，初始化顺序的问题变得很明显了：除非theFileSystem在tempDir之前被初始化，否则，tempDir的构造函数将会去使用还没被初始化的theFileSystem。但theFileSystem和tempDir是由不同的人在不同的时间、不同的文件中创建的。怎么可以确认theFileSystem在tempDir之前被创建呢？

任何时候，如果在不同的被编译单元中定义了 "非局部静态对象" ，并且这些对象的正确行为依赖于它们被初始化的某一特定顺序，这类问题就会产生。非局部静态对象指的是这样的对象：

• 定义在全局或名字空间范围内（例如：theFileSystem和tempDir），
• 在一个类中被声明为static，或，
• 在一个文件范围被定义为static。

class FileSystem { /* ... */ };     // 同前
FileSystem& theFileSystem()         // 这个函数代替了theFileSystem对象
{static FileSystem tfs;          // 定义和初始化// 局部静态对象// (tfs = "the file system")return tfs;                     // 返回它的引用
}class Directory { /* ... */ };      // 同前Directory::Directory()
{//同前，除了theFileSystem被theFileSystem()代替;
}Directory& tempDir()            // 这个函数代替了tempDir对象
{  static Directory td;        // 定义和初始化局部静态对象    return td;                  // 返回它的引用
}

系统被修改后，用户还是完全和以前一样编程，只是现在他们用的是theFileSystem()和tempDir()，而不是theFileSystem和tempDir。即，他们所用的是返回对象引用的函数，而不是对象本身。

这种返回引用的函数虽然采用了上面所讨论的技术，但函数本身总是很简单：第一行定义并初始化一个局部静态对象，第二行返回它，仅此而已。因为太简单，你可能很想把它声明为inline。条款33指出，对于C++语言规范的最新修订版本来说，这是一个非常有效的实现策略；但它同时指出，在使用之前，一定要确认你的编译器和标准中的相关要求要一致。如果编译器不符合最新标准，你又象上面那样使用内联，就可能造成函数以及函数内部静态对象有多份拷贝。这足以让一个成年的程序员哭泣。

至此已没有什么神秘之处了。为了使这一技术有效，一定要给对象一个合理的初始化顺序。如果你让对象A必须在对象B之前初始化，同时又让A的初始化依赖于B已经被初始化，你就会惹上麻烦，坦白说，是罪有应得。如果能避开这种不合理的情况，本条款所介绍的方案将会很好地为你提供帮助。

提高对CPP的认识

C++中有很多 "东西"：C，重载，面向对象，模板，例外，名字空间。这么多东西，有时让人感到不知所措。怎么弄懂所有这些东西呢？

C++之所以发展到现在这个样子，在于它有自己的设计目标。理解了这些设计目标，就不难弄懂所有这些东西了。C++最首要的目标在于：

• 和C的兼容性。很多很多C还存在，很多很多C程序员还存在。C++利用了这一基础，并建立在 ---- 我是指 "平衡在" ---- 这一基础之上。
• 效率。作为C++的设计者和第一个实现者，Bjarne Stroustrup从一开始就清楚地知道，要想把C程序员争取过来，就要避免转换语言会带来性能上的损失，否则他们不会对C++再看第二眼。结果，他确信C++在效率上可以和C匹敌 ---- 二者相差大约在5%之内。
• 和传统开发工具及环境的兼容性。各色不同的开发环境到处都是，编译器、链接器和编辑器则无处不在。从小型到大型的所有开发环境，C++都要轻松应对，所以带的包袱越轻越好。想移植C++？你实际上移植的只是一种语言，并利用了目标平台上现有的工具。（然而，往往也可能带来更好的实现，例如，如果链接器能被修改，使得它可以处理内联和模板在某些方面更高的要求）
• 解决真实问题的可应用性。C++没有被设计为一种完美的，纯粹的语言，不适于用它来教学生如何编程。它是设计为专业程序员的强大工具，用它来解决各种领域中的真实问题。真实世界都有些磕磕碰碰，因此，程序员们所依赖的工具如果偶尔出点问题，也不值得大惊小怪。

class Base 
{
public:virtual void f(int x);
};class Derived: public Base 
{
public:virtual void f(double *pd);
};Derived *pd = new Derived;
pd->f(10);                            // 错误!

class Derived: public Base 
{
public:using Base::f;                   // 将Base::f引入到// Derived的空间范围virtual void f(double *pd);
};Derived *pd = new Derived;
pd->f(10);                         // 正确，调用Base::f

class Derived: public Base {
public:virtual void f(int x) { Base::f(x); }virtual void f(double *pd);
};Derived *pd = new Derived;
pd->f(10);                 // 正确，调用Derived::f(int)，间接调用了Base::f(int)

----------------------------------------------------------------------------------------------