（接上篇）
但是也许你注意到无论是在栈上的还是在堆上的方法，为了从 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 的设计的例子是合理的，至少在单线程的环境中是这样。）
