我在這本書的序言中曾特別提到過，讓類支持隱式類型轉換在一般情況下都不會是一個好主意。當然，這一準則還是存在一些例外的，其中最普通的一個就是數值類型。舉例說，如果你正在設計一個表示有理數的類，提供從整數向有理數的隱式轉換也不是毫無道理的。很顯然，這樣做與C++內建的從int向double的轉換一樣符合常理（甚至比C++內建的從double向int的轉換要符合常理得多）。這是千真萬確的，你可能以這樣的方式開始編寫你的Rational（有理數）類：
class Rational {
public:
Rational(int numerator = 0, int denominator = 1);
// 構造函數是有意聲明為非顯性的，
// 從而可以提供int到Rational的隱性轉換
int numerator() const; // 用于訪問分子和分母的函數
int denominator() const; // 參見條目22
private:
...
};
此時你需要讓這個類支持諸如加法、乘法等算術操作，但是你并不能確定這些操作是應該通過成員函數實現，還是以非成員函數的形式實現，亦或在可能的情況下以友元函數的形式實現。在你舉棋不定的時候，你的本能會告訴你你應該盡量做到面向對象。你知道這一點，于是會說，有理數的乘法操作與Rational類相關，因此很自然地，有理數的operator*就應該實現為Rational類內部的成員。與直覺恰恰相反的是，將函數放在相關的類中在有些時候恰恰是違背面向對象原則的（條目23中討論過），我們暫時不考慮這一問題，考察一下用operator*作為Rational的一個成員函數：
class Rational {
public:
...
const Rational operator*(const Rational& rhs) const;
};
（如果你不太了解為什么以這種方式定義函數：返回一個const值，使用一個“const引用”類型的參數，請參見條目3、20、21）
這種設計方案會使乘法操作非常簡便：
Rational oneEighth(1, 8);
Rational oneHalf(1, 2);
Rational result = oneHalf * oneEighth; // 工作正常
result = result * oneEighth; //工作正常
但是你不能滿足于現狀。你可能期望Rational支持混合模式操作，也就是說Rational應該可以與其它類型值（比如int）相乘。畢竟說，兩數相乘的操作再自然不過了，即使這兩個數的類型不一致。
然而，當你嘗試進行混合模式算術時，你會發現它僅僅在一半的時間內正常工作：
result = oneHalf * 2; // 工作正常
result = 2 * oneHalf; // 出錯！
這是一個不好的兆頭。你是否記得乘法交換率呢？
如果你將上述后兩個示例重寫為它們等價的函數形式，代碼中的問題就會浮出水面：
result = oneHalf.operator*(2); // 工作正常
result = 2.operator*(oneHalf); // 出錯！
oneHalf對象是一個類的實例，這個類中包含operator*，于是編譯器就會調用這個函數。然而整數2沒有相關的類，因此就沒有相關的operator*成員函數。編譯器仍然會去尋找operator*的非成員函數版本（應該存在于名字空間域或者整體域），這些operator*應該可以這樣調用：
result = operator*(2, oneHalf); // 出錯！
但是在本示例中，沒有任何非成員的operator*能接收一個int和一個Rational，因此搜尋工作自然會失敗。
請再次關注一下調用成功的示例。你可以看到它的第二個參數是整數2，而Rational::operator*本身只將Rational作為它的參數類型。這里發生了什么呢？2為什么僅在一種情況下正常運行，而另一種又不可以了呢？
這里發生的事情是：隱式類型轉換。編譯器知道你正在傳入一個int，而函數所需要的參數卻是Rational，但是編譯器同時也知道它可以通過使用你所提供的int值作為參數，調用Rational的構造函數，從而“變出”一個合適的Rational來。也就是說，編譯器在處理上述代碼時，會以近似于下面的形式進行：
const Rational temp(2); // 以2為參數，創建一個
// 臨時的Rational對象
result = oneHalf * temp; // 與oneHalf.operator*(temp)等價
當然，編譯器這樣做僅僅是因為有一個非顯性的構造函數為其助一臂之力。如果Rational的構造函數是explicit的，那么下面的語句都是通不過編譯的：
result = oneHalf * 2; // 出錯! (存在explicit的構造函數)
// 無法將2轉型為Rational
result = 2 * oneHalf; // 同樣的錯誤，同樣的問題
雖然上述的兩條語句無法支持混合模式算術，但是至少二者的行為依舊保持一致。
然而你的目標是：即能保持一致性，又能支持混合模式算術，換句話說，尋找出讓上述兩條語句均能通過編譯的設計方案。讓我們返回先前的兩條語句，來討論一下：為什么即使Rational的構造函數不是explicit的，二者依然是一條可通過編譯，另一條則通不過：
result = oneHalf * 2; // 工作正常 (oneHalf擁有非顯性構造函數)
result = 2 * oneHalf; // 錯誤! (即使oneHalf擁有非顯性構造函數)
看上去似乎僅當這些參數存在于參數表中時，它們才有資格進行隱式類型轉換。而那些與調用成員函數的對象（也就是this所指向的對象）相關的隱式參數永遠也沒有資格進行隱式轉換。這就是為什么第一次調用能夠通過編譯，而第二次不行。第一種情況涉及到參數表中所列的一個參數，而第二種沒有。
但是此時你仍期望支持混合模式算術，同時此時工作方案也水落石出了：將operator*聲明為非成員函數，這樣就可以允許編譯器對所有參數進行隱式類型轉換：
class Rational {
... // 不包含任何operator*
};
const Rational operator*(const Rational& lhs, const Rational& rhs)
// 將operator*聲明為非成員函數
{
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*可以通過Rational的公用接口得到完整的實現。上面的代碼交待了如何做這件事情。我們可以從中觀察總結出一條重要結論，那就是：與成員函數相反的是非成員函數，而不是友元函數。有太多的C++程序員自認為，如果一個函數與一個類相關，且不應將其實現為成員（比如說，所有參數都需要進行類型轉換）時，應將其實現為友元。這個示例表明這樣的推理是存在漏洞的。要盡量避免使用友元，因為，與現實生活中的情況類似，朋友為我們帶來的麻煩往往要比好處多得多。當然不排除存在一些真摯的友誼。但是這并不意味著一個函數不應該作為成員時，就必須成為一個友元。
本條款中包含著真理，僅僅包含真理，但又不是真理的全部。當你從面向對象的C++過渡至包含模板的C++時（參見條目1），你會將Rational實現為類模板而不是普通的類，此時就需要考慮新的問題了，也有了新的解決辦法，一些設計實現的方法是不可思議的。這些問題、解決方案、具體實現是條目46討論的主題。
時刻牢記
l 如果你需要對一個函數的所有參數全部進行類型轉換（包括this指針所指的參數），那么它必須是一個非成員函數。