Effective C++ 2e: 类和函数：设计与声明

类和函数：设计与声明

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

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

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

·对象将如何被创建和摧毁？它将极大地影响构造函数和析构函数的设计，以及自定义的operator new, operator new[], operator delete, 和operator delete[]。（条款M8描述了这些术语的区别）

·对象初始化和对象赋值有什么不同？答案决定了构造函数和赋值运算符的行为以及它们之间的区别。

·通过值来传递新类型的对象意味着什么？记住，拷贝函数负责对此做出回答。

·新类型的合法值有什么限制？这些限制决定了成员函数（特别是构造函数和赋值运算符）内部的错误检查的种类。它可能还影响到函数抛出的例外的种类以及函数的例外规范（参见条款M14），如果你使用它们的话。

·新类型符合继承关系吗？如果是从已有的类继承而来，那么新类的设计就要受限于这些类，特别是受限于被继承的类是虚拟的还是非虚拟的。如果新类允许被别的类继承，这将影响到函数是否要声明为虚拟的。

·允许哪种类型转换？如果允许类型A的对象隐式转换为类型B的对象，就要在类A中写一个类型转换函数，或者，在类B中写一个可以用单个参数来调用的非explicit构造函数。如果只允许显式转换，就要写函数来执行转换功能，但不用把它们写成类型转换运算符和或单参数的非explicit构造函数。（条款M5讨论了用户自定义转换函数的优点和缺点）

·什么运算符和函数对新类型有意义？答案决定了将要在类接口中声明什么函数。

·哪些运算符和函数要被明确地禁止？它们需要被声明为private。

·谁有权访问新类型的成员？这个问题有助于决定哪些成员是公有的，哪些是保护的，哪些私有的。它还有助于确定哪些类和/或函数必须是友元，以及将一个类嵌套到另一个类中是否有意义。

·新类型的通用性如何？也许你实际上不是在定义一个新的类型，而是在定义一整套的类型。如果是这样，就不要定义一个新类，而要定义一个新的类模板。

这些都是很难回答的问题，所以C++中定义一个高效的类远不是那么简单。但如果做好了，C++中用户自定义的类所产生的类型就会和固定类型几乎没什么区别，如果能达到这样的效果，其价值也就体现出来了。

上面每一个问题如果要详细讨论都可以单独组成一本书。所以后面条款中所介绍的准则决不会面面俱到。但是，它们强调了在设计中一些很重要的注意事项，提醒一些常犯的错误，对设计者常碰到的一些问题提供了解决方案。很多建议对非成员函数和成员函数都适用，所以本章节我也考虑了全局函数和名字空间中的函数的设计和声明。

条款18: 争取使类的接口完整并且最小

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

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

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

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

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

撇开处世原则方面的因素不谈——牵就你的用户真的正确吗？——充斥着大量函数的类的接口从技术上来说有很多缺点。第一，接口中函数越多，以后的潜在用户就越难理解。他们越难理解，就越不愿意去学该怎么用。一个有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，
                              // 请参见条款49

  BoundsCheckingStatus checkingBounds;
};

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

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

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

Array(int size,
      BoundsCheckingStatus check = NO_CHECK_BOUNDS);

但这就不能成为最小接口了，因为带上下限参数的那个构造函数可以完成同样的事。尽管如此，出于某些目的去迎合那些老程序员们的需要也可能是明智的，特别是出于和基本语言（C语言）一致的考虑。

还需要哪些函数？对于一个完整的接口来说当然还需要对数组的索引：

// 返回可以读/写的元素
T& operator[](int index);

// 返回只读元素
const T& operator[](int index) const;

通过两次声明同一个函数，一次带const一次没有const，就提供了对const和非const Array对象的支持。返回值不同很重要，条款21对此进行了说明。

现在，Array模板支持构造函数，析构函数，传值，赋值，索引，你可能想到这已经是一个完整的接口了。但再看清楚一些。假如一个用户想遍历一个整数数组，打印其中的每一个元素，如下所示：

Array<int> a(10, 20);      // 下标上下限为：10到20

...

for (int i = a的下标下限; i <= a的下标上限; ++i)
  cout << "a[" << i << "] = " << a[i] << '/n';

