我談到讓一個類支持隱式類型轉換通常是一個不好的主意。當然，這條規則有一些例外，最普通的一種就是在創建數值類型時。例如，假如你設計一個用來表現有理數的類，答應從整數到有理數的隱式轉換看上去並非不合理。這的確不比 C++ 的內建類型從 int 到 double 的轉換更不合理（而且比 C++ 的內建類型從 double 到 int 的轉換合理得多）。在這種情況下，你可以用這種方法開始你的 Rational 類：
class Rational {
public:
Rational(int numerator = 0, // ctor is deliberately not eXPlicit;
int denominator = 1); // allows implicit int-to-Rational
// conversions
int numerator() const; // Accessors for numerator and
int denominator() const; // denominator - see Item 22
private:
...
};
你知道你應該支持類似加，乘等算術運算，但是你不確定你應該通過成員函數還是非成員函數，或者，非成員的友元函數來實現它們。你的直覺告訴你，當你拿不准的時候，你應該堅持面向對象。你知道這些，於是表示，有理數的乘法與 Rational 類相關，所以在 Rational 類內部為有理數實現 operator* 似乎更加正常。與直覺不符，將函數放置在它們所關聯的類的內部的主意有時候與面向對象的原則正好相反，但是讓我們將它放到一邊，來研究一下將 operator* 作為 Rational 的一個成員函數的主意：
class Rational {
public:
...
const Rational operator*(const Rational& rhs) const;
};
（假如你不能確定為什麼這個函數聲明為這個樣子——返回一個 const by-value 的結果，卻持有一個 reference-to-const 作為它的參數。）
這個設計讓你在有理數相乘時不費吹灰之力：
Rational oneEighth(1, 8);
Rational oneHalf(1, 2);
Rational result = oneHalf * oneEighth; // fine
result = result * oneEighth; // fine
但是你並不感到滿足。你還希望支持混合模式的操作，以便讓 Rationals 能夠和其它類型（例如，int）相乘。究竟，很少有事情像兩個數相乘那麼正常，即使它們碰巧是數字的不同類型。
當你試圖做混合模式的算術運算時，可是，你發現只有一半時間它能工作：
result = oneHalf * 2; // fine
result = 2 * oneHalf; // error!
這是一個不好的征兆。乘法必須是可交換的，記得嗎？
當你重寫最後兩個例子為功能等價的另一種形式時，問題的來源就變得很明顯了：
result = oneHalf.operator*(2); // fine
result = 2.operator*(oneHalf); // error!
對象 oneHalf 是一個包含 operator* 的類的實例，所以編譯器調用那個函數。然而，整數 2 與類沒有關系，因而沒有 operator* 成員函數。編譯器同樣要尋找能如下調用的非成員的 operator*s（也就是說，在 namespace 或全局范圍內的 operator*s）：
result = operator*(2, oneHalf); // error!
但是在本例中，沒有非成員的持有一個 int 和一個 Rational 的 operator*，所以搜索失敗。
再看一眼那個成功的調用。你會發現它的第二個參數是整數 2，然而 Rational::operator* 卻持有一個 Rational 對象作為它的參數。這裡發生了什麼呢？為什麼 2 在一個位置能工作，在其它地方卻不行呢？
發生的是隱式類型轉換。編譯器知道你傳遞一個 int 而那個函數需要一個 Rational，但是它們也知道通過用你提供的 int 調用 Rational 的構造函數，它們能做出一個相配的 Rational，這就是它們的所作所為。換句話說，它們將那個調用或多或少看成如下這樣：
const Rational temp(2); // create a temporary
// Rational object from 2
result = oneHalf * temp; // same as oneHalf.operator*(temp);
當然，編譯器這樣做僅僅是因為提供了一個非顯性的構造函數。假如 Rational 的構造函數是顯性的，這些語句都將無法編譯：
result = oneHalf * 2; // error! (with explicit ctor);
// can’t convert 2 to Rational
result = 2 * oneHalf; // same error, same problem
支持混合模式操作失敗了，但是至少兩個語句的行為將步調一致。
然而，你的目標是既保持一致性又要支持混合運算，也就是說，一個能使上面兩個語句都可以編譯的設計。讓我們返回這兩個語句看一看，為什麼即使 Rational 的構造函數不是顯式的，也是一個可以編譯而另一個不行：
result = oneHalf * 2; // fine (with non-explicit ctor)
result = 2 * oneHalf; // error! (even with non-explicit ctor)
其原因在於僅僅當參數列在參數列表中的時候，它們才有資格進行隱式類型轉換。而對應於成員函數被調用的那個對象的隱含參數—— this 指針指向的那個——根本沒有資格進行隱式轉換。這就是為什麼第一個調用能編譯而第二個不能。第一種情況包括一個參數被列在參數列表中，而第二種情況沒有。
你還是希望支持混合運算，然而，現在做到這一點的方法或許很清楚了：讓 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(1, 4);
Rational result;
result = oneFourth * 2; // fine
result = 2 * oneFourth; // hooray, it works!
這樣的確使故事有了一個圓滿的結局，但是有一個吹毛求疵的毛病。operator* 應該不應該作為 Rational 類的友元呢？
在這種情況下，答案是不，因為 operator* 能夠根據 Rational 的 public 接口完全實現。上面的代碼展示了做這件事的方法之一。這導出了一條重要的結論：與成員函數相對的是非成員函數，而不是友元函數。太多的程序員假設假如一個函數與一個類有關而又不應該作為成員時（例如，因為所有的參數都需要類型轉換），它應該作為友元。這個示例證實這樣的推理是有缺陷的。無論何時，只有你能避免友元函數，你就避免它，因為，就像在現實生活中，朋友的麻煩通常多於他們的價值。當然，有時友誼是正當的，但是事實表明僅僅因為函數不應該作為成員並不自動意味著它應該作為友元。 本 Item 包含真理，除了真理一無所有，但它還不是完整的真理。當你從 Object-Oriented C++ 穿過界線進入 Template C++而且將 Rational 做成一個類模板代替一個類，就有新的問題要考慮，也有新的方法來解決它們，以及一些令人驚奇的設計含義。
Things to Remember
·假如你需要在一個函數的所有參數（包括被 this 指針所指向的那個）上使用類型轉換，這個函數必須是一個非成員。
