作者在导读中提过,令class支持隐式类型转换通常是个糟糕的主意。当然这条规则有其例外,最常见的例外是在建立数值类型时。假设你设计一个class用来表现有理数,允许整数“隐式转换”为有理数似乎颇为合理。的确,它并不比C++内置从int至double的转换来得不合理,而还比C++内置从double至int的转换来得合理些。假设你这样开始你的Rational class:
class Rational
{
public:// 构造函数刻意不为explicit,允许int-to-Rational隐式转换Rational(int numerator = 0, int denominator = 1);int numerator() const; // 分子(numerator)和分母(denominator)的访问函数(accessor)——见条款22int denominator() const;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 oneEight(1, 8);
Rational oneHalf(1, 2);
Rational result = oneHalf * oneEight; // 很好
result = result * oneEight; // 很好
但你还不满足。你希望支持混合式运算,也就是拿Rational和例如int相乘。毕竟很少有什么东西会比两个数值相乘更自然的了——即使是两个不同类型的数值。
然而当你尝试混合式算术,你发现只有一半行得通:
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对象——的那个隐喻参数,绝不是隐式转换的合格参与者(即oneHalf的operator*只有一个参数,它有一个隐喻参数,就是oneHalf对象自己,它自己是不能从2转换为Rational对象的,意思就是第一个参数是int时不能转换为Rational对象)。这就是为什么上述第一次调用可通过编译,第二次调用则否,因为第一次调用伴随一个放在参数列内的参数,第二次调用则否。
然而你一定也会想要支持混合式算术运算。可行之道终于拨云见日:让operator*成为一个non-member函数,俾允许编译器在每一个实参身上执行隐式类型转换:
class Rational
{// ... 不包括operator*
};const Rational operator*(const Rational &lhs, const Rational &rhs) // 现在成了一个non-member函数
{return Rational(lhs.numerator() * rhs.numerator(), 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函数。太多C++程序员假设,如果一个“与某class相关”的函数不该成为一个member(也许由于其所有实参都需要类型转换,例如先前的Rational的operator*
函数),就该是个friend。本例表明这样的理由过于牵强。无论何时如何你可以避免friend函数就该避免,因为就像真实世界一样,朋友带来的麻烦往往多过其价值。当然有时候friend有其正当性,但这个事实依然存在:不能够只因函数不该成为member,就自动让它成为friend。
本条款内含真理,但却不是全部的真理。当你从Object-Oriented C++跨进Template C++(见条款1)并让Rational成为一个class template而非class,又有一些需要考虑的新争议、新解法、以及一些令人惊讶的设计牵连。这些争议、解法和设计牵连形成了条款46。
请记住:
如果你需要为某个函数的所有参数(包括被this指针所指的那个隐喻参数)进行类型转换,那么这个函数必须是个non-member。