用户怎么得到a的下标上下限呢？答案取决于Array对象的赋值操作做了些什么，即在Array::operator=里做了什么。特别是，如果赋值操作可以改变Array对象的上下限，就必须提供一个返回当前上下限值的成员函数，因为用户无法总能在程序的某个地方推出上下限值是多少。比如上面的例子，a是在被定义后、用于循环前的时间段里被赋值的，用户在循环语句中就无法知道a当前的上下限值。

如果Array对象的上下限值在赋值时不能改变，那它在a被定义时就固定下来了，用户就可能有办法（虽然很麻烦）对其进行跟踪。这种情况下，提供一个函数返回当前上下限值是很方便，但接口就不能做到最小。

继续前面的赋值操作可以改变对象上下限的假设，上下限函数可以这样声明：

int lowBound() const;
int highBound() const;

因为这两个函数不对它们所在的对象进行任何修改操作，而且为遵循“能用const就尽量用const”的原则（见条款21），它们被声明为const成员函数。有了这两个函数，循环语句可以象下面这样写：

for (int i = a.lowBound(); i <= a.highBound(); ++i)
  cout << "a[" << i << "] = " << a[i] << '/n';

当然，要使这样一个操作类型T的对象数组的循环语句工作，还要为类型T的对象定义一个operator<<函数。（说得不太准确。应该是，必须有一个类型T的operator<<，或，T可以隐式转换（见条款M5）成的其它类型的operator<<）

一些人会争论，Array类应该提供一个函数以返回Array对象里元素的数量。元素的数量可以简单地得到：highBound()-lowBound()+1，所以这个函数不是那么真的必要。但考虑到很多人经常忘了"+1"，增加这个函数也不是坏主意。

还有一些其他函数可以加到类里，包括那些输入输出方面的操作，还有各种关系运算符（例如，<, >, ==, 等）。但这些函数都不是最小接口的一部分，因为它们都可以通过包含operator[]调用的循环来实现。

说到象operator<<, operator>>这样的函数以及关系运算符，条款19解释了为什么它们经常用非成员的友元函数而不用成员函数来实现。另外，不要忘记友元函数在所有实际应用中都是类的接口的一部分。这意味着友元函数影响着类的接口的完整性和最小性。

条款19: 分清成员函数，非成员函数和友元函数

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

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

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

private:
  ...
};

这是一个没有一点用处的类。（用条款18的术语来说，接口的确最小，但远不够完整。）所以，要对它增加加，减，乘等算术操作支持，但是，该用成员函数还是非成员函数，或者，非成员的友元函数来实现呢？

当拿不定主意的时候，用面向对象的方法来考虑！有理数的乘法是和Rational类相联系的，所以，写一个成员函数把这个操作包到类中。

class Rational {
public:

  ...

  const Rational operator*(const Rational& rhs) const;
};

（如果你不明白为什么这个函数以这种方式声明——返回一个const值而取一个const的引用作为它的参数——参考条款21-23。）

现在可以很容易地对有理数进行乘法操作：

Rational oneEighth(1, 8);
Rational oneHalf(1, 2);

Rational result = oneHalf * oneEighth;   // 运行良好

result = result * oneEighth;             // 运行良好

但不要满足，还要支持混合类型操作，比如，Rational要能和int相乘。但当写下下面的代码时，只有一半工作：

result = oneHalf * 2;      // 运行良好

result = 2 * oneHalf;      // 出错!

这是一个不好的苗头。记得吗？乘法要满足交换律。

如果用下面的等价函数形式重写上面的两个例子，问题的原因就很明显了：

result = oneHalf.operator*(2);      // 运行良好

result = 2.operator*(oneHalf);      // 出错!

对象oneHalf是一个包含operator*函数的类的实例，所以编译器调用了那个函数。而整数2没有相应的类，所以没有operator*成员函数。编译器还会去搜索一个可以象下面这样调用的非成员的operator*函数（即，在某个可见的名字空间里的operator*函数或全局的operator*函数）：

result = operator*(2, oneHalf);      // 错误!

但没有这样一个参数为int和Rational的非成员operator*函数，所以搜索失败。

再看看那个成功的调用。它的第二参数是整数2，然而Rational::operator*期望的参数却是Rational对象。怎么回事？为什么2在一个地方可以工作而另一个地方不行？

