• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            洛譯小筑

            別來無恙,我的老友…
            隨筆 - 45, 文章 - 0, 評論 - 172, 引用 - 0
            數(shù)據(jù)加載中……

            [ECPP讀書筆記 條目24] 當(dāng)函數(shù)所有的參數(shù)需要進(jìn)行類型轉(zhuǎn)換時,要將其聲明為非成員函數(shù)

            我在這本書的序言中曾特別提到過,讓類支持隱式類型轉(zhuǎn)換在一般情況下都不會是一個好主意。當(dāng)然,這一準(zhǔn)則還是存在一些例外的,其中最普通的一個就是數(shù)值類型。舉例說,如果你正在設(shè)計一個表示有理數(shù)的類,提供從整數(shù)向有理數(shù)的隱式轉(zhuǎn)換也不是毫無道理的。很顯然,這樣做與C++內(nèi)建的從intdouble的轉(zhuǎn)換一樣符合常理(甚至比C++內(nèi)建的從doubleint的轉(zhuǎn)換要符合常理得多)。這是千真萬確的,你可能以這樣的方式開始編寫你的Rational(有理數(shù))類:

            class Rational {

            public:

              Rational(int numerator = 0, int denominator = 1);

                                               // 構(gòu)造函數(shù)是有意聲明為非顯性的,

                                               // 從而可以提供intRational的隱性轉(zhuǎn)換

             

              int numerator() const;           // 用于訪問分子和分母的函數(shù)

              int denominator() const;         // 參見條目22

             

            private:

              ...

            };

            此時你需要讓這個類支持諸如加法、乘法等算術(shù)操作,但是你并不能確定這些操作是應(yīng)該通過成員函數(shù)實現(xiàn),還是以非成員函數(shù)的形式實現(xiàn),亦或在可能的情況下以友元函數(shù)的形式實現(xiàn)。在你舉棋不定的時候,你的本能會告訴你你應(yīng)該盡量做到面向?qū)ο蟆D阒肋@一點,于是會說,有理數(shù)的乘法操作與Rational類相關(guān),因此很自然地,有理數(shù)的operator*就應(yīng)該實現(xiàn)為Rational類內(nèi)部的成員。與直覺恰恰相反的是,將函數(shù)放在相關(guān)的類中在有些時候恰恰是違背面向?qū)ο笤瓌t的(條目23中討論過),我們暫時不考慮這一問題,考察一下用operator*作為Rational的一個成員函數(shù):

            class Rational {

            public:

             ...

             

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

            };

            (如果你不太了解為什么以這種方式定義函數(shù):返回一個const值,使用一個“const引用”類型的參數(shù),請參見條目32021

            這種設(shè)計方案會使乘法操作非常簡便:

            Rational oneEighth(1, 8);

            Rational oneHalf(1, 2);

             

            Rational result = oneHalf * oneEighth; // 工作正常

             

            result = result * oneEighth;            //工作正常

            但是你不能滿足于現(xiàn)狀。你可能期望Rational支持混合模式操作,也就是說Rational應(yīng)該可以與其它類型值(比如int)相乘。畢竟說,兩數(shù)相乘的操作再自然不過了,即使這兩個數(shù)的類型不一致。

            然而,當(dāng)你嘗試進(jìn)行混合模式算術(shù)時,你會發(fā)現(xiàn)它僅僅在一半的時間內(nèi)正常工作:

            result = oneHalf * 2;                   // 工作正常

             

            result = 2 * oneHalf;                   // 出錯!

            這是一個不好的兆頭。你是否記得乘法交換率呢?

            如果你將上述后兩個示例重寫為它們等價的函數(shù)形式,代碼中的問題就會浮出水面:

            result = oneHalf.operator*(2);          // 工作正常

             

            result = 2.operator*(oneHalf);          // 出錯!

            oneHalf對象是一個類的實例,這個類中包含operator*,于是編譯器就會調(diào)用這個函數(shù)。然而整數(shù)2沒有相關(guān)的類,因此就沒有相關(guān)的operator*成員函數(shù)。編譯器仍然會去尋找operator*的非成員函數(shù)版本(應(yīng)該存在于名字空間域或者整體域),這些operator*應(yīng)該可以這樣調(diào)用:

            result = operator*(2, oneHalf);         // 出錯!

            但是在本示例中,沒有任何非成員的operator*能接收一個int和一個Rational,因此搜尋工作自然會失敗。

            請再次關(guān)注一下調(diào)用成功的示例。你可以看到它的第二個參數(shù)是整數(shù)2,而Rational::operator*本身只將Rational作為它的參數(shù)類型。這里發(fā)生了什么呢?2為什么僅在一種情況下正常運行,而另一種又不可以了呢?

            這里發(fā)生的事情是:隱式類型轉(zhuǎn)換。編譯器知道你正在傳入一個int,而函數(shù)所需要的參數(shù)卻是Rational,但是編譯器同時也知道它可以通過使用你所提供的int值作為參數(shù),調(diào)用Rational的構(gòu)造函數(shù),從而“變出”一個合適的Rational來。也就是說,編譯器在處理上述代碼時,會以近似于下面的形式進(jìn)行:

            const Rational temp(2);            // 2為參數(shù),創(chuàng)建一個

                                               // 臨時的Rational對象

             

            result = oneHalf * temp;          // oneHalf.operator*(temp)等價

            當(dāng)然,編譯器這樣做僅僅是因為有一個非顯性的構(gòu)造函數(shù)為其助一臂之力。如果Rational的構(gòu)造函數(shù)是explicit的,那么下面的語句都是通不過編譯的:

            result = oneHalf * 2;              // 出錯! (存在explicit的構(gòu)造函數(shù))

                                               // 無法將2轉(zhuǎn)型為Rational

             

            result = 2 * oneHalf;              // 同樣的錯誤,同樣的問題

            雖然上述的兩條語句無法支持混合模式算術(shù),但是至少二者的行為依舊保持一致。

            然而你的目標(biāo)是:即能保持一致性,又能支持混合模式算術(shù),換句話說,尋找出讓上述兩條語句均能通過編譯的設(shè)計方案。讓我們返回先前的兩條語句,來討論一下:為什么即使Rational的構(gòu)造函數(shù)不是explicit的,二者依然是一條可通過編譯,另一條則通不過:

            result = oneHalf * 2;                // 工作正常 (oneHalf擁有非顯性構(gòu)造函數(shù))

             

            result = 2 * oneHalf;                // 錯誤! (即使oneHalf擁有非顯性構(gòu)造函數(shù))

            看上去似乎僅當(dāng)這些參數(shù)存在于參數(shù)表中時,它們才有資格進(jìn)行隱式類型轉(zhuǎn)換。而那些與調(diào)用成員函數(shù)的對象(也就是this所指向的對象)相關(guān)的隱式參數(shù)永遠(yuǎn)也沒有資格進(jìn)行隱式轉(zhuǎn)換。這就是為什么第一次調(diào)用能夠通過編譯,而第二次不行。第一種情況涉及到參數(shù)表中所列的一個參數(shù),而第二種沒有。

            但是此時你仍期望支持混合模式算術(shù),同時此時工作方案也水落石出了:將operator*聲明為非成員函數(shù),這樣就可以允許編譯器對所有參數(shù)進(jìn)行隱式類型轉(zhuǎn)換:

            class Rational {

              ...                              // 不包含任何operator*

            };

             

            const Rational operator*(const Rational& lhs, const Rational& rhs)

                                               // operator*聲明為非成員函數(shù)

            {

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

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

            }

             

            Rational oneFourth(1, 4);

            Rational result;

             

            result = oneFourth * 2;           // 工作正常

             

            result = 2 * oneFourth;           // 太棒了!這樣也可以了。

            故事終于有了一個完美的結(jié)局,但是還留下了一處懸念。operator*是否應(yīng)該做為Rational類的一個友元呢?

            在這種情況下,答案是:不行。因為operator*可以通過Rational的公用接口得到完整的實現(xiàn)。上面的代碼交待了如何做這件事情。我們可以從中觀察總結(jié)出一條重要結(jié)論,那就是:與成員函數(shù)相反的是非成員函數(shù),而不是友元函數(shù)。有太多的C++程序員自認(rèn)為,如果一個函數(shù)與一個類相關(guān),且不應(yīng)將其實現(xiàn)為成員(比如說,所有參數(shù)都需要進(jìn)行類型轉(zhuǎn)換)時,應(yīng)將其實現(xiàn)為友元。這個示例表明這樣的推理是存在漏洞的。要盡量避免使用友元,因為,與現(xiàn)實生活中的情況類似,朋友為我們帶來的麻煩往往要比好處多得多。當(dāng)然不排除存在一些真摯的友誼。但是這并不意味著一個函數(shù)不應(yīng)該作為成員時,就必須成為一個友元。

            本條款中包含著真理,僅僅包含真理,但又不是真理的全部。當(dāng)你從面向?qū)ο蟮?span style="font-family:"Courier New";">C++過渡至包含模板的C++時(參見條目1),你會將Rational實現(xiàn)為類模板而不是普通的類,此時就需要考慮新的問題了,也有了新的解決辦法,一些設(shè)計實現(xiàn)的方法是不可思議的。這些問題、解決方案、具體實現(xiàn)是條目46討論的主題。

            時刻牢記

            如果你需要對一個函數(shù)的所有參數(shù)全部進(jìn)行類型轉(zhuǎn)換(包括this指針?biāo)傅膮?shù)),那么它必須是一個非成員函數(shù)。

            posted on 2007-07-05 23:23 ★ROY★ 閱讀(1224) 評論(1)  編輯 收藏 引用 所屬分類: Effective C++

            評論

            # re: 【翻譯】[Effective C++中文版第3版][第24條]當(dāng)函數(shù)所有的參數(shù)需要進(jìn)行類型轉(zhuǎn)換時,要將其聲明為非成員函數(shù)  回復(fù)  更多評論   

            與成員函數(shù)所調(diào)用的對象(也就是 this 所指向的對象)相關(guān)的隱式參數(shù)永遠(yuǎn)也沒有資格進(jìn)行隱式轉(zhuǎn)換
            **********************************************
            這個是必然的, 因為編譯器根本無法確定你要轉(zhuǎn)到什么類型。


            2007-07-06 08:43 | SmartPtr
            欧美噜噜久久久XXX| 日韩一区二区久久久久久| 2020久久精品亚洲热综合一本| 久久综合九色欧美综合狠狠| 久久婷婷五月综合97色直播| 久久久久久国产精品无码超碰| 精品久久久久久无码人妻蜜桃| 精品综合久久久久久97| 亚洲国产天堂久久综合网站| 久久99久久99精品免视看动漫 | 久久黄色视频| 久久天堂AV综合合色蜜桃网| 久久久久18| 99久久99久久久精品齐齐| 色综合久久久久| 无码AV中文字幕久久专区| 久久国产精品免费一区二区三区| 漂亮人妻被中出中文字幕久久| 国产精品久久久久久久久| 偷窥少妇久久久久久久久| 99久久99久久精品国产| 久久精品国产亚洲AV忘忧草18| 精品久久久久久无码国产| 国产V亚洲V天堂无码久久久| 伊人久久大香线蕉亚洲| 亚洲精品WWW久久久久久| 久久精品国产精品亜洲毛片| 久久精品国产69国产精品亚洲 | 伊人久久大香线焦综合四虎 | 久久久噜噜噜久久| 国产国产成人久久精品| 2020最新久久久视精品爱| 国产人久久人人人人爽| 国产精品久久久久久搜索| 久久久精品2019免费观看| 国内精品人妻无码久久久影院| 无码超乳爆乳中文字幕久久 | 性欧美丰满熟妇XXXX性久久久| 久久久精品人妻一区二区三区蜜桃| 久久久久亚洲AV综合波多野结衣| 国产精品美女久久久免费|