Effective C++ 2e Item19

减小字体

增大字体作者：佚名来源：本站整理发布时间：2009-03-16 19:36:03

条款19: 分清成员函数，非成员函数和友元函数

成员函数和非成员函数最大的区别在于成员函数可以是虚拟的而非成员函数不行。所以，如果有个函数必须进行动态绑定（见条款38），就要采用虚拟函数，而虚拟函数必定是某个类的成员函数。关于这一点就这么简单。如果函数不必是虚拟的，情况就稍微复杂一点。

看下面表示有理数的一个类：

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

private:
...
};

这是一个没有一点用处的类。（用条款18的术语来说，接口的确最小，但远不够完整。）所以，要对它增加加，减，乘等算术操作支持，但是，该用成员函数还是非成员函数，或者，非成员的友元函数来实现呢？

当拿不定主意的时候，用面向对象的方法来考虑！有理数的乘法是和Rational类相联系的，所以，写一个成员函数把这个操作包到类中。

class Rational {
public:

...

const Rational operator*(const Rational& rhs) const;
};

（如果你不明白为什么这个函数以这种方式声明――返回一个const值而取一个const的引用作为它的参数――参考条款21-23。）

现在可以很容易地对有理数进行乘法操作：

Rational oneEighth(1, 8);
Rational oneHalf(1, 2);

Rational result = oneHalf * oneEighth; // 运行良好

result = result * oneEighth; // 运行良好

但不要满足，还要支持混合类型操作，比如，Rational要能和int相乘。但当写下下面的代码时，只有一半工作：

result = oneHalf * 2; // 运行良好

result = 2 * oneHalf; // 出错!

这是一个不好的苗头。记得吗？乘法要满足交换律。

如果用下面的等价函数形式重写上面的两个例子，问题的原因就很明显了：

result = oneHalf.operator*(2); // 运行良好

result = 2.operator*(oneHalf); // 出错!

对象oneHalf是一个包含operator*函数的类的实例，所以编译器调用了那个函数。而整数2没有相应的类，所以没有operator*成员函数。编译器还会去搜索一个可以象下面这样调用的非成员的operator*函数（即，在某个可见的名字空间里的operator*函数或全局的operator*函数）：

result = operator*(2, oneHalf); // 错误!

但没有这样一个参数为int和Rational的非成员operator*函数，所以搜索失败。

再看看那个成功的调用。它的第二参数是整数2，然而Rational::operator*期望的参数却是Rational对象。怎么回事？为什么2在一个地方可以工作而另一个地方不行？

秘密在于隐式类型转换。编译器知道传的值是int而函数需要的是Rational，但它也同时知道调用Rational的构造函数将int转换成一个合适的Rational，所以才有上面成功的调用（见条款M19）。换句话说，编译器处理这个调用时的情形类似下面这样：

const Rational temp(2); // 从2产生一个临时
// Rational对象

result = oneHalf * temp; // 同oneHalf.operator*(temp);

当然，只有所涉及的构造函数没有声明为explicit的情况下才会这样，因为explicit构造函数不能用于隐式转换，这正是explicit的含义。如果Rational象下面这样定义：

class Rational {
public:
explicit Rational(int numerator = 0, // 此构造函数为
int denominator = 1); // explicit
...

const Rational operator*(const Rational& rhs) const;

...

};

那么，下面的语句都不能通过编译：

result = oneHalf * 2; // 错误!
result = 2 * oneHalf; // 错误!

这不会为混合运算提供支持，但至少两条语句的行为一致了。

然而，我们刚才研究的这个类是要设计成可以允许固定类型到Rational的隐式转换的――这就是为什么Rational的构造函数没有声明为explicit的原因。这样，编译器将执行必要的隐式转换使上面result的第一个赋值语句通过编译。实际上，如果需要的话，编译器会对每个函数的每个参数执行这种隐式类型转换。但它只对函数参数表中列出的参数进行转换，决不会对成员函数所在的对象（即，成员函数中的*this指针所对应的对象）进行转换。这就是为什么这个语句可以工作：

result = oneHalf.operator*(2); // converts int -> Rational

而这个语句不行：

result = 2.operator*(oneHalf); // 不会转换
// int -> Rational

第一种情形操作的是列在函数声明中的一个参数，而第二种情形不是。

尽管如此，你可能还是想支持混合型的算术操作，而实现的方法现在应该清楚了：使operator*成为一个非成员函数，从而允许编译器对所有的参数执行隐式类型转换：

class Rational {

... // contains no operator*

};

// 在全局或某一名字空间声明，
// 参见条款M20了解为什么要这么做
const Rational operator*(const Rational& lhs,
const Rational& rhs)
{
return Rational(lhs.numerator() * rhs.numerator(),
lhs.denominator() * rhs.denominator());
}

Rational oneFourth(1, 4);
Rational result;

result = oneFourth * 2; // 工作良好
result = 2 * oneFourth; // 万岁, 它也工作了!

这当然是一个完美的结局，但还有一个担心：operator*应该成为Rational类的友元吗？

这种情况下，答案是不必要。因为operator*可以完全通过类的公有（public）接口来实现。上面的代码就是这么做的。只要能避免使用友元函数就要避免，因为，和现实生活中差不多，友元（朋友）带来的麻烦往往比它（他/她）对你的帮助多。

然而，很多情况下，不是成员的函数从概念上说也可能是类接口的一部分，它们需要访问类的非公有成员的情况也不少。

让我们回头再来看看本书那个主要的例子，String类。如果想重载operator>>和operator<<来读写String对象，你会很快发现它们不能是成员函数。如果是成员函数的话，调用它们时就必须把String对象放在它们的左边：

// 一个不正确地将operator>>和
// operator<<作为成员函数的类
class String {
public:
String(const char *value);

...

istream& operator>>(istream& input);
ostream& operator<<(ostream& output);

private:
char *data;
};

String s;

s >> cin; // 合法, 但
// 有违常规