秘密在于隐式类型转换。编译器知道传的值是int而函数需要的是Rational，但它也同时知道调用Rational的构造函数将int转换成一个合适的Rational，所以才有上面成功的调用（见条款M19）。换句话说，编译器处理这个调用时的情形类似下面这样：

const Rational temp(2);      // 从2产生一个临时
                             // Rational对象

result = oneHalf * temp;     // 同oneHalf.operator*(temp);

当然，只有所涉及的构造函数没有声明为explicit的情况下才会这样，因为explicit构造函数不能用于隐式转换，这正是explicit的含义。如果Rational象下面这样定义：

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.data
  point to it

  return 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的成员函数。

条款20: 避免public接口出现数据成员

首先，从“一致性”的角度来看这个问题。如果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接口里放上数据成员无异于自找麻烦，所以要把数据成员安全地隐藏在与功能分离的高墙后。如果现在就开始这么做，那我们就可以无需任何代价地换来一致性和精确的访问控制。

条款21: 尽可能使用const

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

const关键字实在是神通广大。在类的外面，它可以用于全局或名字空间常量（见条款1和47），以及静态对象（某一文件或程序块范围内的局部对象）。在类的内部，它可以用于静态和非静态成员（见条款12）。

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

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有可能提高一个函数的安全性和效率，否则还会出问题。

例如，看这个在条款19中介绍的有理数的operator*函数的声明：

const Rational operator*(const Rational& lhs,
                         const Rational& rhs);

很多程序员第一眼看到它会纳闷：为什么operator*的返回结果是一个const对象？因为如果不是这样，用户就可以做下面这样的坏事：

Rational a, b, c;

...

(a * b) = c;      // 对a*b的结果赋值

我不知道为什么有些程序员会想到对两个数的运算结果直接赋值，但我却知道：如果a，b和c是固定类型，这样做显然是不合法的。一个好的用户自定义类型的特征是，它会避免那种没道理的与固定类型不兼容的行为。对我来说，对两个数的运算结果赋值是非常没道理的。声明operator*的返回值为const可以防止这种情况，所以这样做才是正确的。

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

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

class String {
public:

  ...

  // 用于非const对象的operator[]
  char& operator[](int position)
  { return data[position]; }

  // 用于const对象的operator[]
  const char& operator[](int position) const
  { return data[position]; }

private:
  char *data;
};

String s1 = "Hello";
cout << s1[0];                  // 调用非const
                                // String::operator[]
const String s2 = "World";
cout << s2[0];                  // 调用const
                                // String::operator[]

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

String s = "Hello";              // 非const String对象

cout << s[0];                    // 正确——读一个
                                 // 非const String

s[0] = 'x';                      // 正确——写一个
                                 // 非const String

const String cs = "World";       // const String 对象

cout << cs[0];                   // 正确——读一个
                                 // const String

cs[0] = 'x';                     // 错误!——写一个
                                 // const String

另外注意，这里的错误只和调用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 above

private:
  char *data;

  mutable size_t dataLength;      // 这些数据成员现在
                                  // 为mutable；他们可以在
  mutable bool lengthIsValid;     // 任何地方被修改，即使
                                  // 在const成员函数里
};

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）不会修改它的参数所指的数据时，才能保证它可以正常工作。

条款22: 尽量用“传引用”而不用“传值”

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——传值实际上会比传引用更高效。

条款23: 必须返回一个对象时不要试图返回一个引用

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

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

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

class Rational {
public:
  Rational(int numerator = 0, int denominator = 1);

  ...

private:
  int n, d;              // 分子和分母

friend
  const Rational                      // 参见条款21：为什么
    operator*(const Rational& lhs,    // 返回值是const
              const Rational& rhs)    
};

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

很明显，这个版本的operator*是通过传值返回对象结果，如果不去考虑对象构造和析构时的开销，你就是在逃避作为一个程序员的责任。另外一件很明显的事实是，除非确实有必要，否则谁都不愿意承担这样一个临时对象的开销。那么，问题就归结于：确实有必要吗？

