C++ code review中的检查项（2）

四。返回值问题

1。必须返回一个对象时不要试图返回一个引用

example:

看一个表示有理数的类，其中包含一个友元函数，用于两个有理数相乘：

class rational {
public:
  rational(int numerator = 0, int denominator = 1);

  ...

private:
  int n, d;              // 分子和分母

friend
  const rational                     
    operator*(const rational& lhs,    // 返回值是const
              const rational& rhs)    
};

inline const rational operator*(const rational& lhs,
                                const rational& rhs)
{
  return rational(lhs.n * rhs.n, lhs.d * rhs.d);
}

一个函数只能有两种方法创建一个新对象：在堆栈里或在堆上。在堆栈里创建对象时伴随着一个局部变量的定义，采用这种方法，就要这样写operator*：

// 写此函数的第一个错误方法
inline const rational& operator*(const rational& lhs,
                                 const rational& rhs)
{
  rational result(lhs.n * rhs.n, lhs.d * rhs.d);
  return result;
}

这个方法应该被否决，因为我们的目标是避免构造函数被调用，但result必须要象其它对象一样被构造。另外，这个函数还有另外一个更严重的问题，它返回的是一个局部对象的引用。

那么，在堆上创建一个对象然后返回它的引用呢？基于堆的对象是通过使用new产生的，所以应该这样写operator*：

// 写此函数的第二个错误方法
inline const rational& operator*(const rational& lhs,
                                 const rational& rhs)
{
  rational *result =
    new rational(lhs.n * rhs.n, lhs.d * rhs.d);
  return *result;
}

首先，你还是得负担构造函数调用的开销，因为new分配的内存是通过调用一个适当的构造函数来初始化的。另外，还有一个问题：谁将负责用delete来删除掉new生成的对象呢？
也许，你会想你比一般的熊——或一般的程序员——要聪明；也许，你注意到在堆栈和堆上创建对象的方法避免不了对构造函数的调用；也许，你想起了我们最初的目标是为了避免这种对构造函数的调用；也许，你有个办法可以只用一个构造函数来搞掂一切；也许，你的眼前出现了这样一段代码：operator*返回一个“在函数内部定义的静态rational对象”的引用：

// 写此函数的第三个错误方法
inline const rational& operator*(const rational& lhs,
                                 const rational& rhs)
{
  static rational result;      // 将要作为引用返回的
                               // 静态对象

  lhs和rhs 相乘，结果放进result；

  return result;
}

这个方法看起来好象有戏，虽然在实际实现上面的伪代码时你会发现，不调用一个rational构造函数是不可能给出result的正确值的，而避免这样的调用正是我们要谈论的主题。就算你实现了上面的伪代码，但，你再聪明也不能最终挽救这个不幸的设计。

想知道为什么，看看下面这段写得很合理的用户代码：

bool operator==(const rational& lhs,      // rationals的operator==
                const rational& rhs);     //

rational a, b, c, d;

...

if ((a * b) == (c * d)) {

  处理相等的情况;

} else {

  处理不相等的情况;

}

看出来了吗？((a*b) == (c*d)) 会永远为true，不管a，b，c和d是什么值！

用等价的函数形式重写上面的相等判断语句就很容易明白发生这一可恶行为的原因了：

if (operator==(operator*(a, b), operator*(c, d)))

注意当operator==被调用时，总有两个operator*刚被调用，每个调用返回operator*内部的静态rational对象的引用。于是，上面的语句实际上是请求operator==对“operator*内部的静态rational对象的值”和“operator*内部的静态rational对象的值”进行比较，这样的比较不相等才怪呢！

以上讨论可以归结为：当需要在返回引用和返回对象间做决定时，你的职责是选择可以完成正确功能的那个。至于怎么让这个选择所产生的代价尽可能的小，那是编译器的生产商去想的事。

2。不要返回内部数据成员变量的指针或引用

example:

假设b是一个const string对象：

class string {
public:
  string(const char *value);       
  ~string();                       

  operator char *() const;          // 转换string -> char*;
                                   
  ...

private:
  char *data;
};

const string b("hello world");      // b是一个const对象

既然b为const，最好的情况当然就是无论现在还是以后，b的值总是"hello world"。这就寄希望于别的程序员能以合理的方式使用b了。特别是，千万别有什么人象下面这样残忍地将b强制转换掉const：

string& alsob =              // 使得alsob成为b的另一个名字，
  const_cast<string&>(b);    // 但不具有const属性

然而，即使没有人做这种残忍的事，就能保证b永远不会改变吗？看看下面的情形：

char *str = b;               // 调用b.operator char*()

strcpy(str, "hi mom");       // 修改str指向的值

b的值现在还是"hello world"吗？或者，它是否已经变成了对母亲的问候语？答案完全取决于string::operator char*的实现。

3。当成员变量的访问级比成员函数低的时候，成员函数的返回值不能指向成员的非const指针或引用

example:

class Address { ... };           // 某人居住在此

class person {
public:
  Address& personaddress() { return address; }
  ...

private:
  Address address;
  ...
};

成员函数personaddress为调用者提供的是person对象中所包含的address对象，但是，也许是出于效率上的考虑，返回结果采用的是引用，而不是值。遗憾的是，这个成员函数的做法有违当初将person::address声明为private的初衷：

person scott(...);             // 为简化省略了参数

Address& addr =                // 假设addr为全局变量
  scott.personaddress();

现在，全局对象addr成为了scott.address的另一个名字，利用它可以随意读写scott.address。实际上，scott.address不再为private，而是public，访问级提升的根源在于成员函数personaddress。当然，本例中给出的address 的访问级是private，如果是protected，情况完全一样。

