它只是一个很简单的道理，真的，相信我。
先看第一种情况：返回一个局部对象的引用。它的问题在于，局部对象 —– 顾名思义 —- 仅仅是局部的。也就是说，局部对象是在被定义时创建，在离开生命空间时被销毁的。所谓生命空间，是指它们所在的函数体。当函数返回时，程序的控制离开了这个空间，所以函数内部所有的局部对象被自动销毁。因此，如果返回局部对象的引用，那个局部对象其实已经在函数调用者使用它之前被销毁了。
当想提高程序的效率而使函数的结果通过引用而不是值返回时，这个问题就会出现。下面的例子和必须返回一个对象时不要试图返回一个引用中的一样，其目的在于详细说明什么时候该返回引用，什么时候不该：
C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
classrational{ // 一个有理数类
public:
rational(intnumerator=0,intdenominator=1);
~rational();
...
private:
intn,d; // 分子和分母
// 注意operator* (不正确地)返回了一个引用
friendconstrational&operator*(constrational&lhs,
constrational&rhs);
};
// operator*不正确的实现
inlineconstrational&operator*(constrational&lhs,
constrational&rhs)
{
rationalresult(lhs.n*rhs.n,lhs.d*rhs.d);
returnresult;
}
这里，局部对象result在刚进入operator*函数体时就被创建。但是，所有的局部对象在离开它们所在的空间时都要被自动销毁。具体到这个例子来说，result是在执行return语句后离开它所在的空间的。所以，如果这样写：
C++
1
2
3
rationaltwo=2;
rationalfour=two*two; // 同operator*(two, two)
函数调用时将发生如下事件：
1. 局部对象result被创建。
2. 初始化一个引用，使之成为result的另一个名字；这个引用先放在另一边，留做operator*的返回值。
3. 局部对象result被销毁，它在堆栈所占的空间可被本程序其它部分或其他程序使用。
4. 用步骤2中的引用初始化对象four。
一切都很正常，直到第4步才产生了错误，借用高科技界的话来说，产生了”一个巨大的错误”。因为，第2步被初始化的引用在第3步结束时指向的不再是一个有效的对象，所以对象four的初始化结果完全是不可确定的。
教训很明显：别返回一个局部对象的引用。
“那好，”你可能会说，”问题不就在于要使用的对象离开它所在的空间太早吗？我能解决。不要使用局部对象，可以用new来解决这个问题。”象下面这样：
C++
1
2
3
4
5
6
7
8
9
10
11
// operator*的另一个不正确的实现
inlineconstrational&operator*(constrational&lhs,
constrational&rhs)
{
// create a new object on the heap
rational*result=
newrational(lhs.n*rhs.n,lhs.d*rhs.d);
// return it
return*result;
}
这个方法的确避免了上面例子中的问题，但却引发了新的难题。大家都知道，为了在程序中避免内存泄漏，就必须确保对每个用new产生的指针调用delete，但是，这里的问题是，对于这个函数中使用的new，谁来进行对应的delete调用呢？
显然，operator*的调用者应该负责调用delete。真的显然吗？遗憾的是，即使你白纸黑字将它写成规定，也无法解决问题。之所以做出这么悲观的判断，是基于两条理由：
第一，大家都知道，程序员这类人是很马虎的。这不是指你马虎或我马虎，而是指，没有哪个程序员不和某个有这类习性的人打交道。想让这样的程序员记住无论何时调用operator*后必须得到结果的指针然后调用delete，这样的几率有多大呢？也是说，他们必须这样使用operator*：
C++
1
2
3
4
5
constrational&four=two*two; // 得到废弃的指针；
// 将它存在一个引用中
...
delete&four; // 得到指针并删除
这样的几率将会小得不能再小。记住，只要有哪怕一个operator*的调用者忘了这条规则，就会造成内存泄漏。
返回废弃的指针还有另外一个更严重的问题，即使是最尽责的程序员也难以避免。因为常常有这种情况，operator*的结果只是临时用于中间值，它的存在只是为了计算一个更大的表达式。例如：
C++
1
2
3
4
rationalone(1),two(2),three(3),four(4);
rationalproduct;
product=one*two*three*four;
product的计算表达式需要三个单独的operator*调用，以相应的函数形式重写这个表达式会看得更清楚：
C++
1
product=operator*(operator*(operator*(one,two),three),four);
是的，每个operator*调用所返回的对象都要被删除，但在这里无法调用delete，因为没有哪个返回对象被保存下来。
解决这一难题的唯一方案是叫用户这样写代码：
C++
1
2
3
4
5
6
7
constrational&temp1=one*two;
constrational&temp2=temp1*three;
constrational&temp3=temp2*four;
delete&temp1;
delete&temp2;
delete&temp3;
果真如此的话，你所能期待的最好结果是人们将不再理睬你。更现实一点，你将会在指责声中度日，或者可能会被判处10年苦力去写威化饼干机或烤面包机的微代码。
所以要记住你的教训：写一个返回废弃指针的函数无异于坐等内存泄漏的来临。
另外，假如你认为自己想出了什么办法可以避免”返回局部对象的引用”所带来的不确定行为，以及”返回堆(heap)上分配的对象的引用”所带来的内存泄漏，那么，请转到必须返回一个对象时不要试图返回一个引用，看看为什么返回局部静态(static)对象的引用也会工作不正常。看了之后，也许会帮助你避免头痛医脚所带来的麻烦。
相关文章:必须返回一个对象时不要试图返回一个引用据说爱因斯坦曾提出过这样的建议：尽可能地让事情简单，但不要过于简单。在c++语言中相似的说法应该是：尽可能地使程序高效，但不要过于高效。...
“new”和“malloc()”的不同点“malloc()”是个函数，接受(字节)数目作为参数；它返回一个指向未初始化空间的 void * 指针。“new”是个运算符，接受一个类型以及一套该类型的初始值(可选)作为参数；它返回一个指向已被初始化(可选)的该类型的对象的指针。当你想为带有非平凡初始化语义(non-trivial initialization semantics)的用户自定义类型分配空间时，这两者的区别是很明显的。...
为什么C++ 有指针也有引用C++ 的指针继承于 C，若要移除指针，势必造成严重的兼容性问题。引用有几方面的用处，但我在 C++ 中引入它的主要目的是为了支持运算符重载。例如：...
应该使用按值传递还是按引用传递这取决于你到底想达到什么目的： 如果你想改变被传递的对象，那就按引用传递或者使用指针；例如 void f(X&); 或者 void f(X*); 如果你并不想改变被传递的对象，但该对象很大，那就按常量引用传递；例如 void f(const X&);...
写operator new和operator delete时要遵循常规但事情也不是那么简单。因为operator new实际上会不只一次地尝试着去分配内存，它要在每次失败后调用出错处理函数，还期望出错处理函数能想办法释放别处的内存。只有在指向出错处理函数的指针为空的情况下，operator new才抛出异常。...
避免隐藏标准形式的new因为内部范围声明的名称会隐藏掉外部范围的相同的名称，所以对于分别在类的内部 和全局声明的两个相同名字的函数f来说，类的成员函数会隐藏掉全局函数：...
如果写了operator new就要同时写operator delete让我们回过头去看看这样一个基本问题：为什么有必要写自己的operator new和operator delete？ 答案通常是：为了效率。缺省的operator new和operator delete具有非常好的通用性，它的这种灵活性也使得在某些特定的场合下，可以进一步改善它的性能。尤其在那些需要动态分配大量的但很小的对象的应用程序里，情况更是如此。...
让operator=返回*this的引用c++的设计者bjarne stroustrup下了很大的功夫想使用户自定义类型尽可能地和固定类型的工作方式相似。这就是为什么你可以重载运算符，写类型转换函数，控制赋值和拷贝构造函数，等等。他做了这么多努力，那你最少也该继续做下去。...
尽量用“传引用”而不用“传值”函数参数的传递在设计时，尽可能的选择”传引用“，不要用“传值”的方式，有两个好处：1.速度快2.可以将修改后的值带回...
避免：其返回值是指向成员的非const指针或引用，但成员的访问级比这个函数要低使一个成员为private或protected的原因是想限制对它的访问，对吗？劳累的编译器要费九牛二虎之力来确保你设置的访问限制不被破坏，对不对？所以，写个函数来让用户随意地访问受限的成员没多大意义，对不对？如果你确实认为有意义，那么请反复阅读本段，直到你不这样认为为止。...