答案是，如果能返回一个引用，当然就没有必要。但请记住，引用只是一个名字，一个其它某个已经存在的对象的名字。无论何时看到一个引用的声明，就要立即问自己：它的另一个名字是什么呢？因为它必然还有另外一个什么名字（见条款M1）。拿operator*来说，如果函数要返回一个引用，那它返回的必须是其它某个已经存在的Rational对象的引用，这个对象包含了两个对象相乘的结果。

但，期望在调用operator*之前有这样一个对象存在是没道理的。也就是说，如果有下面的代码：

Rational a(1, 2);                // a = 1/2
Rational b(3, 5);                // b = 3/5
Rational c = a * b;              // c 为 3/10

期望已经存在一个值为3/10的有理数是不现实的。如果operator* 一定要返回这样一个数的引用，就必须自己创建这个数的对象。

一个函数只能有两种方法创建一个新对象：在堆栈里或在堆上。在堆栈里创建对象时伴随着一个局部变量的定义，采用这种方法，就要这样写operator*：

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

这个方法应该被否决，因为我们的目标是避免构造函数被调用，但result必须要象其它对象一样被构造。另外，这个函数还有另外一个更严重的问题，它返回的是一个局部对象的引用，关于这个错误，条款31进行了深入的讨论。

那么，在堆上创建一个对象然后返回它的引用呢？基于堆的对象是通过使用new产生的，所以应该这样写operator*：

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

首先，你还是得负担构造函数调用的开销，因为new分配的内存是通过调用一个适当的构造函数来初始化的（见条款5和M8）。另外，还有一个问题：谁将负责用delete来删除掉new生成的对象呢？

实际上，这绝对是一个内存泄漏。即使可以说服operator*的调用者去取函数返回值地址，然后用delete去删除它（绝对不可能——条款31展示了这样的代码会是什么样的），但一些复杂的表达式会产生没有名字的临时值，程序员是不可能得到的。例如：

Rational w, x, y, z;

w = x * y * z;

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

也许，你会想你比一般的熊——或一般的程序员——要聪明；也许，你注意到在堆栈和堆上创建对象的方法避免不了对构造函数的调用；也许，你想起了我们最初的目标是为了避免这种对构造函数的调用；也许，你有个办法可以只用一个构造函数来搞掂一切；也许，你的眼前出现了这样一段代码：operator*返回一个“在函数内部定义的静态Rational对象”的引用：

// 写此函数的第三个错误方法
inline const Rational& operator*(const Rational& lhs,
                                 const Rational& rhs)
{
  static Rational result;      // 将要作为引用返回的
                               // 静态对象

  lhs和rhs 相乘，结果放进result；

  return result;
}

这个方法看起来好象有戏，虽然在实际实现上面的伪代码时你会发现，不调用一个Rational构造函数是不可能给出result的正确值的，而避免这样的调用正是我们要谈论的主题。就算你实现了上面的伪代码，但，你再聪明也不能最终挽救这个不幸的设计。

想知道为什么，看看下面这段写得很合理的用户代码：

bool operator==(const Rational& lhs,      // Rationals的operator==
                const Rational& rhs);     //

Rational a, b, c, d;

...

if ((a * b) == (c * d)) {

  处理相等的情况;

} else {

  处理不相等的情况;

}

看出来了吗？((a*b) == (c*d)) 会永远为true，不管a，b，c和d是什么值！

用等价的函数形式重写上面的相等判断语句就很容易明白发生这一可恶行为的原因了：

if (operator==(operator*(a, b), operator*(c, d)))

注意当operator==被调用时，总有两个operator*刚被调用，每个调用返回operator*内部的静态Rational对象的引用。于是，上面的语句实际上是请求operator==对“operator*内部的静态Rational对象的值”和“operator*内部的静态Rational对象的值”进行比较，这样的比较不相等才怪呢！

幸运的话，我以上的说明应该足以说服你：想“在象operator*这样的函数里返回一个引用”实际上是在浪费时间。但我没幼稚到会相信幸运总会光临自己。一些人——你们知道这些人是指谁——此刻会在想，“唔，上面那个方法，如果一个静态变量不够用，也许可以用一个静态数组……”

请就此打住！我们难道还没受够吗？