不仅仅是引用，指针也会产生以上问题。

4。千万不要返回局部对象的引用，也不要返回函数内部用new初始化的对象的引用

example:

先看第一种情况：返回一个局部对象的引用。它的问题在于，局部对象 ----- 顾名思义 ---- 仅仅是局部的。也就是说，局部对象是在被定义时创建，在离开生命空间时被销毁的。所谓生命空间，是指它们所在的函数体。当函数返回时，程序的控制离开了这个空间，所以函数内部所有的局部对象被自动销毁。因此，如果返回局部对象的引用，那个局部对象其实已经在函数调用者使用它之前被销毁了。

当想提高程序的效率而使函数的结果通过引用而不是值返回时，这个问题就会出现。下面的例子目的在于详细说明什么时候该返回引用，什么时候不该：

class rational {          // 一个有理数类
public:
  rational(int numerator = 0, int denominator = 1);
  ~rational();

  ...

private:
  int n, d;               // 分子和分母

// 注意operator* (不正确地)返回了一个引用
friend const rational& operator*(const rational& lhs,
                                 const rational& rhs);
};

// operator*不正确的实现
inline const rational& operator*(const rational& lhs,
                                 const rational& rhs)
{
  rational result(lhs.n * rhs.n, lhs.d * rhs.d);
  return result;
}

这里，局部对象result在刚进入operator*函数体时就被创建。但是，所有的局部对象在离开它们所在的空间时都要被自动销毁。具体到这个例子来说，result是在执行return语句后离开它所在的空间的。所以，如果这样写：

rational two = 2;

rational four = two * two;         // 同operator*(two, two)

函数调用时将发生如下事件：

1. 局部对象result被创建。
2. 初始化一个引用，使之成为result的另一个名字；这个引用先放在另一边，留做operator*的返回值。
3. 局部对象result被销毁，它在堆栈所占的空间可被本程序其它部分或其他程序使用。
4. 用步骤2中的引用初始化对象four。

一切都很正常，直到第4步才产生了错误，借用高科技界的话来说，产生了"一个巨大的错误"。因为，第2步被初始化的引用在第3步结束时指向的不再是一个有效的对象，所以对象four的初始化结果完全是不可确定的。

教训很明显：别返回一个局部对象的引用。

"那好，"你可能会说，"问题不就在于要使用的对象离开它所在的空间太早吗？我能解决。不要使用局部对象，可以用new来解决这个问题。"象下面这样：

// operator*的另一个不正确的实现
inline const rational& operator*(const rational& lhs,
                                 const rational& rhs)
{
  // create a new object on the heap
  rational *result =
    new rational(lhs.n * rhs.n, lhs.d * rhs.d);

  // return it
  return *result;
}

这个方法的确避免了上面例子中的问题，但却引发了新的难题。大家都知道，为了在程序中避免内存泄漏，就必须确保对每个用new产生的指针调用delete，但是，这里的问题是，对于这个函数中使用的new，谁来进行对应的delete调用呢？

显然，operator*的调用者应该负责调用delete。真的显然吗？遗憾的是，即使你白纸黑字将它写成规定，也无法解决问题。之所以做出这么悲观的判断，是基于两条理由：

第一，大家都知道，程序员这类人是很马虎的。这不是指你马虎或我马虎，而是指，没有哪个程序员不和某个有这类习性的人打交道。想让这样的程序员记住无论何时调用operator*后必须得到结果的指针然后调用delete，这样的几率有多大呢？也是说，他们必须这样使用operator*：

const rational& four = two * two;      // 得到废弃的指针；
                                       // 将它存在一个引用中
...

delete &four;                          // 得到指针并删除

这样的几率将会小得不能再小。记住，只要有哪怕一个operator*的调用者忘了这条规则，就会造成内存泄漏。

返回废弃的指针还有另外一个更严重的问题，即使是最尽责的程序员也难以避免。因为常常有这种情况，operator*的结果只是临时用于中间值，它的存在只是为了计算一个更大的表达式。例如：

rational one(1), two(2), three(3), four(4);
rational product;

product = one * two * three * four;

product的计算表达式需要三个单独的operator*调用，以相应的函数形式重写这个表达式会看得更清楚：

product = operator*(operator*(operator*(one, two), three), four);

是的，每个operator*调用所返回的对象都要被删除，但在这里无法调用delete，因为没有哪个返回对象被保存下来。

解决这一难题的唯一方案是叫用户这样写代码：

const rational& temp1 = one * two;
const rational& temp2 = temp1 * three;
const rational& temp3 = temp2 * four;

delete &temp1;
delete &temp2;
delete &temp3;

果真如此的话，你所能期待的最好结果是人们将不再理睬你。更现实一点，你将会在指责声中度日，或者可能会被判处10年苦力去写威化饼干机或烤面包机的微代码。

所以要记住你的教训：写一个返回废弃指针的函数无异于坐等内存泄漏的来临。

另外，假如你认为自己想出了什么办法可以避免"返回局部对象的引用"所带来的不确定行为，以及"返回堆(heap)上分配的对象的引用"所带来的内存泄漏，那么，看看为什么返回局部静态(static)对象的引用也会工作不正常。看了之后，也许会帮助你避免头痛医脚所带来的麻烦。

5。不要省略返回值的类型

example:

C语言中，凡不加类型说明的函数，一律自动按整型处理。这样做不会有什么好处，却容易被误解为void类型。
C++语言有很严格的类型安全检查，不允许上述情况发生。由于C++程序可以调用C函数，为了避免混乱，规定任
何C++/ C函数都必须有类型。如果函数没有返回值，那么应声明为void类型。