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

            常用鏈接

            留言簿

            隨筆檔案

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            色婷婷久久久SWAG精品| 99久久精品午夜一区二区| 久久免费观看视频| 国产精品中文久久久久久久| AV无码久久久久不卡蜜桃| 久久国产精品一区| 日韩久久久久中文字幕人妻 | 久久青青草原精品国产| 国产V亚洲V天堂无码久久久| 久久国产一片免费观看| 久久久噜噜噜久久熟女AA片| 久久本道久久综合伊人| 乱亲女H秽乱长久久久| 一本久道久久综合狠狠爱| WWW婷婷AV久久久影片| 国产亚州精品女人久久久久久| 久久久久久久久66精品片| 国产精品亚洲美女久久久| 久久超乳爆乳中文字幕| 亚洲欧洲久久av| 久久精品国产福利国产琪琪| 久久ZYZ资源站无码中文动漫| 亚洲一区精品伊人久久伊人| 久久99精品久久久久久9蜜桃 | 久久国产乱子精品免费女| 国产精品久久久久…| 狠狠色婷婷久久综合频道日韩| 欧美午夜A∨大片久久| 久久久久亚洲AV无码专区网站| 亚洲午夜久久久精品影院 | 亚洲综合熟女久久久30p| 人人妻久久人人澡人人爽人人精品| 草草久久久无码国产专区| 久久精品国产91久久综合麻豆自制 | 久久久久久久免费视频| 久久久久久午夜精品| 色老头网站久久网| 精品久久久久久中文字幕大豆网| 亚洲欧洲精品成人久久曰影片| 久久免费视频1| jizzjizz国产精品久久|