我不能让自己写一段示例代码来太高这个设计，因为即使只抱有上面这种想法都足以令人感到羞愧。首先，你必须选择一个n，指定数组的大小。如果n太小，就会没地方储存函数返回值，这和我们前面否定的那个“采用单个静态变量的设计”相比没有什么改进。如果n太大，就会降低程序的性能，因为函数第一次被调用时数组中每个对象都要被创建。这会带来n个构造函数和n个析构函数的开销，即使这个函数只被调用一次。如果说"optimization"（最优化）是指提高软件的性能的过程， 那么现在这种做法简直可以称为"pessimization"（最差化）。最后，想想怎么把需要的值放到数组的对象中以及需要多大的开销？在对象间传值的最直接的方法是通过赋值，但赋值的开销又有多大呢？一般来说，它相当于调用一个析构函数（摧毁旧值）再加上调用一个构造函数（拷贝新值）。但我们现在的目标正是为了避免构造和析构的开销啊！面对现实吧：这个方法也绝对不能选用。

所以，写一个必须返回一个新对象的函数的正确方法就是让这个函数返回一个新对象。对于Rational的operator*来说，这意味着要不就是下面的代码（就是最初看到的那段代码），要不就是本质上和它等价的代码：

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

的确，这会导致“operator*的返回值构造和析构时带来的开销”，但归根结底它只是用小的代价换来正确的程序运行行为而已。况且，你所担心的开销还有可能永远不会出现：和所有程序设计语言一样，C++允许编译器的设计者采用一些优化措施来提高所生成的代码的性能，所以，在有些场合，operator*的返回值会被安全地除去（见条款M20）。当编译器采用了这种优化时（当前大部分编译器这么做），程序和以前一样继续工作，只不过是运行速度比你预计的要快而已。

以上讨论可以归结为：当需要在返回引用和返回对象间做决定时，你的职责是选择可以完成正确功能的那个。至于怎么让这个选择所产生的代价尽可能的小，那是编译器的生产商去想的事。

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

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

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)

那么，什么时候该用哪种方法呢？

答案取决于另外两个问题。第一，确实有那么一个值可以作为缺省吗？第二，要用到多少种算法？一般来说，如果可以选择一个合适的缺省值并且只是用到一种算法，就使用缺省参数（参见条款38）。否则，就使用函数重载。

下面是一个最多可以计算五个int的最大值的函数。这个函数使用了——深呼一口气，看清楚啦——std::numeric_limits<int>::min()，作为缺省参数值。等会儿再进一步介绍这个值，这里先给出函数的代码：

int max(int a,
        int b = std::numeric_limits<int>::min(),
        int c = std::numeric_limits<int>::min(),
        int d = std::numeric_limits<int>::min(),
        int e = std::numeric_limits<int>::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<class T>
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<class T>
void printMinimumValue()
{
  cout << std::numeric_limits<T>::min();
}

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

#include <limits.h>

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); }

输入为int的构造函数必须执行错误检查，而拷贝构造函数不需要，所以需要两个不同的函数来实现，这就是重载。还请注意，两个函数都必须对新对象赋一个初值。这会导致在两个构造函数里出现重复代码，所以要写一个“包含有两个构造函数公共代码”的私有成员函数init来解决这个问题。这个方法——在重载函数中调用一个“为重载函数完成某些功能”的公共的底层函数——很值得牢记，因为它经常有用（见条款12）。

条款25: 避免对指针和数字类型重载

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

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

void f(int x);
void f(string *ps);

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

答案是，0是一个int——准确地说，一个字面上的整数常量——所以，“总是”f(int)被调用。这就是问题所在：因为不是所有的人总是希望它这样执行。这是C++世界中特有的一种情况：当人们认为某个调用应该具有多义性时，编译器却不这么干。

如果能想办法用符号名（比如，NULL表示null指针）来解决这类问题就好了，但实现起来比想象的要难得多。

最先想到的应该是声明一个称为NULL的常量，但常量要有类型，NULL的类型应该是什么呢？它要兼容于所有的指针类型，但满足条件的唯一一个类型是void*，而且，要想把void*指针传给某类型的指针，必须要有一个显式的类型转换。这样做不仅很难看，而且乍看不比最初的情况好到哪儿去：

void * const NULL = 0;             // 可能的NULL定义

