轉載地址：http://www.enet.com.cn/article/2005/0808/A20050808442242_2.shtml
【簡 介】
我談到讓一個類支持隱式類型轉換通常是一個不好的主意。當然，這條規則有一些例外，最普通的一種就是在創建數值類型時。例如，如果你設計一個用來表現有理數的類，允許從整數到有理數的隱式轉換看上去並非不合理。
當你試圖做混合模式的算術運算時，可是，你發現只有一半時間它能工作：
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 指針所指向的那個）上使用類型轉換，這個函數必須是一個非成員。