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

            weibing

            用最簡單的方式理解const成員函數及mutable關鍵字

            struct SomeType
            {
                
            int m_a;
                
            void SomeMethod()const
                
            {
                    m_a 
            = 0;
                }

            }
            ;

            上面的代碼實際上將無法通過編譯,我們把"SomeMethod"換一個寫法來理解一下

            void SomeMethod()const

            {

                this->m_a = 0;

            }

            這里的“this”就是我們通常說的成員函數的隱含this指針參數了,該參數雖然沒在函數參數列表里(所以稱之為隱含),但是這個參數是實際存在的,并且該參數類型對于非const成員函數來說是SomeType* const,對于const 成員函數,其類型是const SomeType* const, 也就是又增加了一個const(我想是由于this指針是隱含參數,所以const沒地方放了,只好放在成員函數的結尾了)。這也就解釋了,為什么上面的代碼無法通過編譯,同時也說明了,成員函數是通過這個隱含的this指針來訪問其成員的,這個隱含的this指針,在代碼定義的時候仍然可以省去不寫,當然,在編譯的時候,編譯器會自動添加這個this的。

             

            這里還存在一個很別扭的問題: 在SomeMethod的第一個版本定義里,定義的是const成員函數,但是第二個版本由于升級,我們需要改動某個成員變量的值,很顯然,這個時候我們需要把SomeMethod成員函數后面的const去掉才能通過編譯,但這樣做又會帶來一個問題,如果SomeMethod是作為共享代碼庫的形式存在,我們有理由保證SomeMethod的版本兼容性,這樣才能完全保證該庫的第一個版本使用者,在升級到該庫的第二個版本時,可以不改變調用代碼,進行成功編譯。為了解決這個問題,C++引入mutable關鍵字,也就是把m_a定義為mutable int m_a就可以了。該關鍵字將屏蔽掉編譯過程中對const的特殊優化處理,不僅僅解決這個編譯問題,也保證了運行期的邏輯正確性。

             

            這個時候,大家可能會提出一個實用的做法,就是避免定義const成員函數,一切問題不就解決了嗎(函數參數的const定義規范,以后我會專門討論)?其實用const有如下幾個明顯好處:

             

            1.     const從語言層面保證該方法不會改動其成員,幫助該方法的使用者理解其含義并做出正確調用,也幫助該方法的設計者不違背其實現意圖,從編譯層面盡可能防止寫出錯誤的實現代碼

            2.     const可以擴大該方法的使用范圍,const SomeType c; c.SomeMethod(); 如果不是const成員函數,這個代碼將無法實現編譯,也就是說該方法的調用將受到本不該受到的限制

            3.     從語義以外的執行層面,const變量在一定程度上會參與編譯的優化,從而提高運行效率,也就是const對象的存在是必要的


            posted on 2011-07-10 23:31 魏兵 閱讀(1479) 評論(0)  編輯 收藏 引用

            My Links

            Blog Stats

            常用鏈接

            留言簿

            隨筆檔案

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            久久精品人成免费| 久久精品国产精品青草| 国产69精品久久久久9999APGF | 一本色道久久88综合日韩精品 | www.久久99| 97精品伊人久久久大香线蕉| 久久综合伊人77777麻豆| 久久精品黄AA片一区二区三区| 久久99精品国产99久久6男男| 久久人人爽人人爽人人片AV麻豆 | 久久伊人精品青青草原高清| 亚洲精品乱码久久久久久蜜桃| 国内精品九九久久久精品| 一本大道久久香蕉成人网| 久久成人精品视频| 亚洲狠狠婷婷综合久久久久| 久久精品国产黑森林| 亚洲乱亚洲乱淫久久| 久久久久久国产精品免费无码| 精品久久久久久久久久中文字幕| 国产精品一久久香蕉国产线看观看| 亚洲国产成人精品女人久久久 | 一个色综合久久| 亚洲欧美久久久久9999| 91精品无码久久久久久五月天| 亚洲国产精品18久久久久久| 思思久久好好热精品国产| 久久久精品视频免费观看| 国产福利电影一区二区三区久久久久成人精品综合 | 99久久国产宗和精品1上映| 亚洲日韩欧美一区久久久久我| 国产成人无码精品久久久免费| 欧美国产成人久久精品| 99久久这里只精品国产免费| 一本色道久久综合狠狠躁篇| 欧洲性大片xxxxx久久久| 日本亚洲色大成网站WWW久久| 亚洲人成无码www久久久| 亚洲国产精品无码久久九九| 国产成人精品综合久久久久| 久久精品视频一|