f(0);                              // 还是调用f(int)
f(static_cast<string*>(NULL));     // 调用f(string*)
f(static_cast<string*>(0));        // 调用f(string*)

不过细想一下，用NULL来表示一个void*常量的方法还是比最初要好一点，因为如果能保证只是用NULL来表示null指针的话，是可以避免歧义的：

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

至少现在已经把一个运行时的错误（对0调用了“错误的”f函数）转移成了一个编译时的错误（传递一个void*给string*参数）。情况稍微有点改善（见条款46），但需要进行类型转换还是令人讨厌。

如果想可耻地退回去求助于欲处理，你会发现它也解决不了问题，因为最明显的办法不外乎：

#define NULL 0

或

#define NULL ((void*) 0)

第一种办法只不过是字面上的0，本质上还是一个整数常量（如果你记得的话，还是最初的问题）；第二种方法则又把你拉回到“传void*指针给某种类型的指针”的麻烦中。

如果对类型转换的规则有研究，你就会知道，C++会认为“从long int 0到null指针的转换”和“从long int到int的转换”一样，没什么不妥的。所以可以利用这一点，将多义性引入到上面那个你可能认为有“int/指针”问题的地方：

#define NULL 0L            // NULL现在是一个long int

void f(int x);
void f(string *p);

f(NULL);                   // 错误!——歧义

然而，当想重载long int和指针时，它又不起作用了：

#define NULL 0L

void f(long int x);        // 这个f现在的参数为long
void f(string *p);

f(NULL);                   // 正确, 调用f(long int)

实际编程中，这比把NULL定义为int可能要安全，但它无非只是在转移问题，而不是消除问题。

这个问题可以消除，但需要使用C++语言最新增加的一个特性：成员函数模板（往往简称为成员模板）。顾名思义，成员函数模板是在类的内部为类生成成员函数的模板。拿上面关于NULL的讨论来说，我们需要一个“对每一个T类型，运作起来都象static_cast<T*>(0)表达式”的对象。即，使NULL成为一个“包含一个隐式类型转换运算符”的类的对象，这个类型转换运算符可以适用于每种可能的指针类型。这就需要很多转换运算符，但它们可以求助于C++从成员模板生成：

// 一个可以产生NULL指针对象的类的第一步设计
class NullClass {
public:
  template<class T>                       // 为所有类型的T
    operator 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*)

这是一个很好的初步设计，但还可以从几方面进行改进。第一，我们实际上只需要一个NullClass对象，所以给这个类一个名字没必要；我们只需要定义一个匿名类并使NULL成为这种类型。第二，既然我们是想让NULL可以转换为任何类型的指针，那就也要能够处理成员指针。这就需要定义第二个成员模板，它的作用是为所有的类C和所有的类型T，将0转换为类型T C::*（指向类 C里类型为T的成员）。（如果你不懂成员指针，或者你从没听说过，或很少用，那也不要紧。成员指针可以称得上是稀有动物，是很少见，也许很多人从来没用过它。对此好奇的人可以参考条款30，那儿对成员指针进行了较详细的讨论。）最后，要防止用户取NULL的地址，因为我们希望NULL的行为并不是象指针那样，而是要象指针的值，而指针的值（如0x453AB002）是没有地址的。

所以，改进后的NULL的定义看起来就象这样：

const                             // 这是一个const对象...
class {
public:
  template<class T>               // 可以转换任何类型
    operator T*() const           // 的null非成员指针
    { return 0; }                 // 

  template<class C, class T>      // 可以转换任何类型
    operator T C::*() const       // 的null成员指针
    { return 0; }

private:
  void operator&() const;         // 不能取其地址
                                  // (见条款27)

} NULL;                           // 名字为NULL

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

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

重要的一点是，以上所有那些产生正确工作的NULL的设计方案，只有在你自己是调用者的时候才有意义。如果你是设计被调用函数的人，写这样一个给别人使用的NULL其实没有多大的用处，因为你不能强迫你的调用者去使用它。例如，即使为你的用户提供了上面开发的那个NULL，你还是不能防止他们这样做：

f(0);                  // 还是调用f(int),
                       // 因为0还是int

它还是和本条款最前面的出现的问题一样。

所以，作为重载函数的设计者，归根结底最基本的一条是，只要有可能，就要避免对一个数字和一个指针类型重载。

