条款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; // 合法, 但
// 有违常规
s << cout; // 同上
这会把别人弄糊涂。所以这些函数不能是成员函数。注意这种情况和前面的不同。这里的目标是自然的调用语法，前面关心的是隐式类型转换。
所以，如果来设计这些函数，就象这样：
istream& operator>>(istream& input, String& string)
{
delete [] string.data;
read from input into some memory, and make string.data
point to it
return input;
}
ostream& operator<<(ostream& output,
const String& string)
{
return output << string.data;
}
注意上面两个函数都要访问String类的data成员，而这个成员是私有（private）的。但我们已经知道，这个函数一定要是非成员函数。这样，就别无选择了：需要访问非公有成员的非成员函数只能是类的友元函数。
本条款得出的结论如下。假设f是想正确声明的函数，C是和它相关的类：
·虚函数必须是成员函数。如果f必须是虚函数，就让它成为C的成员函数。
·operator>>和operator<<决不能是成员函数。如果f是operator>>或operator<<，让f成为非成员函数。如果f还需要访问C的非公有成员，让f成为C的友元函数。
·只有非成员函数对最左边的参数进行类型转换。如果f需要对最左边的参数进行类型转换，让f成为非成员函数。如果f还需要访问C的非公有成员，让f成为C的友元函数。
·其它情况下都声明为成员函数。如果以上情况都不是，让f成为C的成员函数。
