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

            sherrylso

            C++博客 首頁 新隨筆 聯(lián)系 聚合 管理
              18 Posts :: 0 Stories :: 124 Comments :: 0 Trackbacks

            四、c++中的多態(tài)規(guī)則。
            一) c++中函數(shù)動態(tài)綁定規(guī)則。
            看下面的例子:

            class Window
            {

            public:
              virtual 
            void  oops()
              
            {
                cout
            <<"Window oops"<<endl;
              }

            public:
              
            int height;
              
            int width;
            }
            ;
            class TextWindow : public Window
            {

            public:
              virtual 
            void  oops()
              
            {
                cout
            <<"TextWindow oops"<<cursorLocation<<endl;
              }

            public:
              
            int cursorLocation;
            }
            ;

            main()
            {
              Window win;
              Window
            * tWin;
              TextWindow 
            * tWinPtr;

              tWinPtr 
            = new TextWindow;
              tWin 
            = tWinPtr;
              
              win.oops();
              tWin
            ->oops();
            }


            類TextWindow繼承與類Window。我想程序運(yùn)行的結(jié)果,大多數(shù)熟悉C++的人都會知道,
            win.oops()最終調(diào)用的是父類oops函數(shù),而tWin->oops()調(diào)用的是子類TextWindow的函數(shù)。
            通過這個例子,我們先總結(jié)一下c++中的多態(tài)調(diào)用規(guī)則
            第一、對于指針和引用類型,當(dāng)消息調(diào)用的成員函數(shù)有可能被重寫時(shí),最終被選擇調(diào)用的成員函數(shù)由消息接收者的動態(tài)類型確定(注意:在OO概念中,對某個對象成員函數(shù)進(jìn)行調(diào)用,常常稱為給該對象發(fā)送消息,該對象就是消息的接收者)。
                  如上例:tWin->oops(),由于tWin的動態(tài)類型是子類TextWindow,而不是Windows,所以tWin->oops()調(diào)用的是子類TextWindow的函數(shù)。
            二、對于其它的變量,對虛擬函數(shù)調(diào)用綁定完全由該變量的靜態(tài)類型確定(即該變量的聲明),而不是該變量的真實(shí)類型確定。
                 如上例:win.oops(),由于win的聲明類型為Window類,所以其結(jié)果調(diào)用的是父類oops函數(shù)。
            二) 探討。
                 接下來,我們要看的問題是,在c++中,為什么對于多態(tài)規(guī)則(或者說是動態(tài)函數(shù)綁定規(guī)則),做出了兩中不同的劃分,即:只有指針與引用類型,才進(jìn)行函數(shù)的后期動態(tài)綁定,也就是多態(tài)。這或許也是許多c++初學(xué)者非常迷惑的地方。這種規(guī)則的不一致性,的確給c++的語法造成一定的復(fù)雜性。而這在Java,或者C#中是沒有的,后面我們會涉及到。
                  我們先來看例子。 

            void f()
            {
              Window  win;
              Window
            * tWinPtr;
              
              tWinPtr 
            = new TextWindow;
              win     
            = *tWinPtr;//what's problem happen
               
              win.oops(); 
            //what's problem happen
              tWinPtr->oops();
            }


                  在這里,如果我們假設(shè),c++的函數(shù)動態(tài)綁定規(guī)則是一致的,看看會發(fā)生什么問題???
                  現(xiàn)在win被聲明為Window類型,然而其真實(shí)的類型為TextWindow(因?yàn)閣in=*tWinPtr),由于我們的假設(shè),win現(xiàn)在是允許進(jìn)行動態(tài)函數(shù)綁定的,所以當(dāng)執(zhí)行win.oops()時(shí),實(shí)際上是調(diào)用子類TextWindow的成員函數(shù)。
                 現(xiàn)在,我們有必要來審視一下win變量的內(nèi)存布局。由于win變量是在棧上聲明的變量,其內(nèi)存也是從棧進(jìn)行分配(這是c++從c語言那里繼承過來的優(yōu)良特質(zhì),從棧上分配內(nèi)存空間比動態(tài)分配內(nèi)存有更好的執(zhí)行速度),c++標(biāo)準(zhǔn)規(guī)定:給win變量分配內(nèi)存空間的大小,由其靜態(tài)的類型確定,即應(yīng)該是Window類所使用的內(nèi)存空間大小。在這種情況下,當(dāng)執(zhí)行win=*tWinPtr時(shí),什么會發(fā)生?如下圖:

            在默認(rèn)的拷貝構(gòu)造函數(shù)情況下,信息會出現(xiàn)丟失,這就是著名的slicing off現(xiàn)象。結(jié)果,變量cursorLocation在win的內(nèi)存空間里丟失了。然而,問題是:在我們假設(shè)下,我們要求win.oops()導(dǎo)致TextWindow的成員函數(shù)調(diào)用,而在這個函數(shù)中,訪問到的cursorLocation變量是不存在!win.oops()調(diào)用將導(dǎo)致內(nèi)存違例!
                  到這里,我們可以總結(jié)一下:c++標(biāo)準(zhǔn)基于的其特定的內(nèi)存分配規(guī)則,給出了以上,我們在前一節(jié)總結(jié)出的函數(shù)動態(tài)綁定規(guī)則。
            三) 深入。
                  當(dāng)然,我們也可以說,c++也可以通過改變其內(nèi)存分配規(guī)則,來給出一個一致性的函數(shù)動態(tài)綁定規(guī)則。比如:可以考慮在給win變量分配內(nèi)存空間時(shí),考慮其所有子類需求,然后分配最大數(shù)量的內(nèi)存空間給win變量。這種做法可行性很差,對于編譯器而言,需要掃描整個程序(確定該類的所有子類),才能確定最大的內(nèi)存空間是多少。在使用類庫或者框架的情況下,會引起整個類庫,框架的重新編譯,這是得不償失的!而這種做法,在oo的語言中,基本上是沒有的。這也是c++不得不基于其現(xiàn)有的內(nèi)存管理機(jī)制,而對多態(tài)規(guī)則作出的不一致的解釋。
                對于這個c++現(xiàn)有的內(nèi)存管理機(jī)制,我們?nèi)绻麖牧硗饨嵌热ダ斫獾脑?是很合理的。當(dāng)win=*tWinPtr發(fā)生
            時(shí),我們可以類似地認(rèn)為:好比一個float類型的數(shù)賦給了一個interger類型的變量,其結(jié)果當(dāng)然是float的值被截?cái)嗔恕?br>    我們再來看其它語言,Java(或者C#)是怎么解決的。
                最重要的一點(diǎn)是,在Java(C#)中只有引用的概念,所以在棧上聲明的類的變量,只需要分配一個指針大小的內(nèi)存空間就行了,而不需要給該變量分配空間來保存變量內(nèi)容本身,這其實(shí)就是我們現(xiàn)在看到的c++中指針和引用的情況。
                

             

            posted on 2008-01-05 23:12 愛上龍卷風(fēng) 閱讀(3164) 評論(8)  編輯 收藏 引用

            Feedback

            # re: c語法背后的故事(二) [未登錄] 2008-01-06 12:21 ZZZ
            是有點(diǎn)晦澀  回復(fù)  更多評論
              

            # re: c++晦澀語法背后的故事(二) 2008-01-07 22:53 abettor.org
            看來這個容易理解一些,呵呵。  回復(fù)  更多評論
              

            # re: c++晦澀語法背后的故事(二) [未登錄] 2008-01-10 11:10 Composition
            sherrylso兄,
            void f()
            {
            Window win;
            Window* tWinPtr;

            tWinPtr = new TextWindow;
            win = *tWinPtr;//what's problem happen

            win.oops(); //what's problem happen
            tWinPtr->oops();
            }
            中win.oops(); 仍然會調(diào)用父類的方法,因?yàn)榫幾g器生成的拷貝構(gòu)造函數(shù)不會拷貝vptr。希望你check一下。
            這里僅僅切割了子對象,但是切割后的對象是合法的父對象,除非你的設(shè)計(jì)不合理,違反了LSP。  回復(fù)  更多評論
              

            # re: c++晦澀語法背后的故事(二) 2008-01-11 22:04 愛上龍卷風(fēng)
            @Composition
            我的論述的前提是:“假設(shè):c++的函數(shù)動態(tài)綁定規(guī)則是一致的“
            搞不清楚你的觀點(diǎn)是什么?
              回復(fù)  更多評論
              

            # re: c++晦澀語法背后的故事(二) 2008-01-14 13:35 Composition
            我的意思是不管子對象怎么切割,win.oops(); 永遠(yuǎn)會調(diào)用父類的函數(shù),絕不會因?yàn)榍懈钫{(diào)用子類的方法。既然不調(diào)用子類的方法,自然不會出錯。你可以在編譯器實(shí)驗(yàn)一下,你這個例子會輸出Window oops xxx,沒有錯誤。
            不管怎么假設(shè),通過對象調(diào)用成員函數(shù)都是編譯時(shí)綁定,永遠(yuǎn)不可能調(diào)用到子類的成員函數(shù)。
            win = *tWinPtr;這句會調(diào)用Window的拷貝構(gòu)造(編譯器生成),但是拷貝構(gòu)造不會拷貝對象的vptr。而且就算拷貝了,通過對象調(diào)用成員函數(shù)也不通過vptr找vtable,而是直接調(diào)用對象類型對應(yīng)到成員函數(shù)(編譯后成為全局函數(shù))。你這里假設(shè)“c++的函數(shù)動態(tài)綁定規(guī)則是一致的”,但別忘了,vptr不拷貝,這是C++實(shí)現(xiàn)機(jī)制,怎么調(diào)用都是父類的成員函數(shù),不會有多態(tài)。
            如果你做出拷貝構(gòu)造會拷貝vptr+對象調(diào)用會查找vtable的假設(shè),那么你的論述應(yīng)該合理。但是這么假設(shè)個人認(rèn)為意義不大。  回復(fù)  更多評論
              

            # re: c++晦澀語法背后的故事(二) 2008-01-14 21:39 愛上龍卷風(fēng)
            @Composition
            1) 首先,我要論述的是多態(tài)規(guī)則,不是只有C++有。很多面向?qū)ο蟮恼Z言都有的特性。Java, C#, Smalltalk。你不必要局限于C++本身。
            2) 其次,你說的,我都贊同,這就是c++的內(nèi)存管理機(jī)制。
            3) 基于c++的內(nèi)存管理機(jī)制,推出了現(xiàn)有的C++多態(tài)規(guī)則。
            4)我是在討論,C++語法為什么復(fù)雜的背后原因。也就是怎么去更好地理解現(xiàn)行的語法。
              回復(fù)  更多評論
              

            # re: c++晦澀語法背后的故事(二) 2008-01-14 21:41 愛上龍卷風(fēng)
            @Composition
            再者,如果C++改變了現(xiàn)有的內(nèi)存管理機(jī)制,即我提到的:可以考慮在給win變量分配內(nèi)存空間時(shí),考慮其所有子類需求,然后分配最大數(shù)量的內(nèi)存空間給win變量。
            是可以做到多態(tài)規(guī)則的一致性  回復(fù)  更多評論
              

            # re: c++晦澀語法背后的故事(二) 2008-01-15 12:14 Composition
            我明白你的意思了,不過我也沒有完全拘泥于C++,但是C++的多態(tài)實(shí)現(xiàn)確實(shí)與其他語言很不同。如Python,Ruby之類語言通過給類建立哈希表來實(shí)現(xiàn)多態(tài)。Java,C#之類應(yīng)該是通過元數(shù)據(jù)。而且只有C++才有切割問題,其他語言在堆上分配就不存在切割了。
            至于你的例子f()我覺得可以改成如下的例子更能說明問題,而且也不必做過多假設(shè):
            void f()
            {
            Window win;
            TextWindow textWin;
            Window* tWinPtr;

            tWinPtr = new TextWindow;
            memcpy(reinterpret_cast<char*>(tWinPtr) + 4,
            reinterpret_cast<char*>(&win) + 4,
            sizeof(win) - 4); //don't change vptr

            tWinPtr->oops(); //what's problem happen
            }
            這個例子會發(fā)生錯誤,即使運(yùn)行不出錯,邏輯也是錯的。
            至于你對“可以考慮在給win變量分配內(nèi)存空間時(shí),考慮其所有子類需求,然后分配最大數(shù)量的內(nèi)存空間給win變量。”的論述很透徹,我同意。  回復(fù)  更多評論
              


            只有注冊用戶登錄后才能發(fā)表評論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            无码AV波多野结衣久久| 99久久综合国产精品二区| 国产精品永久久久久久久久久| 午夜精品久久久久久久| 久久狠狠爱亚洲综合影院 | 亚洲欧美国产日韩综合久久| 99久久国产亚洲高清观看2024| 久久综合久久综合九色| 成人亚洲欧美久久久久| 久久综合九色综合欧美就去吻| 久久久久这里只有精品| 2021国内久久精品| 久久婷婷国产综合精品 | 日日狠狠久久偷偷色综合0| 久久婷婷五月综合成人D啪| 久久人人爽人人爽人人片AV麻豆| 一级做a爰片久久毛片免费陪| 色悠久久久久久久综合网| 久久精品成人欧美大片| 久久久久久久久无码精品亚洲日韩| 久久w5ww成w人免费| 国产成人精品久久综合| 亚洲人成无码www久久久| 色欲av伊人久久大香线蕉影院| 国产精品禁18久久久夂久| 99久久99久久精品国产片果冻| 国产精品久久久久久五月尺| 久久av无码专区亚洲av桃花岛| 国产2021久久精品| 久久久久久国产精品无码下载| 国产成人久久激情91| 性高湖久久久久久久久AAAAA| 久久久精品人妻一区二区三区蜜桃| 9191精品国产免费久久| 久久精品国产99国产精品亚洲| 久久精品国产秦先生| 久久久这里有精品| 精品免费久久久久国产一区| 性欧美丰满熟妇XXXX性久久久| 久久精品成人影院| 97精品久久天干天天天按摩|