一旦程序员抓住对象传值的效率隐忧，很多人就会成为狂热的圣战分子，誓要根除传值的罪恶，无论它隐藏多深。他们不屈不挠地追求传引用的纯度，但他们全都犯了一个致命的错误：他们开始传递并不存在的对象的引用。这可不是什么好事。
考虑一个代表有理数的类，包含一个将两个有理数相乘的函数：
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*：