• <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 魏兵 閱讀(1470) 評論(0)  編輯 收藏 引用

            My Links

            Blog Stats

            常用鏈接

            留言簿

            隨筆檔案

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            武侠古典久久婷婷狼人伊人| 99久久99久久| 久久久精品人妻一区二区三区蜜桃 | 中文字幕无码久久精品青草| 久久夜色精品国产www| 久久亚洲精品无码VA大香大香| 亚洲中文字幕无码一久久区| 久久久青草久久久青草| 久久妇女高潮几次MBA| 丰满少妇人妻久久久久久4| 伊人久久大香线蕉av不卡| 国产成人综合久久精品尤物| 亚洲AV成人无码久久精品老人| 日韩精品国产自在久久现线拍| 久久成人国产精品免费软件| 精品久久久久久无码中文野结衣| 丁香色欲久久久久久综合网| 国产高潮久久免费观看| 青青草原精品99久久精品66| 国产综合久久久久久鬼色| 综合久久给合久久狠狠狠97色| 狠狠狠色丁香婷婷综合久久五月| 一本一道久久综合狠狠老| 手机看片久久高清国产日韩| 亚洲国产精品久久久久婷婷老年| 亚洲国产精品无码久久久秋霞2 | 久久久久人妻精品一区二区三区| 久久久久亚洲AV无码专区网站| 久久精品亚洲精品国产色婷| 久久国产欧美日韩精品| 一本久久免费视频| 久久综合精品国产一区二区三区| 久久青青草原精品影院| 国产精品一久久香蕉国产线看| 久久亚洲中文字幕精品有坂深雪 | 久久精品人人做人人爽电影蜜月| 亚洲国产成人久久综合野外| 一本久久综合亚洲鲁鲁五月天亚洲欧美一区二区 | 波多野结衣中文字幕久久| 色婷婷综合久久久久中文一区二区 | 国产Av激情久久无码天堂|