若所有参数皆需类型转换，请为此采用non-member函数——条款24_若所有参数皆需类型转换,请为此采用non-member函数-优快云博客

本文链接：https://blog.youkuaiyun.com/yj_android_develop/article/details/105460535

令classes支持隐式类型转换通常是个糟糕的注意。当然这条规则有其例外，最常见的例外是在建立数值类型时。假设你设计一个class用来表现有理数，允许整数“隐式转换”为有理数似乎颇为合理。的确，它并不比C++内置从int至double的转换来得不合理，而还比C++内置从double至int的转换来得合理些。假设你这样开始你的Rational class：

class Rational {
public:
	Rational(int numberator = 0, int denominator = 1);  // 构造函数刻意不为explicit，允许int-to-Rational隐式转换。
	int numberator() const;  // 分子（numberator）和分母（denominator）的
	int denominator() const;  // 访问函数（accessors）——见条款22
private:
	...
};

你想支持算术运算诸如加法、乘法等等，但你不确定是否该由member函数、non-member函数，或可能的话由non-member friend 函数来实现它们。你的直觉告诉你，当你犹豫就该保持面向对象精神。你知道有理数相乘和Rational class有关，因此很自然地似乎该在Rational class内为有理数实现operator*。条款23曾经反直觉地主张，将函数放进相关class内有时会与面向对象守则发生矛盾，但让我们先把那放在一旁，先研究一下将operator*写成Rational成员函数的写法：

class Rational {
public:
	...
	const Rational operator* (const Rational& rhs) const;
};

（如果你不确定为什么函数被声明为这种形式，也就是为什么它返回一个const by-value结果但接受一个reference-to-const实参，请参考条款3,20,和21。）

这个设计使你能够将两个有理数以最轻松自在的方式相乘：

Rational oneEighth(1, 8);
Rational oneHalf(1, 2);
Rational result = oneHalf * oneEighth;  // 很好
result = result * oneEighth;  // 很好

但你还不满足。你希望支持混合式运算，也就是拿Rationals和......嗯......例如ints相乘。毕竟很少有什么东西会比两个数值相乘更自然了——即使是两个不同类型的数值。

然而当你尝试混合式算术，你发现只有一半行得通：

result = oneHalf * 2;  // 很好
result = 2 * oneHalf;  // 错误！

乘法应该满足交换律，不是吗? 当你以对应的函数形式重写上述两个式子，问题所在便一目了然了：

result = oneHalf.operator*(2);  // 很好
result = 2.operator*(oneHalf);  // 错误！

oneHalf是一个内含operator*函数的class对象，所以编译器调用该函数。然而整数2并没有相应的class，也就没有operator*成员函数。编译器也会尝试寻找可被以下这般调用的non-member operator*（也就是在命名空间内或在global作用域内）：

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

但本例并不存在这样一个接受int和Rational作为参数的non-member operator*，因此查找失败。

再次看看先前成功的那个调用。注意其第二个参数是整数2，但Rational::operator*需要的实参却是个Rational对象。这里发生了什么事？为什么2在这里可被接受，在另一个调用中却不被接受？

因为这里发生了所谓隐式类型转换（implicit type conversion）。编译器知道你正在传递一个int，而函数需要的是Rational；但它也知道只要调用Rational构造函数并赋予你所提供的int，就可以变出一个适当的Rational来。于是它就那样做了。换句话说此一调用动作在编译器眼中有点像这样：

const Rational temp(2);   // 根据2建立一个暂时性的Rational对象。
result = oneHalf * temp;  // 等同于oneHalf.operator*(temp);

当然，只因为涉及non-explicit构造函数，编译器才会这样做。如果Rational构造函数是explicit，以下语句没有一个可通过编译：

result = oneHalf * 2;  // 错误！(在explicit构造函数的情况下)无法将2转换为一个Rational。
result = 2 * oneHalf;  // 一样的错误，一样的问题。

不过这就很难让Rational class支持混合式算术运算了。然而你的目标不仅是一致性，也要支持混合式算术运算，也就是希望有个设计能让以上语句通过编译。这把我们带回到上述两个语句，为什么即使Rational构造函数不是explicit，仍然只有一个可通过编译，另一个不可以：

result = oneHalf * 2;  // 没问题(在non-explicit构造函数的情况下)。
result = 2 * oneHalf;  // 错误！(甚至在non-explicit构造函数的情况下)。

结论是，只有当参数被列于参数列（parameter list）内，这个参数才说隐式类型转换的合格参与者。地位相当于“被调用之成员函数所隶属的那个对象”——即this对象的那个隐喻参数，绝不是隐式转换的合格参与者。

然而你一定也会想要支持混合式算术运算。则可以让operator*成为一个non-member函数，允许编译器在每一个实参身上执行隐式类型转换：

class Rational {
public:
	...
};

const Rational operator* (const Rational& lhs, const Rational& rhs) 
{
	return Rational(lhs.numberator() * rhs.numberator(), lhs.denominator() * rhs.denominator());
};

Rational oneFourth(1, 4);
Rational result;
result = oneFourth * 2;  // 没问题
result = 2 * oneFourth;  // 通过编译了！

这当然是个好的结局，不过operator*是否应该成为Rational class的一个friend函数呢？

就本例而言答案是否定的，因为operator*可以完全由Rational的public接口完成任务，上面代码已表明此做法。这导出一个重要的观察：member函数的反面是non-member函数，不是friend函数。无论何时如果你可以避免friend函数就该避免，因为就像真实世界一样，朋友带来的麻烦往往多过其价值。当然有时候friend尤其正当性，但这个事实依然存在：不能够只因函数不该成为member，就自动让它成为friend。

本条款内含真理，但却不是全部的真理。当你从Object-Oriented C++跨进Template C++（见条款1）并让Rational成为一个class template而非class，又有一些需要考虑的新争议、新解法、以及一些令人惊讶的设计牵连。这些争议、解法和设计牵连形成了条款46.