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

            常用鏈接

            留言簿

            隨筆檔案

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            久久久久久久综合日本亚洲| 久久久久免费视频| www.久久精品| 日本亚洲色大成网站WWW久久| 久久久久亚洲AV无码观看| 国内精品久久国产大陆| 理论片午午伦夜理片久久| 久久久久女人精品毛片| 26uuu久久五月天| 99蜜桃臀久久久欧美精品网站| 日本久久久久久中文字幕| 一级做a爰片久久毛片看看| 久久国产乱子伦精品免费强| 久久久久久久免费视频| 亚洲伊人久久大香线蕉苏妲己| 亚洲精品高清国产一线久久| 久久久久久亚洲精品不卡| 久久久噜噜噜久久熟女AA片| 久久久久亚洲AV成人网人人网站| 亚洲国产天堂久久综合网站| 久久精品人人做人人妻人人玩| 亚洲精品高清一二区久久| 999久久久免费国产精品播放| 国产精品18久久久久久vr| 国产精品99久久久精品无码| 久久久久国产视频电影| 国产精品美女久久久| 国产美女久久精品香蕉69| 亚洲国产精品成人久久| 亚洲精品美女久久久久99| 久久人人爽人人爽人人片av麻烦| 香蕉久久一区二区不卡无毒影院 | 久久久久亚洲精品无码网址 | 青春久久| 伊人久久大香线蕉精品不卡| 久久婷婷人人澡人人| 久久九九久精品国产免费直播| 国产精品欧美久久久久无广告| 91久久精品国产成人久久| 亚洲午夜精品久久久久久人妖| 久久福利青草精品资源站免费|