# Item 21: 当你必须返回一个对象时不要试图返回一个引用
作者：Scott Meyers
译者：fatalerror99 (iTePub's Nirvana)
发布：http://blog.csdn.net/fatalerror99/
一旦程序员抓住对象传值的效率隐忧（参见 Item 20），很多人就会成为狂热的圣战分子，誓要根除传值的罪恶，无论它隐藏多深。他们不屈不挠地追求传引用的纯度，但他们全都犯了一个致命的错误：他们开始传递并不存在的对象的引用。这可不是什么好事。
考虑一个代表有理数的类，包含一个将两个有理数相乘的函数：
```
class Rational {
public:
Rational(int numerator = 0, // see Item 24 for why this
int denominator = 1); // ctor isn't declared explicit
...
private:
int n, d; // numerator and denominator
friend
const Rational // see Item 3 for why the
operator*(const Rational& lhs, // return type is const
const Rational& rhs);
};
```
operator\* 的这个版本以传值方式返回它的结果，而且如果你没有担心那个对象的构造和析构的代价，你就是在推卸你的专业职责。如果你不是迫不得已，你不应该为这样的一个对象付出成本。所以问题就在这里：你是迫不得已吗？
哦，如果你能用返回一个引用来作为代替，你就不是迫不得已。但是，请记住一个引用仅仅是一个名字，一个实际存在的对象的名字。无论何时只要你看到一个引用的声明，你应该立刻问自己它是什么东西的另一个名字，因为它必定是某物的另一个名字。在这个 operator\* 的情况下，如果函数返回一个引用，它必须返回某个已存在的而且其中包含两个对象相乘的产物的 Rational 对象的引用。
当然没有什么理由期望这样一个对象在调用 operator\* 之前就存在。也就是说，如果你有
```
Rational a(1, 2); // a = 1/2
Rational b(3, 5); // b = 3/5
Rational c = a * b; // c should be 3/10
```
似乎没有理由期望那里碰巧已经存在一个值为十分之三的有理数。不是这样的，如果 operator\* 返回这样一个数的引用，它必须自己创建那个数字对象。
一个函数创建一个新对象仅有两种方法：在栈上或者在堆上。栈上的生成物通过定义一个局部变量而生成。使用这个策略，你可以用这种方法试写 operator\*：
```
const Rational& operator*(const Rational& lhs, // warning! bad code!
const Rational& rhs)
{
Rational result(lhs.n * rhs.n, lhs.d * rhs.d);
return result;
}
```
你可以立即否决这种方法，因为你的目标是避免调用构造函数，而 result 正像任何其它对象一样必须被构造。一个更严重的问题是这个函数返回一个引向 result 的引用，但是 result 是一个局部对象，而局部对象在函数退出时被销毁。那么，这个 operator\* 的版本不会返回引向一个 Rational 的引用——它返回引向一个前 Rational；一个曾经的 Rational；一个空洞的、恶臭的、腐败的，从前是一个 Rational 但永不再是的尸体的引用，因为它已经被销毁了。任何调用者甚至于没有来得及匆匆看一眼这个函数的返回值就立刻进入了未定义行为的领地。这是事实，任何返回一个引向局部变量的引用的函数都是错误的。（对于任何返回一个指向局部变量的指针的函数同样成立。）
那么，让我们考虑一下在堆上构造一个对象并返回引向它的引用的可能性。基于堆的对象通过使用 new 而开始存在，所以你可以像这样写一个基于堆的 operator\*：
```
const Rational& operator*(const Rational& lhs, // warning! more bad
const Rational& rhs) // code!
{
Rational *result = new Rational(lhs.n * rhs.n, lhs.d * rhs.d);
return *result;
}
```
哦，你还是必须要付出一个构造函数调用的成本，因为通过 new 分配的内存要通过调用一个适当的构造函数进行初始化，但是现在你有另一个问题：谁是删除你用 new 做出来的对象的合适人选？
即使调用者尽职尽责且一心向善，它们也不太可能是用这样的方案来合理地预防泄漏：
```
Rational w, x, y, z;
w = x * y * z; // same as operator*(operator*(x, y), z)
```
这里，在同一个语句中有两个 operator\* 的调用，因此 new 被使用了两次，这两次都需要使用 delete 来销毁。但是 operator\* 的客户没有合理的办法进行那些调用，因为他们没有合理的办法取得隐藏在通过调用 operator\* 返回的引用后面的指针。这是一个早已注定的资源泄漏。
但是也许你注意到无论是在栈上的还是在堆上的方法，为了从 operator\* 返回的每一个 result，我们都不得不容忍一次构造函数的调用。也许你想起我们最初的目标是避免这样的构造函数调用。也许你认为你知道一种方法能避免除一次以外几乎全部的构造函数调用。也许下面这个实现是你做过的，一个基于 operator\* 返回一个引向 static Rational 对象的引用的实现，而这个 static Rational 对象定义在函数内部：
```
const Rational& operator*(const Rational& lhs, // warning! yet more
const Rational& rhs) // bad code!
{
static Rational result; // static object to which a
// reference will be returned
result = ... ; // multiply lhs by rhs and put the
// product inside result
return result;
}
```
就像所有使用了 static 对象的设计一样，这个也会立即引起我们的线程安全（thread-safety）的混乱，但那是它的比较明显的缺点。为了看到它的更深层的缺陷，考虑这个完全合理的客户代码：
```
bool operator==(const Rational& lhs, // an operator==
const Rational& rhs); // for Rationals
Rational a, b, c, d;
...
if ((a * b) == (c * d)) {
do whatever's appropriate when the products are equal;
} else {
do whatever's appropriate when they're not;
}
```
猜猜会怎么样？不管 a，b，c，d 的值是什么，表达式 ((a*b) == (c*d)) 总是等于 true！
如果代码重写为功能完全等价的另一种形式，这一启示就很容易被理解了：
```
if (operator==(operator*(a, b), operator*(c, d)))
```
注意，当 operator== 被调用时，将同时存在两个起作用的对 operator\* 的调用，每一个都将返回引向 operator\* 内部的 static Rational 对象的引用。因此，operator== 将被要求比较 operator\* 内部的 static Rational 对象的值和 operator\* 内部的 static Rational 对象的值。如果它们不是永远相等，那才真的会令人大惊失色了。
这些应该足够让你信服试图从类似 operator\* 这样的函数中返回一个引用纯粹是浪费时间，但是你们中的某些人可能会这样想“好吧，就算一个 static 不够用，也许一个 static 的数组是一个窍门……”
我无法拿出示例代码来肯定这个设计，但我可以概要说明为什么这个想法应该让你羞愧得无地自容。首先，你必须选择一个 n 作为数组的大小。如果 n 太小，你可能会用完存储函数返回值的空间，与刚刚名誉扫地的 single-static 设计相比，在任何一个方面你都不会得到更多的东西。但是如果 n 太大，就会降低你的程序的性能，因为在函数第一次被调用的时候数组中的每一个对象都会被构造。即使这个我们正在讨论的函数仅被调用了一次，也将让你付出 n 个构造函数和 n 个析构函数的成本。如果“优化”是提高软件效率的过程，对于这种东西也只能是“悲观主义”的。最后，考虑你怎样将你所需要的值放入数组的对象中，以及你做这些需要付出什么。在两个对象间移动值的最直接方法就是通过赋值，但是一次赋值将要付出什么？对于很多类型，这就大约相当于调用一次析构函数（销毁原来的值）加上调用一次构造函数（把新值拷贝过去）。但是你的目标是避免付出构造和析构成本！面对的结果就是：这个方法绝对不会成功。（不，用一个 vector 代替数组也不会让事情有多少改进。）
写一个必须返回一个新对象的函数的正确方法就是让那个函数返回一个新对象。对于 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\* 的返回值的构造和析构能被安全地消除。如果编译器利用了这一点（编译器经常这样做），你的程序还是在它假定的方法上继续运行，只是比你期待的要快。
全部的焦点在这里：如果需要在返回一个引用和返回一个对象之间做出决定，你的工作就是让那个选择能提供正确的行为。让你的编译器厂商去绞尽脑汁使那个选择尽可能地廉价。
Things to Remember
* 绝不要返回一个局部栈对象的指针或引用，绝不要返回一个被分配的堆对象的引用，如果存在需要一个以上这样的对象的可能性时，绝不要返回一个局部 static 对象的指针或引用。（Item 4 提供的一个返回一个局部 static 的设计的例子是合理的，至少在单线程的环境中是这样。）
- Preface（前言）
- Introduction（导言）
- Terminology（术语）
- Item 1: 将 C++ 视为 federation of languages（语言联合体）
- Item 2: 用 consts, enums 和 inlines 取代 #defines
- Item 3: 只要可能就用 const
- Item 4: 确保 objects（对象）在使用前被初始化
- Item 5: 了解 C++ 为你偷偷地加上和调用了什么函数
- Item 6: 如果你不想使用 compiler-generated functions（编译器生成函数），就明确拒绝
- Item 7: 在 polymorphic base classes（多态基类）中将 destructors（析构函数）声明为 virtual（虚拟）
- Item 8: 防止因为 exceptions（异常）而离开 destructors（析构函数）
- Item 9: 绝不要在 construction（构造）或 destruction（析构）期间调用 virtual functions（虚拟函数）
- Item 10: 让 assignment operators（赋值运算符）返回一个 reference to *this（引向 *this 的引用）
- Item 11: 在 operator= 中处理 assignment to self（自赋值）
- Item 12: 拷贝一个对象的所有组成部分
- Item 13: 使用对象管理资源
- Item 14: 谨慎考虑资源管理类的拷贝行为
- Item 15: 在资源管理类中准备访问裸资源（raw resources）
- Item 16: 使用相同形式的 new 和 delete
- Item 17: 在一个独立的语句中将 new 出来的对象存入智能指针
- Item 18: 使接口易于正确使用，而难以错误使用
- Item 19: 视类设计为类型设计
- Item 20: 用 pass-by-reference-to-const（传引用给 const）取代 pass-by-value（传值）
- Item 21: 当你必须返回一个对象时不要试图返回一个引用
- Item 22: 将数据成员声明为 private
- Item 23: 用非成员非友元函数取代成员函数
- Item 24: 当类型转换应该用于所有参数时，声明为非成员函数
- Item 25: 考虑支持不抛异常的 swap
- Item 26: 只要有可能就推迟变量定义
- Item 27: 将强制转型减到最少
- Item 28: 避免返回对象内部构件的“句柄”
- Item 29: 争取异常安全（exception-safe）的代码
- Item 30: 理解 inline 化的介入和排除
- Item 31: 最小化文件之间的编译依赖
- Item 32: 确保 public inheritance 模拟 "is-a"
- Item 33: 避免覆盖（hiding）“通过继承得到的名字”
- Item 34: 区分 inheritance of interface（接口继承）和 inheritance of implementation（实现继承）
- Item 35: 考虑可选的 virtual functions（虚拟函数）的替代方法
- Item 36: 绝不要重定义一个 inherited non-virtual function（通过继承得到的非虚拟函数）
- Item 37: 绝不要重定义一个函数的 inherited default parameter value（通过继承得到的缺省参数值）
- Item 38: 通过 composition（复合）模拟 "has-a"（有一个）或 "is-implemented-in-terms-of"（是根据……实现的）
- Item 39: 谨慎使用 private inheritance（私有继承）
- Item 40: 谨慎使用 multiple inheritance（多继承）
- Item 41: 理解 implicit interfaces（隐式接口）和 compile-time polymorphism（编译期多态）
- Item 42: 理解 typename 的两个含义
- Item 43: 了解如何访问 templatized base classes（模板化基类）中的名字
- Item 44: 从 templates（模板）中分离出 parameter-independent（参数无关）的代码
- Item 45: 用 member function templates（成员函数模板） 接受 "all compatible types"（“所有兼容类型”）
- Item 46: 需要 type conversions（类型转换）时在 templates（模板）内定义 non-member functions（非成员函数）
- Item 47: 为类型信息使用 traits classes（特征类）
- Item 48: 感受 template metaprogramming（模板元编程）
- Item 49: 了解 new-handler 的行为
- Item 50: 领会何时替换 new 和 delete 才有意义
- Item 51: 编写 new 和 delete 时要遵守惯例
- Item 52: 如果编写了 placement new，就要编写 placement delete
- 附录 A. 超越 Effective C++
- 附录 B. 第二和第三版之间的 Item 映射