• <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>

            woaidongmao

            文章均收錄自他人博客,但不喜標題前加-[轉貼],因其丑陋,見諒!~
            隨筆 - 1469, 文章 - 0, 評論 - 661, 引用 - 0
            數據加載中……

            當“友元”遇到“虛函數”

            前些天d2school QQ群里有網友在討論這一內容,我試圖做個整理。

            幾點基本知識:

            1、如果類A是類B的友元,則類A(的成員函數)可以直接訪問類B的私有成員。

            2、友元不能繼承。也就是說,類A是類B的友元,類D是類B的派生類,則類A并不會直接是類D的友元。通俗一點,父親的朋友,并不天生就是兒子的朋友。

            3、虛函數的基本知識就不說了。

            來看下面的幾段代碼:

            Code:

            1.      class A; 

            2.       

            3.      class

            4.     

            5.      private

            6.          virtual void output() 

            7.          { 

            8.              cout << "B::output" << endl; 

            9.          } 

            10.       

            11.      friend class A;      

            12.  }; 

            13.   

            14.  class D : public

            15. 

            16.  private

            17.      virtual void output() 

            18.      { 

            19.          cout << "D::output" << endl; 

            20.      }     

            21.  }; 

            A B 的友元類, 而DB的派生類。 所以,若想在A中直接訪問D的代碼,則編譯不過:

            Code:

            1.      class

            2.     

            3.      public:     

            4.          void test() 

            5.          { 

            6.              D d; 

            7.              d.output(); //編譯出錯 

            8.          } 

            9.      }; 

            這一點大家都沒覺得有問題,畢竟書上寫得都明白直觀:父類的友元,并不會因為繼承,而成為派生類的友元。

            但若代碼改成這樣,編譯器似乎就被欺騙了:

            Code:

            1.      class

            2.     

            3.      public:     

            4.          void test() 

            5.          { 

            6.              D d; 

            7.              B* pb = &d;    

            8.              pb->output(); //編譯通過 

            9.          } 

            10.  }; 

            沒錯,很多人會認為這種代碼,就算能通過編譯器,也很可能是一種不好的代碼,因為它怎么看都像是在欺騙編譯器。是這樣嗎?先不討論。先問一個問題:上面的08行代碼,output調用的是B類的那個output,還是D類的那個呢?

            回答正確并不難——既然會認定這段代碼帶有欺騙性質,而且又注意到output是一個虛函數的話——就能能正確地解答: 調用的是D類的。A明明只是B的友元,但卻通過一個簡單的類型轉換,就訪問了D類的那個私有函數,所以會覺得這是一種欺騙

            如果這是一種欺騙,那我們先來回答這個騙局為什么能成立:因為友元的判斷(resolve),在編譯期決定;而虛函數在運行期去resolve。在編譯08行代碼時,編譯器看到*pb的類型是B,而AB的友元,所以允許它調用output(它認為是B::output);而在運行時,由于output是虛函數,所以最終被決定到D::output頭上。

            沒時間細查手頭的《The Design and Evolution fo C++》,但不管這樣的設計是有意為之,還是無奈之舉,或者僅僅是C++眾多的特性正交現象之一,我個人覺得這個特性其實正是我們想要的。 

            一、首先要理解為什么派生類不應該繼承基類的"友元",這一點很多C++的書講到了

            二、其次要理解它的語法機制:前面講的,一個編譯期屬性與一個運行期屬性相遇了……

            三、要理解如果想關掉這一類欺騙,其實做不到。且來看看,該法之一是在編譯期,也檢查實際調用對象的類型,前面的示例代碼不難做到這一點,但下面的代碼中,pb來自一個形參:

            Code:

            1.      A::test_2(B* pb) 

            2.     

            3.          pb->output(); //很難在編譯期反查出pb的實際類型。 

            4.                       //因為調用test_2()的代碼,可能無處不在,甚至可能在未來的代碼 

            5.     

            四、要理解有時候,人們其實就是在故意做這種事,最典型的做法,就是通過非虛函數調用虛函數: 

            Code:

            1.      class

            2.     

            3.      public

            4.          void Action() 

            5.          { 

            6.                   this->DoAction(); 

            7.          } 

            8.      private

            9.            virtual void DoAction() = 0; //一個私有的純虛函數 

            10.   

            11.      //  friend class A;

            12.  }; 

             任何一個合格的C++程序員,都應該學會這種作法。DoAction是一個純虛函數,這里我們更決絕一點,干脆讓它是私有的,這就是逼著派生類自己去實現一個完全自我的DoAction(),假設有個class D : public B,并且聽話地實現了DoAction。具體D的定義,為節省點篇幅,不寫了。

             注意到第11行的注釋, class A 現在已經不是 B 的友員了,但不要緊,我們只是想在新版的類A中,調用Action函數,而它是public的,所以這里不需要友元來攪和。

            Code:

            1.      class

            2.     

            3.            void test() 

            4.            { 

            5.                     B* pb = new D; //pb 實際指向一個D對象。  

            6.                     pb->Action(); // Action  公開的,所以可以調用 

            7.            } 

            8.      }; 

            pb 調用了非虛的B::Action函數,但在Action內調用了虛函數DoAction,再由于pb實際指向的是D對象,所以最終調用的是D::DoAction()——這了無新意對不對?只要學過一點C++的多態,都會懂這一點。沒錯,它太司空見慣了,基本上所有C++程序員每天都會在寫類似的代碼——這就是我想說的,有時候,看起來在調用基類的代碼,但實際上在調用派生類的代碼。假設我們修改了語法規則,逼著虛函數在遇上友元之后失效,那就是逼著程序員不去用friend,去將更多本來應該是private的成員,用各種該法寫成public的。

            五、接著,是一個看起來很簡單,但卻被很多人誤解的概念:友元是破壞了封裝了嗎?錯,友元其實是促進了更好的封裝。它基于這樣的需求:有一個類,它有那么幾個成員(數據或函數),它只能對個別的其它類公開,這時,你可以考慮使用友元這項技術。如果不用,會有很多人就把那些成員直接修改為public,結果:原本應只對個別類開放的屬性,變成對所有類開放了。俗氣一點,法律規定老婆可以在私有場合下看老公的屁屁,如果法律強制規定不允許有這種例外,那很可能會有一些哥們,直接把屁股public出來就上街了——你若問他為什么,他也很無辜:我不過是想讓我老婆方便一些。

            六、讀了第五點,對OO有一套的C++程序員要筆試/鄙視我了,好,好,我知道既使不用friend的屬性,也可以美滿地實現前述的,類似老婆看老公屁股的問題——我是說,通過OO技術,避開需要只對部分類開放權限的需求,而轉化為第三方(比如某個接口及它的實現類)中——不管如何,你必須承認友元沒有破壞封裝性,因為其它解決這一問題的的,似乎更純粹的OO技術,它們美好的地方是在于更細的類顆粒,以及更好的類組織(不美好地方是,效率差了點,以及對OO思想非得有點水準,否則會繞暈掉,為了不讓Cer笑話,我們不提太多)。

            七、不過,縱算如此(第六點),我還是是狡辯一句:就算是在那些看起來很純的OO語言里,其實也有友元的影子啊。比如Java,是沒有friend關鍵字,可以它的內部類(非靜態的內部類),可以直接訪問外部類,難道不是友元嗎?——事實上,這也正是在C++使用friend最主旋律的用法(我甚至不用寫之一)。再如Object Pascal(Delphi),是沒有friend關鍵字,可是只要是位于同一個代碼單元(就是同一個.pas文件),則其中所有類天生就是可以互相訪問啊(當然,需首先滿足可見性)——這是當年我用Delphi時覺得最爽的地方之一了,既然號稱更OO的語言都留了一手,為何C++不能呢? :)

            八、第七點明顯帶有情緒化,這不符合C++之父對我們的期望:C++設計中有一條指導原則,那就是,無論做什么事情,都必須相信程序員。與可能出現什么樣的錯誤相比,更重要得多的是能做出什么好事情。C++程序員總被看作是成年人……。在C++的大千世界,差異性永遠被尊重,有人不愛用template,那不用就是; 有人堅決認為只要有privatepublic就足夠了,那就把protected忘記吧,甚至有人認為virtual也是多余的——很多人就是把C++當成另一種C使用,那都可以接受。friend也一樣,如果你不用,它的存在并不會給你帶來什么性能損失,你要做的就是用很OO或很不OO的,但是你熟悉的方法去滿足友元的需求而已。

            九、一定要這個第9點。除了友元類,更常見的其實是友元函數。很多操作符的重載,都需要全局的友元函數來減輕相關類的public出太多成員。這一下扯到操作符重載有用嗎?哇,這是另外一個經典的問題了,它曾經引起的糾紛,比這個友元所帶來的,要熱鬧上幾倍呢。就此打住。

            十、最后一點,C++初學者如何學習這門語言眾多的,又容易產生正交效應的特性呢?我有個建議:先有個基本了解,做點練習,但并不需要急著真正使用。

             

            posted on 2009-12-02 10:29 肥仔 閱讀(933) 評論(2)  編輯 收藏 引用 所屬分類: C++ 基礎

            評論

            # re: 當&ldquo;友元&rdquo;遇到&ldquo;虛函數&rdquo;  回復  更多評論   

            好文~頂一個
            2009-12-02 13:26 | iceshark

            # re: 當&ldquo;友元&rdquo;遇到&ldquo;虛函數&rdquo;  回復  更多評論   

            好文,學習了
            2009-12-02 16:01 | zhaoyg
            久久99国产综合精品女同| 亚洲精品国精品久久99热| 情人伊人久久综合亚洲| 久久久久人妻精品一区三寸蜜桃| 国产精品久久久久久久久久影院| 精品久久久噜噜噜久久久| 99久久伊人精品综合观看| 亚洲第一极品精品无码久久| 国产精品免费久久| 亚洲AV无码久久精品蜜桃| 精品国产综合区久久久久久 | 久久久久久午夜成人影院| 国内精品久久久久久不卡影院 | 久久这里只精品国产99热| 久久青青色综合| 精品人妻伦一二三区久久| 国产精品一久久香蕉国产线看观看| 亚洲国产成人久久综合一区77| 韩国无遮挡三级久久| 久久综合久久自在自线精品自| 久久久久这里只有精品| 久久精品草草草| 精品久久久久久久久午夜福利 | 91精品久久久久久无码| 久久99精品久久久久久久久久| 久久久久久国产精品美女| 久久久亚洲精品蜜桃臀 | 久久久国产乱子伦精品作者| 久久只有这精品99| 四虎久久影院| 久久丝袜精品中文字幕| 久久精品这里只有精99品| 国产精品99久久不卡| 亚洲嫩草影院久久精品| 一本久久久久久久| 久久99精品国产麻豆不卡| www亚洲欲色成人久久精品| 国产精品欧美久久久久天天影视| 久久免费视频网站| 91精品国产91热久久久久福利| 四虎国产精品免费久久久|