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