条款26: 当心潜在的二义性

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

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

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

class B {
public:
  operator A() const;       // 可以从A转换而来的类B
};

这些类的声明没一点错——他们可以在相同的程序中共存而没一点问题。但是，看看下面，当把这两个类结合起来使用，在一个输入参数为A的函数里实际传进了一个B的对象，这时将会发生什么呢？

void f(const A&);

B b;

f(b);                       // 错误!——二义

一看到对f的调用，编译器就知道它必须产生一个类型A的对象，即使它手上拿着的是一个类型B的对象。有两种都很好的方法来实现（见条款M5）。一种方法是调用类A的构造函数，它以b为参数构造一个新的A的对象。另一种方法是调用类B里自定义的转换运算符，它将b转换成一个A的对象。因为这两个途径都一样可行，编译器拒绝从他们中选择一个。

当然，在没碰上二义的情况下，程序可以使用。这正是潜在的二义所具有的潜伏的危害性。它可以长时期地潜伏在程序里，不被发觉也不活动；一旦某一天某位不知情的程序员真的做了什么具有二义性的操作，混乱就会爆发。这导致有这样一种令人担心的可能：你发布了一个函数库，它可以在二义的情况下被调用，而你却不知道自己正在这么做。

另一种类似的二义的形式源于C++语言的标准转换——甚至没有涉及到类：

void f(int);
void f(char);

double d = 6.02;

f(d);                         // 错误!——二义

d是该转换成int还是char呢？两种转换都可行，所以编译器干脆不去做结论。幸运的是，可以通过显式类型转换来解决这个问题：

f(static_cast<int>(d));       // 正确, 调用f(int)
f(static_cast<char>(d));      // 正确, 调用f(char)

多继承（见条款43）充满了潜在二义性的可能。最常发生的一种情况是当一个派生类从多个基类继承了相同的成员名时：

class Base1 {
public:
  int doIt();
};
class Base2 {
public:
  void doIt();
};

class Derived: public Base1,     // Derived没有声明
               public Base2 {    // 一个叫做doIt的函数
  ...

};

Derived d;

d.doIt();                   // 错误!——二义

当类Derived继承两个具有相同名字的函数时，C++没有认为它有错，此时二义只是潜在的。然而，对doIt的调用迫使编译器面对这个现实，除非显式地通过指明函数所需要的基类来消除二义，函数调用就会出错：

d.Base1::doIt();            // 正确, 调用Base1::doIt

d.Base2::doIt();            // 正确, 调用Base2::doIt

这不会令很多人感到麻烦，但当看到上面的代码没有用到访问权限时，一些本来很安分的人会动起心眼想做些不安分的事：

class Base1 { ... };        // 同上

class Base2 {
private:
  void doIt();              // 此函数现在为private
};                          

class Derived: public Base1, public Base2
{ ... };                    // 同上

Derived d;

int i = d.doIt();           // 错误! — 还是二义!

对doIt的调用还是具有二义性，即使只有Base1中的函数可以被访问。另外，只有Base1::doIt返回的值可以用于初始化一个int这一事实也与之无关——调用还是具有二义性。如果想成功地调用，就必须指明想要的是哪个类的doIt。

C++中有一些最初看起来会觉得很不直观的规定，现在就是这种情况。具体来说，为什么消除“对类成员的引用所产生的二义”时不考虑访问权限呢？有一个非常好的理由，它可以归结为：改变一个类成员的访问权限不应该改变程序的含义。

比如前面那个例子，假设它考虑了访问权限。于是表达式d.doIt()决定调用Base1::doIt，因为Base2的版本不能访问。现在假设Base1的Doit版本由public改为protected，Base2的版本则由private改为public。

转瞬之间，同样的表达式d.doIt()将导致另一个完全不同的函数调用，即使调用代码和被调用函数本身都没有被修改！这很不直观，编译器甚至无法产生一个警告。可见，不是象你当初所想的那样，对多继承的成员的引用要显式地消除二义性是有道理的。

