1. 将需要隐式类型转换的函数声明为成员函数会出现问题

使类支持隐式转换是一个坏的想法。当然也有例外的情况，最常见的一个例子就是数值类型。举个例子，如果你设计一个表示有理数的类，允许从整型到有理数的隐式转换应该是合理的。在C++内建类型中，从int转换到double也是再合理不过的了（比从double转换到int更加合理）。看下面的例子：

 class Rational {

 public:

 Rational(int numerator = , // ctor is deliberately not explicit;

 int denominator = ); // allows implicit int-to-Rational

 // conversions

 int numerator() const; // accessors for numerator and

 int denominator() const; // denominator — see Item 22

 private:

 ...

 };

你想支持有理数的算术运算，比如加法，乘法等等，但是你不知道是通过成员函数还是非成员函数，或者非成员友元函数来实现。你的直觉会告诉你当你犹豫不决的时候，你应该使用面向对象的特性。有理数的乘积和有理数类相关，所有将有理数的operator*实现放在Rationl类中看上去是很自然的事。但违反直觉的是，Item 23已经论证过了将函数放在类中的方法有时候会违背面向对象法则，现在我们将其放到一边，研究一下将operator*实现为成员函数的做法：

 class Rational {

 public:

 ...

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

 };

（如果你不明白为什么函数声明成上面的样子——返回一个const value值，参数为const引用，参考Item 3,Item 20和Item21）

这个设计让你极为方便的执行有理数的乘法：

 Rational oneEighth(, );

 Rational oneHalf(, );

 Rational result = oneHalf * oneEighth; // fine

 result = result * oneEighth; // fine

但是你不满足。你希望可以支持混合模式的操作，例如可以支持int类型和Rational类型之间的乘法。这种不同类型之间的乘法也是很自然的事情。

当你尝试这种混合模式的运算的时候，你会发现只有一半的操作是对的：

 result = oneHalf * ; // fine

 result =  * oneHalf; // error!

这就不太好了，乘法是支持交换律的。

2. 问题出在哪里？

将上面的例子用等价的函数形式写出来，你就会知道问题出在哪里：

 result = oneHalf.operator*(); // fine

 result = .operator*(oneHalf ); // error!

oneHalf对象是Rational类的一个实例，而Rational支持operator*操作，所以编译器能调用这个函数。然而，整型2却没有关联的类，也就没有operator*成员函数。编译器同时会去寻找非成员operator*函数（也就是命名空间或者全局范围内的函数）：

 result = operator*(, oneHalf ); // error!

但是在这个例子中，没有带int和Rational类型参数的非成员函数，所以搜索会失败。

再看一眼调用成功的那个函数。你会发现第二个参数是整型2，但是Rational::operator*使用Rational对象作为参数。这里发生了什么？为什么都是2，一个可以另一个却不行？

没错，这里发生了隐式类型转换。编译器知道函数需要Rational类型，但你传递了int类型的实参，它们也同样知道通过调用Rational的构造函数，可以将你提供的int实参转换成一个Rational类型实参，这就是编译器所做的。它们的做法就像下面这样调用：

 const Rational temp(); // create a temporary

 // Rational object from 2

 result = oneHalf * temp; // same as oneHalf.operator*(temp);

当然，编译器能这么做仅仅因为类提供了non-explicit构造函数。如果Rational类的构造函数是explicit的，下面的两个句子都会出错：

 result = oneHalf * ; // error! (with explicit ctor);

 // can’t convert 2 to Rational

 result =  * oneHalf; // same error, same problem

这样就不能支持混合模式的运算了，但是至少两个句子的行为现在一致了。

然而你的目标是既能支持混合模式的运算又要满足一致性，也就是，你需要一个设计使得上面的两个句子都能通过编译。回到上面的例子，当Rational的构造函数是non-explicit的时候，为什么一个能编译通过另外一个不行呢？

看上去是这样的，只有参数列表中的参数才有资格进行隐式类型转换。而调用成员函数的隐式参数——this指针指向的那个——绝没有资格进行隐式类型转换。这就是为什么第一个调用成功而第二个调用失败的原因。

3. 解决方法是什么？

然而你仍然希望支持混合模式的算术运行，但是方法现在可能比较明了了：使operator*成为一个非成员函数，这样就允许编译器在所有的参数上面执行隐式类型转换了：

 class Rational {

 ... // contains no operator*

 };

 const Rational operator*(const Rational& lhs, // now a non-member

 const Rational& rhs) // function

 {

 return Rational(lhs.numerator() * rhs.numerator(),

 lhs.denominator() * rhs.denominator());

 }

 Rational oneFourth(, );

 Rational result;

 result = oneFourth * ; // fine

 result =  * oneFourth; // hooray, it works!

4. Operator*应该被实现为友元函数么？

故事有了一个完美的结局，但是还有一个挥之不去的担心。Operator*应该被实现为Rational类的友元么？

在这种情况下，答案是No。因为operator*可以完全依靠Rational的public接口来实现。上面的代码就是一种实现方式。我们能得到一个很重要的结论：成员函数的反义词是非成员函数而不是友元函数。太多的c++程序员认为一个类中的函数如果不是一个成员函数（举个例子，需要为所有参数做类型转换），那么他就应该是一个友元函数。上面的例子表明这样的推理是有缺陷的。尽量避免使用友元函数，就像生活中的例子，朋友带来的麻烦可能比从它们身上得到的帮助要多。

5. 其他问题

如果你从面向对象C++转换到template C++，将Rational实现成一个类模版，会有新的问题需要考虑，并且有新的方法来解决它们。这些问题，方法和设计参考Item 46。