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

            常用鏈接

            留言簿

            隨筆檔案

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            久久亚洲精品无码VA大香大香| 狠狠久久亚洲欧美专区| 久久久网中文字幕| 蜜臀av性久久久久蜜臀aⅴ麻豆| 久久久久久国产精品免费无码| 国产 亚洲 欧美 另类 久久| 亚洲精品成人久久久| 久久av无码专区亚洲av桃花岛| 天天久久狠狠色综合| 91麻豆国产精品91久久久| 久久精品国内一区二区三区| 尹人香蕉久久99天天拍| 日本三级久久网| 精品久久久久久成人AV| 亚洲国产成人久久综合一区77| 久久综合狠狠色综合伊人| 欧美精品国产综合久久| 久久成人影院精品777| 久久久精品人妻一区二区三区蜜桃| 久久青青草原精品影院| 亚洲成色www久久网站夜月| 久久青青草原精品国产不卡| 香蕉久久夜色精品升级完成| 亚洲伊人久久成综合人影院 | 国产精品免费久久| 国产成人综合久久综合| 无码人妻精品一区二区三区久久 | 久久97精品久久久久久久不卡| 久久精品国产亚洲AV蜜臀色欲| 久久精品中文字幕第23页| 久久免费小视频| 久久青青草原国产精品免费 | 久久香蕉国产线看观看猫咪?v| 久久久久久久尹人综合网亚洲| 97r久久精品国产99国产精| 久久99国产精品尤物| 97久久久久人妻精品专区| 狠狠色丁香婷婷综合久久来| 久久亚洲欧美日本精品| 蜜桃麻豆www久久| 久久精品国产精品亚洲|