既然写程序和函数库时有这么多不同的情况会产生潜在的二义性，那么，一个好的软件开发者该怎么做呢？最根本的是，一定要时时小心它。想找出所有潜在的二义性的根源几乎是不可能的，特别是当程序员将不同的独立开发的库结合起来使用时（见条款28），但在了解了导致经常产生潜在二义性的那些情况后，你就可以在软件设计和开发中将它出现的可能性降到最低。

条款27: 如果不想使用隐式生成的函数就要显式地禁止它

假设想写一个类模板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);

  ...

};

现在，当用户试图对Array对象执行赋值操作时，编译器会不答应；当你自己无意间在成员或友元函数中调用它时，链接器会嗷嗷大叫。

不要因为这个例子就认为本条款只适用于赋值运算符。不是这样的。它适用于条款45所介绍的每一个编译器自动生成的函数。实际应用中，你会发现赋值和拷贝构造函数具有行为上的相似性（见条款11和16），这意味着几乎任何时候当你想禁止它们其中的一个时，就也要禁止另外一个。

条款28: 划分全局名字空间

全局空间最大的问题在于它本身仅有一个。在大的软件项目中，经常会有不少人把他们定义的名字都放在这个单一的空间中，从而不可避免地导致名字冲突。例如，假设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
                                  // 都没有引入到本空间
  ...                           

}

（有些名字空间没有名字。这种没命名的名字空间一般用于限制名字空间内部元素的可见性。详见条款M31。）

名字空间带来的最大的好处之一在于：潜在的二义不会造成错误（参见条款26）。所以，从多个不同的名字空间引入同一个符号名不会造成冲突（假如确实真的从不使用这个符号的话）。例如，除了名字空间sdm外，假如还要用到下面这个名字空间：

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();

  ...
}

但是，如果全局范围内实际上没有名字冲突，用户就会觉得加修饰符麻烦而多余。幸运的是，还是有办法来让用户选择使用它们或忽略它们。

对于类型名，可以用类型定义（typedef）来显式地去掉空间引用。例如，假设结构s（模拟的名字空间）内有个类型名T，可以这样用typedef来使得T成为S::T的同义词：

typedef sdm::Handle Handle;

对于结构中的每个（静态）对象X，可以提供一个（全局）引用X，并初始化为S::X：

const double& BOOK_VERSION = sdm::BOOK_VERSION;

老实说，如果读了条款47，你就会不喜欢定义一个象BOOK_VERSION这样的非局部静态对象。（你就会用条款47中所介绍的函数来取代这样的对象）

处理函数的方法和处理对象一样，但要注意，即使定义函数的引用是合法的，但代码的维护者会更喜欢你使用函数指针：

sdm::Handle& (* const getHandle)() =      // getHandle是指向sdm::getHandle
  sdm::getHandle;                         // 的const 指针 (见条款21)

注意getHandle是一个常指针。因为你当然不想让你的用户将它指向别的什么东西，而不是sdm::getHandle，对不对？

（如果真想知道怎么定义一个函数的引用，看看下面：

sdm::Handle& (&getHandle)() =      // getHandle是指向
  sdm::getHandle;                  // sdm::getHandle的引用

我个人认为这样的做法也很好，但你可能以前从没见到过。除了初始化的方式外，函数的引用和函数的常指针在行为上完全相同，只是函数指针更易于理解。）

有了上面的类型定义和引用，那些不会遭遇全局名字冲突的用户就会使用没有修饰符的类型和对象名；相反，那些有全局名字冲突的用户就会忽略类型和引用的定义，代之以带修饰符的符号名。还要注意的是，不是所有用户都想使用这种简写名，所以要把类型定义和引用放在一个单独的头文件中，不要把它和（模拟namespace的）结构的定义混在一起。

struct是namespace的很好的近似，但实际上还是相差很远。它在很多方面很欠缺，其中很明显的一点是对运算符的处理。如果运算符被定义为结构的静态成员，它就只能通过函数调用来使用，而不能象常规的运算符所设计的那样，可以通过自然的中缀语法来使用：

// 定义一个模拟名字空间的结构，结构内部包含Widgets的类型
// 和函数。Widgets对象支持operator+进行加法运算
struct widgets {
  class Widget { ... };

  // 参见条款21：为什么返回const
  static 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);        // 合法, 但不是
                                         // "自然"的语法

正因为这些限制，所以一旦编译器支持，就要尽早使用真正的名字空间。