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

            天秤座的唐風

            總會有一個人需要你的分享~!- 唐風 -

              C++博客 :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理 ::
              13 隨筆 :: 0 文章 :: 69 評論 :: 0 Trackbacks

            與臨時對象的斗爭(上)

            作者:唐風

            原載:www.cnblogs.com/liyiwen

            C++ 是一門以效率見長的語言(雖然近來越來越多的人“不齒”談及效率,我深以為不然,在某一次的程序編寫中不對效率錙銖必較并不意味意味著我們就不應該追求更多的更好的做法)。總之吧,相比起其它語言,程序員們在使 C++ 的時候會更加有意識地去避免沒有效率的做法。在C++ 的程序中,臨時對象的產生就是損及效率的“惡因”之一,因此也產生出一些意思的技術和優化手段,這篇文章里我總結一下最近在這些方面學習的一些收獲:

            返回值優化(RVO)與具命返回值優化(NRVO)

            這是一項編譯器做的優化,已經是一種很常見的優化手段了,放狗搜一下可以找到很多的資料,在 MSDN 里也有相關的說明。

            返回值優化,顧名思義,就是與返回值有關的優化(廢話……),是當函數是按值返回(而不是引用啊、指針啊)時,為了避免產生不必要的臨時對象以及值拷貝而進行的優化。

            先看看下面的代碼:

            typedef unsigned int UINT32;
            
            class MyCla
            {
            public:
                MyCla(UINT32 a_size = 10):size(a_size) {
                    p = new UINT32[size];        
                }
                MyCla(MyCla const & a_right):size(a_right.size) {
                    p = new UINT32[size];
                    memcpy(p, a_right.p, size*sizeof(UINT32));
                }
                MyCla const& operator = (MyCla const & a_right) {
                    size = a_right.size;
                    p = new UINT32[size];
                    memcpy(p, a_right.p, size*sizeof(UINT32));
                    return *this;
                }
                ~MyCla() {
                    delete [] p;
                }
            private:
                UINT32 *p;
                UINT32 size;
            };
            
            MyCla TestFun() {
                return MyCla();
            }
            
            int _tmain(int argc, _TCHAR* argv[])
            {
                MyCla a = TestFun();
                
                return 0;
            }

            TestFun() 函數返回了一個 MyCla 對象,而且是按值傳遞的。

            在沒有任何“優化”之前,這段代碼的行為也許是這樣的:return MyCla() 這行代碼中,構造了一個 MyCla 類的臨時的無名對象(姑且叫它t1),接著把 t1 拷貝到另一塊臨時對象 t2(不在棧上),然后函數保存好 t2 的地址(放在 eax 寄存器中)后返回,TestFun 的棧區間被“撤消”(這時 t1 也就“沒有”了,t1 的生存域在 TestFun 中,所以被析構了),在 MyCla a = TestFun(); 這一句中,a 利用 t2 的地址,可以找到 t2 進行,接著進行構造。這樣 a 的構造過程就完成了。然后再把 t2 也“干掉”。

            可以看到,在這個過程中,t1 和 t2 這兩個臨時的對象的存在實在是很浪費的,占用空間不說,關鍵是他們都只是為a的構造而存在,a構造完了之后生命也就終結了。既然這兩個臨時的對象對于程序員來說根本就“看不到、摸不著”(匿名對象嘛,你怎么引用?),于是編譯器干脆在里面做點手腳,不生成它們!怎么做呢?很簡單,編譯器“偷偷地”在我們寫的fun函數中增加一個參數 A&,然后把 a 的地址傳進去(注意,這個時候 a 的內存空間已經存在了,但對象還沒有被“構造”,也就是構造函數還沒有被調用),然后在函數體內部,直接用 a 來代替原來的“匿名對象”,在函數體內部就完成 a 的構造。這樣,就省下了兩個臨時變量的開銷。這就是所謂的“返回值優化”~!在 VC7 里,按值返回匿名對象時,默認都是這么做。

            上面說的是“返回值優化(RVO)”,還有一種“具名返回值優化(NRVO)”,是對于按值返回“具名對象”(就是有名字的變量!)時的優化手段,其實道理是一樣的,但由于返回的值是具名變量,情況會復雜很多,所以,能執行優化的條件更苛刻,在下面三種情況下(來自MSDN),NRVO 將一定不起作用:

            1. 不同的返回路徑上返回不同名的對象(比如if XXX 的時候返回x,else的時候返回y)
            2. 引入 EH 狀態的多個返回路徑(就算所有的路徑上返回的都是同一個具名對象)
            3. 在內聯asm語句中引用了返回的對象名。

            不過就算 NRVO 不能進行,在上面的描述中的 t2 這個臨時變量也不會產生,對于 VC 的 C++ 編譯器來說,只要你寫的程序是把對象按值返回的,它會有兩種做法,來避免 t2 的產生。拿下面這個程序來說明:

            MyCla TestFun2() {
                MyCla x(3);
                return x;
            }

            一種做法是像 RVO一樣,把作為表達式中獲取返回值來進行構造的變量 a 當成一個引用參數傳入函數中,然后在返回語句之前,用要返回的那個變量來拷貝構造 a,然后再把這個變量析構,函數返回原調用點,a 就構造好了。

            還有一種方式,是在函數返回的時候,不析構 x ,而直接把 x 的地址放到 exa 寄存器中,返回調到 TestFun2 的調用點上,這時,a 可以用 exa 中存著的地址來進行構造,a 構造完成之后,再析構原來的變量 x !是的,注意到其實這時,x 的生存域已經超出了 TestFun2,但由于這里 x 所在 TestFun2 的棧雖然已經無效,但是并沒有誰去擦寫這塊存,所以 x 其實還是有效的,當然,一切都在匯編的層面,對于 C++ 語言層面來講是透明的。

            嗯,(具名)返回值引用大約就是這么多,在網上和 MSDN 上還能查到更多的例子和解釋,對于在多線程下  (N)RVO 需要注意什么,嗯,我完全沒有多線程的經驗,不敢亂寫誤人子弟……

            右值引用與 move 語意

            “C++ 中臨時對象對效率產生的影響一直為人所詬病”(網上流傳的說法),NRVO 等手段也只有在一定程度上彌補這個不足(你知道,在很多情況下無法做優化)。在 C++98 確定后的十多年時間后,“Cpper神圣”們終于給出了另一個對付它的法寶——右值引用。

            對于右值引用,目前我所見過的最好的講解是VC開發團隊blog中發布的一篇長文(看這里),在CPP blog上飄飄白云的博主進行了全文翻譯(譯得很棒),建議細讀三遍!理解里面每一個例子~這樣至少你在右值引用的認識上就有了良好的基礎了。(嗯,我只讀了兩遍,下面說的東西有錯誤的話請原諒并指出 :) )

            簡單的說,在C++中的左值,就是能取地址的表達式,比如var、++var之類的,右值就不是能取地址的表達式啦,比如常數 123、x++、x+y等等。

            嗯,我們可以看到,右值常常就代表著臨時對象,也就常常意味著“被詬病的浪費……”

            比如,z = x + y,這里,翻譯得更“低層”一點,那么這里將是:

            temp = x + y
            z = temp

            這個temp是很尷尬的,不用它將無法實現正確、良好的 operator + 語意,用它就很難避免臨時對象產生的不良開銷。

            我們回到上面 RVO 中的程序例子:

            MyCla TestFun() {
                return MyCla();
            }

            看,這里返回的 MyCla(),正是一個右值(我們就給它取個名吧,不然不好稱呼它,嗯,還叫 t1 吧)。在函數返回后,這個 t1 就被析構,它做的析構動作就是把原來申請的內存還給系統。想想在這之前,a 在干什么?a 在構造的時候向系統申請了一塊內存!一個申請,一個還回,一來一回多費事啊,如果能直接把 t1 擁有的內存給 a ,就不省事了嗎?反正 t1 馬上就要掛了。好,右值引用給了我們這種機會,我們為 MyCla 實現一個 move 語意的拷貝構造函數(不知道什么是 move 拷貝構造?回頭看上面鏈接的文章三遍!):

            MyCla(MyCla && a_right):size(a_right.size) {
                p = a_right.p;
                a_right.p = NULL;        
            }

            當編譯器探知用于構造 a 的是一個右值時,就調用這個 move 構造函數,然后我們在這個函數里偷梁換柱,把 t1 的資源竊取過來了。這樣,就算不使用 RVO,這個構造的開銷也是非常小的。

            那么,對于像:

            MyCla TestFun2() {
                MyCla x(3);
                return x;
            }

            這樣的情況呢?是的,這里的 x 是一個左值,不會調用 move 構造函數。可是我們知道這個 x 其實馬上也要掛了,它的資源不給白不給啊對不對?所以,我們就想告訴編譯器,您就把它當成個右值吧,怎么告訴它呢?用 std::move 來實現這種 move 語意,像下面這樣:

            MyCla TestFun2() {
                MyCla x(3);
                return std::move(x);
            }
            好啦,這樣又能用上 MyCla 的 move 構造函數啦。

            總結一下,作為右值的臨時對象,其實它的存在就是充當一個傳遞的橋梁,一旦表達式過了這個橋,那么這個臨時對象的存在就沒有意義了,也沒有人能再用到它(因為它是個右值,沒有名字,又不能取地址)。既然如此,一個無人問津的就要“死”的變量,把它擁的的資源搶過來也不算過份吧……。在 C++0x 之前,我們想這么做,但是沒有手段,雖然編譯器能分清楚左值右值,但我們無法通過程序告訴編譯器,如果這是左值,請用這個方法,這個是右值,嘿嘿,那用另一個方法幫我搶它的資源吧……,。到了 C++0x ,我們有手段了,那就是右值引用,這個右值引用可以參與函數的重載,這樣就給了我們機會,針對左右值分別提供不同的操作方法(函數)讓編譯器幫我們選擇一個合適的。

            一般來說,可能需要注意右值引用的地方有:

            當我們寫的類里擁有動態申請的資源時,那么總是應該提供一個move構造函數,這將會帶給很多好處,可以讓這個類的使用者(一般是我們自己函數,或是SDL等庫)利用它來提升效率。

            如果我們寫的函數需要利用傳入的(含有動態申請資源的)對象參數來構造新的變量時,我們可以提供右值引用的重載版本,并在構造新對象時使用std::move來竊取臨時對象的資源。

            右值引用在泛型編程中也有極為重要的作用(它能實現完美轉發),但和本文沒多大關系,就不多說了。

            總之,右值引用是 C++0x 中非常耀眼的一個新的語言特性,VC2010已經將其列入支持范圍(GCC 本人幾乎沒用過,沒了解,不敢妄言[注{ThanksTo OwnWaterloo}:gcc新版本也支持了。 gcc4.4.0 的stl已經加上對move的支持了])。

            從實踐的角度講,它能夠完美地解決 C++ 中長久以來為人們所詬病的臨時對象的效率問題。從語言本身來講,它健全了 C++ 中引用類型在左值右值方面原先的缺陷,從庫的設計者角度講,它給設計者又帶來了一把利器。而對于廣大的庫使用者而言,不動一兵一卒便能獲得“免費”的效率提升。

            牛吧!這個特性如此重要如此有用,幾乎可以想見在支持右值的編譯器一旦實用化,就將產生大量的使用右值引用特性代碼和相關的idioms,也可能會遇到和這個相關的bug,一句話,趁早學吧,出來混,總是會碰上的……。

             

            (上篇完,下篇將分析 Expression Template 在消除臨時變量中的作用,以及對三種方法進行一個總結)

            posted on 2009-12-02 22:11 唐風 閱讀(2775) 評論(15)  編輯 收藏 引用 所屬分類: 語言技術

            評論

            # re: 與臨時對象的斗爭(上) 2009-12-02 22:50 OwnWaterloo
            gcc新版本也支持了。 gcc4.4.0 的stl已經加上對move的支持了。

            沒有右值引用,也可以消除很多臨時變量,只是編程很復雜……
            需要使用一些proxy,用來"記錄""操作與操作數",僅僅是"記錄"。
            只有當出現操作的"接收者"時,操作才被真正執行,直接在接收者上進行操作了。

            當然,有move更好,本來就應該是這樣,對立馬就要消亡的對象,盜取一些資源是很合理的……
            只是不知道c++0x要什么時候才能流行起來……

            看看現在還有N多用vc6的人…… 無語……


              回復  更多評論
              

            # re: 與臨時對象的斗爭(上) 2009-12-02 22:58 OwnWaterloo
            lambda,aotu,decltype這些都是很有用的特性,沒它們有時候真的是相當的不方便……

            而且,lambda完全可以很簡單的純手工模擬一個。
            這種毫無新意的機械復制的事情,本來就應該交給編譯器去做。
            編譯器實現lambda表達式是不需要花什么力氣的。
            只是解析可能會出現麻煩……

            auto、decltype更是容易。
            其實編譯器已經實現了它們,只是沒有暴露出來而已。

            期待c++0x流行啊……

              回復  更多評論
              

            # re: 與臨時對象的斗爭(上) 2009-12-02 23:17 non
            c++0x過于復雜,在大的工程上保守派不敢上。。甚至于stl的都要求少用  回復  更多評論
              

            # re: 與臨時對象的斗爭(上) 2009-12-02 23:18 唐風
            話說 VC6 還真有點像 IE6 ,擁有極高的使用率,但又不能完全支持“標準”,呵呵,不過 VC6 可以原諒,畢竟開發的時候 C++ 標準還沒出臺嘛……

            唉,托 D 版的福,我可是每發布一個新版本就立即升級的,呵呵,不過在公司做項目又沒辦法了,得聽公司技術決策者的,呵,而我們公司那個大牛,MS 習慣 VC6 ……。

            我也很期待 C++0x 呢,對 C++ 很有感情,哈哈

            對于
            【沒有右值引用,也可以消除很多臨時變量,只是編程很復雜……】
            是啊,但通過這些途徑,完成了一些“目標”之后仍然會覺得心中有缺憾,不能用最優雅的方式解決問題的時候總會不舒服,
            就像 Expression Template 被開發出來,我想也是人們想有效率,又想直觀的結果吧……

            PS:
            您還真是快啊~~我這才發布,你就來了。神仙~  回復  更多評論
              

            # re: 與臨時對象的斗爭(上) 2009-12-02 23:29 唐風
            @non
            是有聽這么說的。
            不過我總覺得:不鼓勵或是要求禁用 STL 的組織,肯定得要有牛人實現一套更合適于他們工程的基本類庫,也許他們只是不想要通用的 STL 實現,但 STL 做的那些事,始終還是需要有“人”來做的。
              回復  更多評論
              

            # re: 與臨時對象的斗爭(上) 2009-12-02 23:51 OwnWaterloo
            @唐風
            DB是什么???

            對那些保守黨,就任由他們去吧……
            讓他們在自己的世界里自娛自樂,一次又一次的發明那屬于自己心中完美輪子。
            都復用別人的,他們還怎么好開口向老板要錢啊?
            一定要說:stl對我們的項目都是不適合的! —— 以顯得自己的項目很牛逼。
            然后追加:所以我們自行開發了xxx! —— 以顯得自己很牛逼。


              回復  更多評論
              

            # re: 與臨時對象的斗爭(上) 2009-12-03 00:06 唐風
            @OwnWaterloo
            呃,不好意思,我是想說“盜版”,呵呵
            回想,DB 確實容易聯想成 DataBase,那這句話就不好理解了……
            It's my fault :)


              回復  更多評論
              

            # re: 與臨時對象的斗爭(上) 2009-12-03 00:27 OwnWaterloo
            @唐風
            機器上的vs2005和2008是學校給的…… 據說有個什么政策,學校每年只用付3000元就可以使用大量的正版軟件。
            不過…… 我已經畢業了…… 機器上的還沒刪…… 繼續用著……
            還去下了一個vc10精簡版…… 這肯定是D版了……

            據說vc9有免費的,不含ide。

              回復  更多評論
              

            # re: 與臨時對象的斗爭(上) 2009-12-03 13:36 空明流轉
            @OwnWaterloo
            從2003開始,VS就有Express Edition了,不過僅用于開發非商業授權的軟件。  回復  更多評論
              

            # re: 與臨時對象的斗爭(上) 2009-12-03 16:33 OwnWaterloo
            @空明流轉
            嗯,謝謝~


            如果我只是想用VC的編譯器測試一下可移植性。
            但并不發布VC生成的binary。
            這樣可以么?


            或者,我開發的東西使用的是new BSD或者LGPL之類的許可證,可以使用VC express么?

              回復  更多評論
              

            # re: 與臨時對象的斗爭(上) 2009-12-03 16:40 OwnWaterloo
            @空明流轉
            上面好像沒說清楚…… 我整理一下……

            1. 開發的軟件使用商業許可證。
            發布的binary使用的是,比如mingw,生成的。
            也發布源代碼。
            但發布前使用VC express作移植性測試。
            當然,還包括VC使用的工程文件也會發布。
            有VC授權的人,可以自己使用VC編譯。

            這樣算侵權么?

            2. 開發的軟件使用非商業許可證,比如new BSD或LGPL
            發布源代碼,VC工程文件。侵權么?
            發布VC編譯的binary呢?

              回復  更多評論
              

            # re: 與臨時對象的斗爭(上) 2009-12-04 12:30 YESHG!
            關于這篇的俺的第一篇回復呢?這里是不是會評論失敗?
              回復  更多評論
              

            # re: 與臨時對象的斗爭(上) 2009-12-06 22:25 唐風
            @YESHG!
            你也注冊一個博客園(或是cppblog)的帳戶唄
            對評論和回復有郵件通知,這個功能挺好用的。  回復  更多評論
              

            # re: 與臨時對象的斗爭(上) 2010-03-08 20:50 Jakcie
            寫的不錯。
            我現在用2005。其實VC6,里面Bug還是不少。尤其是MFC里面。2010都出了,至少該用2005吧。
            免費版也有IDE,但沒有很多高級功能和資源編輯器。  回復  更多評論
              

            # re: 與臨時對象的斗爭(上) 2013-02-28 16:51 refugee
            MyCla const& operator = (MyCla const & a_right) {
            size = a_right.size;
            p = new UINT32[size];
            memcpy(p, a_right.p, size*sizeof(UINT32));
            return *this;
            }
            這個賦值重載有點問題,一、沒做自賦值檢查;二、沒釋放原有空間,內存泄露(size一致的可以不釋放,也不用new新空間,直接copy);三、返回值是否有必要用const限制,表達式(a=b)=c不能成立,雖然這表達式本身就有點腦殘。  回復  更多評論
              

            久久久久久国产精品无码超碰| 色诱久久av| 久久精品国产一区二区三区日韩| 99国产欧美精品久久久蜜芽| 国产精品99久久不卡| 日本加勒比久久精品| 亚洲精品午夜国产VA久久成人| 久久电影网2021| 中文字幕久久精品| 欧美一区二区精品久久| 亚洲欧美日韩精品久久亚洲区| 69久久夜色精品国产69| 久久精品一区二区影院| 久久久久高潮毛片免费全部播放 | 国产精品久久久福利| 久久伊人精品青青草原日本| 蜜臀av性久久久久蜜臀aⅴ麻豆 | 亚洲欧洲日产国码无码久久99| 久久婷婷五月综合色奶水99啪 | 久久成人精品视频| 久久久精品人妻一区二区三区蜜桃| 国产91色综合久久免费分享| 精品国产日韩久久亚洲| 精品久久久久一区二区三区| 国产Av激情久久无码天堂| 久久久久免费精品国产| 久久久人妻精品无码一区| 91精品国产综合久久香蕉 | 91秦先生久久久久久久| 久久人人爽爽爽人久久久| 国产精品成人久久久| 伊人久久五月天| 久久伊人精品青青草原日本| 久久e热在这里只有国产中文精品99| 97r久久精品国产99国产精| 少妇久久久久久被弄高潮| 五月丁香综合激情六月久久| 性欧美大战久久久久久久久| 香蕉久久夜色精品升级完成 | 精品久久久久久久久久中文字幕 | 久久久久亚洲精品日久生情|