首先函数参数作为引用来替代值传递会提高效率这是必然的,那么函数的返回值可以是引用吗?先看一个代表有理数的类,包含一个将两个有理数相乘的函数:
class Rational {
public:
Rational(int numerator = 0,
int denominator = 1);
...
private:
int n, d;
friend
const Rational
operator*(const Rational& lhs,
const Rational& rhs);
};
operator*的这个版本以传值方式返回它的结果,而且如果你没有担心那个对象的构造和析构的代价,那么你就是在推卸你的专业职责,如果是迫不得已,你不应该这样的一个对象付出成本,所以问题就在这里:这里用值传递是迫不得已吗?
如果你能用返回一个引用来替代,你就是迫不得已,但是,引用仅仅是一个名字,一个实际存在对象的名字。无论何时只要你看到一个引用的申明,就应该立刻追问他是一个什么东西的,因为它必定是某物的另一个名字。在这个operation*的情况下,如果一个函数返回一个引用,它必须返回已存在的而且其中包含两个对象相乘的产物的Rational对象的引用。
当然没有什么理由期望这样一个对象在调用oprtation*之前就存在,也就是说:
Rational a(1, 2); // a = 1/2
Rational b(3, 5); // b = 3/5
Rational c = a * b; // c should be 3/10
似乎没有理由那里碰巧已经存在一个值为十分之三的有理数,不是这样的,如果operation*返回这样一个数的引用,它必须自己创建那个数字对象。
一个函数创建一个对象仅有两种方法:在栈上或者在堆上。栈上的生成物通过定义一个局部变量而生成,如果是这样,那个代码该如下表示:
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是一个局部对象,而局部对象在函数退出时被销毁。那么,这个operation*的版本不会返回一个引向Rational的引用,它返回的一个前Rational;当然了这个Rational已经被销毁了。任何调用者甚至与没有来的及看一眼这个函数的返回值就立刻进入了未定义的行为,这是事实,任何返回一个引向局部变量的引用的函数都是错误的。(对于任何返回一个指向局部变量的指针的函数同样成立)。
那么如果是在堆上构造一个对象并返回它的引用的可能性呢,基于堆的对象通过使用new而开始存在,所以你可以像这样写一个基于堆的operation*:
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)
这里,在同一个语句中有两个operation*的调用,因此被new了两次,这两次都需要使用delete来销毁。但是operation*的客户没有合理的办法进行那些调用,因为他们没有办法合理的办法取得隐藏在通过operation*返回的引用后面的指针,这是一个早已注定的资源泄露
但是也许你注意到无论是栈上还是堆上的方法,为了从operation*返回一个result,都不得不进行一个构造函数的调用。也许你想到了我们最初的目标是避免这样的构造函数的调用。也许你认为你知道一种方法能避免一个以外几乎全部的构造函数调用。也许下面这个实现你会见过,一个基于operation*返回一个引向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对象的设计一样,这个也会立即引起我们的线程安全的混乱,但那只是它比较明显的缺点,为了看到更深层次的缺陷,考虑这个完全合理的代码:
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的值是什么,表达式 ((ab) == (cd)) 总是等于 true!
如果代码重写为功能完全等价于另一种行驶,这就容易被理解了:
if (operator==(operator*(a, b), operator*(c, d)))
注意当operation==被调用的时候,将同时存在两个起作用的operation*的调用,每一个都引向operation*内部的static Rational对象的引用。因此,operation==将被要求比较内部的static Rational对象的值和operation*内部的static Rational对象的值,如果他们不是永远相等,那才会令人大惊失色。
这些应该足够让你信视图从类似operation*这样的函数中返回一个引用纯粹是浪费时间,但是有人可能回想,就算一个static不够用,也许一个static数组是一个窍门...
我无法拿出示例代码来肯定这个设计,但我可以概要说明为什么这个想法应该是不靠谱的。首先你需要选择一个n作为数组的大小,如果n太大,你可能会用完存储函数返回值的控件,与刚刚名誉扫地的single-static设计相比,在任何一个方面你都不会得到更多东西,但是如果n太大,就会降低你程序的性能,因为在函数第一次被调用的时候数组中的每一个对象都会被构造。即使这个我们正在讨论的函数仅被调用一次,也将付出n个构造函数和n个析构函数的成本。如果“优化”是提高软件效率的过程,对于这种东西只能是“悲观主义"的。最后,考虑你怎样将你所需要的值放入数组的对象中,以及你做这些需要付出什么。在两个对象简移动值的最直接的方法就是通过赋值,但是一次赋值将要付出什么?对于很多类型,这就约等于调用一次析构函数(销毁原来的值)加上调用一次构造函数(把新值拷贝过去)。但是你的目标是避免付出构造和析构成本!这还是最基本的开销,讲道理你还需要用算法来匹配你修改的是数组里的那个值,再去替换新值!面对结果就是:这个方法绝对不会成功。
写一个必须返回一个新对象的函数正确的方法就是让那个函数返回一个对象,对于Rational的operation*,这就意味着下面这些代码或者本质上与其相当某些东西:
inline const Rational operator*(const Rational& lhs, const Rational& rhs)
{
return Rational(lhs.n * rhs.n, lhs.d * rhs.d);
}
当然,你可能付出了构造和析构operation*返回的成本,但从长远看,这只是为正确行为付出的很小的代价。除此之外,这种令你感到恐怖的账单也许永远不会到达,就像所有的程序设计语言,c++允许编译器实现者在不改变生成代码的可观察行为的条件下使用优化类提升它的性能,在某些条件下会产生如下的结果:operation*的返回值的构造和析构能被安全地消除。如果编译器利用这一点(编译器经常这样做),你的程序还是在它假定的方法上继续运行,只是比你期望的要快。
全部的焦掉在这里:如果需要在返回一个引用和返回一个对象之间做出决定,你的工作就是让那个选择能提供正确的行为。
总结:
绝不要返回一个局部栈对象的引用或指针,绝不要返回一个被分配的堆对象的引用,如果存在需要一个以上这样的对象的可能性绝不要返回一个局部static对象的指针或引用。