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

            洛譯小筑

            別來(lái)無(wú)恙,我的老友…
            隨筆 - 45, 文章 - 0, 評(píng)論 - 172, 引用 - 0
            數(shù)據(jù)加載中……

            [ECPP讀書(shū)筆記 條目30] 深入探究?jī)?nèi)聯(lián)函數(shù)

            內(nèi)聯(lián)函數(shù)——多么振奮人心的一項(xiàng)發(fā)明!它們看上去與函數(shù)很相像,它們擁有與函數(shù)類(lèi)似的行為,它們要比宏(參見(jiàn)條目2)好用的多,同時(shí)你在調(diào)用它們時(shí)帶來(lái)的開(kāi)銷(xiāo)比一般函數(shù)小得多。可謂“內(nèi)聯(lián)在手,別無(wú)他求。”

            你得到的遠(yuǎn)遠(yuǎn)比你想象的要多,因?yàn)楣?jié)約函數(shù)調(diào)用的開(kāi)銷(xiāo)僅僅是冰山一角。我們知道編譯器優(yōu)化通常是針對(duì)那些沒(méi)有函數(shù)調(diào)用的代碼,因此當(dāng)你編寫(xiě)內(nèi)聯(lián)函數(shù)時(shí),編譯器就會(huì)針對(duì)函數(shù)體的上下文進(jìn)行優(yōu)化工作。大多數(shù)編譯器都不會(huì)針對(duì)“外聯(lián)”函數(shù)調(diào)用進(jìn)行這樣的優(yōu)化。

            然而,在你的編程生涯中,“沒(méi)有免費(fèi)的午餐”這句生活哲言同樣奏效,內(nèi)聯(lián)函數(shù)也沒(méi)有例外。內(nèi)聯(lián)函數(shù)背后蘊(yùn)含的理念是:用代碼本體來(lái)取代每次函數(shù)調(diào)用,這樣做很可能會(huì)使目標(biāo)代碼的體積增大不少,這一點(diǎn)并不是非要統(tǒng)計(jì)學(xué)博士才能看得清。對(duì)于內(nèi)存空間有限的機(jī)器而言,過(guò)分熱衷于使用內(nèi)聯(lián)則會(huì)造成過(guò)多的空間占用。即使在虛擬內(nèi)存中,那些冗余的內(nèi)聯(lián)代碼也會(huì)帶來(lái)不少無(wú)謂的分頁(yè),從而使緩存讀取命中率降低,最終帶來(lái)性能的犧牲。

            另一方面,如果一個(gè)內(nèi)聯(lián)函數(shù)體非常的短,那么為函數(shù)體所生成代碼的體積則可能會(huì)比調(diào)用函數(shù)所生成的代碼小一些。此時(shí),內(nèi)聯(lián)函數(shù)才真正做到了減小目標(biāo)代碼和提高緩存讀取命中率的目的。

            請(qǐng)時(shí)刻牢記,Inline是對(duì)編譯器的一次請(qǐng)求,而不是一條命令。這種請(qǐng)求可以顯式提出也可以隱式提出。隱式請(qǐng)求的途徑就是:在類(lèi)定義的內(nèi)部定義函數(shù):

            class Person {

            public:

              ...

              int age() const { return theAge; }    // 隱式內(nèi)聯(lián)請(qǐng)求:

              ...                                   // 年齡age在類(lèi)定義中做出定義

             

            private:

              int theAge;

            };

            這樣的函數(shù)通常是成員函數(shù),但是類(lèi)中定義的函數(shù)也可以是友元(參見(jiàn)條目46),如果函數(shù)是友元,那么它們會(huì)被隱式定義為內(nèi)聯(lián)函數(shù)。

            顯式聲明內(nèi)聯(lián)函數(shù)的方法為:在函數(shù)定義之前添加inline關(guān)鍵字。比如說(shuō),下面是標(biāo)準(zhǔn)max模板(來(lái)自<algorithm>)常見(jiàn)的定義方式:

            template<typename T>               // 顯式內(nèi)聯(lián)請(qǐng)求:

            inline const T& std::max(const T& a, const T& b)

            { return a < b ? b : a; }         // std::max的前邊添加”inline”

            max是模板”這一事實(shí),讓我們不免得出這樣的推論:內(nèi)聯(lián)函數(shù)和模板都應(yīng)該定義在頭文件中。這就使一些程序員做出“函數(shù)模板必須是內(nèi)聯(lián)函數(shù)”的論斷。這一結(jié)論不僅站不住腳,而且也存在潛在的害處,所以這里還是要稍稍深入了解一下。

            由于大多數(shù)編程環(huán)境的內(nèi)聯(lián)操作都是在編譯過(guò)程中進(jìn)行的,因此內(nèi)聯(lián)函數(shù)一般都應(yīng)該定義在頭文件中。編譯器必須首先了解函數(shù)的情況,以便于用所調(diào)用函數(shù)體來(lái)代替這次函數(shù)調(diào)用。(一些構(gòu)建環(huán)境在連接過(guò)程中進(jìn)行內(nèi)聯(lián),還有個(gè)別基于.NET通用語(yǔ)言基礎(chǔ)結(jié)構(gòu)(CLI)的環(huán)境甚至是在運(yùn)行時(shí)進(jìn)行內(nèi)聯(lián)。這樣的環(huán)境屬于例外,不是守則。在大多數(shù)C++程序中,內(nèi)聯(lián)是一個(gè)編譯時(shí)行為。)

            模板通常保存在頭文件中,這是因?yàn)榫幾g器需要了解這些模板,以便于在使用時(shí)進(jìn)行正確的實(shí)例化。(再次說(shuō)明,這并不是一成不變的。一些編程環(huán)境在連接時(shí)進(jìn)行模板實(shí)例化。但是編譯時(shí)實(shí)例化是更通用的方式。)

            模板實(shí)例化相對(duì)于內(nèi)聯(lián)是獨(dú)立的。如果你正在編寫(xiě)一個(gè)模板,而你又確信由這個(gè)模板所實(shí)例化出的所有函數(shù)都應(yīng)該是內(nèi)聯(lián)的,那么這個(gè)模板就應(yīng)該添加inline關(guān)鍵字;這也就是上文中std::max實(shí)現(xiàn)的做法。但是如果你正在編寫(xiě)的模板并不需要內(nèi)聯(lián)函數(shù),那么就不要聲明內(nèi)聯(lián)模板(無(wú)論是顯式還是隱式)。內(nèi)聯(lián)也是有開(kāi)銷(xiāo)的,不計(jì)成本的引入內(nèi)聯(lián)并不明智。我們已經(jīng)介紹過(guò)內(nèi)聯(lián)是如何使代碼膨脹起來(lái)的(對(duì)于模板的作者而言,還應(yīng)該做更周密的考慮——參見(jiàn)條目44),但是內(nèi)聯(lián)還會(huì)帶來(lái)其他的開(kāi)銷(xiāo),這就是我們即將討論的問(wèn)題。

            inline是對(duì)編譯器的一次請(qǐng)求,但編譯器可能會(huì)忽略它。”在我們的討論開(kāi)始之前,我們首先要弄清這一點(diǎn)。大多數(shù)編譯器如果認(rèn)為當(dāng)前的函數(shù)過(guò)于復(fù)雜(比如包含循環(huán)或遞歸的函數(shù)),或者這個(gè)函數(shù)是虛函數(shù)(即使是最平常的虛函數(shù)調(diào)用),就會(huì)拒絕將其內(nèi)聯(lián)。后一個(gè)結(jié)論很好理解。因?yàn)?span style="font-family:"Courier New";">virtual意味著“等到運(yùn)行時(shí)再指出要調(diào)用哪個(gè)程序,”而inline意味著“在執(zhí)行程序之前,使用要調(diào)用的函數(shù)來(lái)代替這次調(diào)用。”如果編譯器不知道要調(diào)用哪個(gè)函數(shù),那么它們拒絕內(nèi)聯(lián)函數(shù)體的做法就無(wú)可厚非了。

            綜上所述,我們得出下面的結(jié)論:一個(gè)給定的內(nèi)聯(lián)函數(shù)是否真正的得到內(nèi)聯(lián),取決于你正在使用的構(gòu)建環(huán)境——主要是編譯器。幸運(yùn)的是,大多數(shù)編譯器擁有診斷機(jī)制,如果在內(nèi)聯(lián)某個(gè)函數(shù)時(shí)失敗了,那么編譯器將會(huì)做出警告(參見(jiàn)條目53)。

            有些時(shí)候,即使編譯器認(rèn)為某個(gè)函數(shù)非常適合內(nèi)聯(lián),可是還是會(huì)為它生成一個(gè)函數(shù)體。舉例說(shuō),如果你的程序要取得某個(gè)內(nèi)聯(lián)函數(shù)的地址,那么一般情況下編譯器必須為其創(chuàng)建一個(gè)外聯(lián)的函數(shù)體。編譯器怎么能讓一個(gè)指針去指向一個(gè)不存在的函數(shù)呢?再加上“編譯器一般不會(huì)通過(guò)對(duì)函數(shù)指針的調(diào)用進(jìn)行內(nèi)聯(lián)”這一事實(shí),更能肯定這一結(jié)論:對(duì)于一個(gè)內(nèi)聯(lián)函數(shù)的調(diào)用是否應(yīng)該得到內(nèi)聯(lián),取決于這一調(diào)用是如何進(jìn)行的:

            inline void f() {...}              // 假設(shè)編譯器樂(lè)意于將f的調(diào)用進(jìn)行內(nèi)聯(lián)

            void (*pf)() = f;                  // pf指向f

            ...

            f();                               // 此調(diào)用將被內(nèi)聯(lián),因?yàn)檫@是一次“正常”的調(diào)用

             

            pf();                              // 此調(diào)用很可能不會(huì)被內(nèi)聯(lián),

                                               // 因?yàn)樗峭ㄟ^(guò)一個(gè)函數(shù)指針進(jìn)行的

            即使你從未使用函數(shù)指針,未得到內(nèi)聯(lián)處理的內(nèi)聯(lián)函數(shù)依然會(huì)“陰魂不散”,這是因?yàn)檎{(diào)用函數(shù)指針的不僅僅是程序員。在對(duì)數(shù)組內(nèi)的對(duì)象進(jìn)行構(gòu)造或析構(gòu)的過(guò)程中,編譯器有時(shí)會(huì)生成構(gòu)造函數(shù)和析構(gòu)函數(shù)的不恰當(dāng)?shù)陌姹荆瑥亩顾鼈兛梢缘玫竭@些函數(shù)的指針以便使用。

            實(shí)際上,為構(gòu)造函數(shù)和析構(gòu)函數(shù)進(jìn)行內(nèi)聯(lián)通常不是一個(gè)最佳選擇。請(qǐng)看下面示例中Derived類(lèi)的構(gòu)造函數(shù):

            class Base {

            public:

             ...

            private:

               std::string bm1, bm2;           // 基類(lèi)成員12

            };

             

            class Derived: public Base {

            public:

              Derived() {}                     // 派生類(lèi)的構(gòu)造函數(shù)為空還有別的可能?

              ...

            private:

              std::string dm1, dm2, dm3;       // 派生類(lèi)成員 1–3

            };

            乍看上去,將這個(gè)構(gòu)造函數(shù)進(jìn)行內(nèi)聯(lián)再適合不過(guò)了,因?yàn)樗话魏未a。但是你的眼睛欺騙了你。

            C++對(duì)于在創(chuàng)建和銷(xiāo)毀對(duì)象的過(guò)程中發(fā)生的事件進(jìn)行了多方面的保證。比如,當(dāng)你使用new時(shí),你動(dòng)態(tài)創(chuàng)建的對(duì)象就會(huì)通過(guò)構(gòu)造函數(shù)將其自動(dòng)初始化;當(dāng)你使用delete時(shí),將調(diào)用相關(guān)的析構(gòu)函數(shù)。當(dāng)你創(chuàng)建一個(gè)對(duì)象時(shí),該對(duì)象的所有基類(lèi)和所有數(shù)據(jù)成員將自動(dòng)得到構(gòu)造,在銷(xiāo)毀這個(gè)對(duì)象時(shí),相關(guān)的析構(gòu)過(guò)程將會(huì)以反方向自動(dòng)進(jìn)行。如果在對(duì)象的構(gòu)造過(guò)程中有異常拋出,那么對(duì)象中已經(jīng)得到構(gòu)造的部分將統(tǒng)統(tǒng)被自動(dòng)銷(xiāo)毀。在所有這些場(chǎng)景中,C++告訴你什么一定會(huì)發(fā)生,但它沒(méi)有說(shuō)明如何發(fā)生。這一點(diǎn)取決于編譯器的實(shí)現(xiàn)者,但是必須要清楚的一點(diǎn)是,這些事情并不是自發(fā)的。你必須要在程序中添加一些代碼來(lái)實(shí)現(xiàn)它們。這些代碼一定存在于某處,它們由編譯器代勞,在編譯過(guò)程中插入你的程序中。一些時(shí)候它們就存在于構(gòu)造函數(shù)和析構(gòu)函數(shù)中,所以,上文中Derived構(gòu)造函數(shù)雖然看似是空的,但我們可以想象其與以下的具體實(shí)現(xiàn)中生成的代碼是等價(jià)的:

            Derived::Derived()                    // Derived“空”構(gòu)造函數(shù)實(shí)現(xiàn):概念版

            {

             Base::Base();                        // 初始化Base部分

             

             try { dm1.std::string::string(); }   // 嘗試構(gòu)造dm1

             catch (...) {                        // 如果拋出異常,

               Base::~Base();                     // 銷(xiāo)毀基類(lèi)部分,

               throw;                             // 并且傳播該異常

             }

             

             try { dm2.std::string::string(); }   // 嘗試構(gòu)造dm2

             catch(...) {                         // 如果拋出異常,

               dm1.std::string::~string();        // 銷(xiāo)毀dm1,

               Base::~Base();                     // 銷(xiāo)毀基類(lèi)部分,

               throw;                             // 并且傳播該異常

             }

             

             try { dm3.std::string::string(); }   // 嘗試構(gòu)造dm3

             catch(...) {                         // 如果拋出異常,

               dm2.std::string::~string();        // 銷(xiāo)毀dm2,

               dm1.std::string::~string();        // 銷(xiāo)毀dm1,

               Base::~Base();                     // 銷(xiāo)毀基類(lèi)部分,

               throw;                             // 并且傳播該異常

             }

            }

            這段代碼并不能完全反映出真實(shí)的編譯器所做的事情,因?yàn)檎鎸?shí)的編譯器采用的做法更加精密。然而,上面的代碼可以精確地反映出Derived的“空”構(gòu)造函數(shù)必須提供的內(nèi)容。無(wú)論編譯器處理異常的實(shí)現(xiàn)方式多么精密,Derived的構(gòu)造函數(shù)必須至少為其數(shù)據(jù)成員和基類(lèi)調(diào)用構(gòu)造函數(shù),這些調(diào)用(可能就是內(nèi)聯(lián)的)會(huì)使Derived顯得不那么適合進(jìn)行內(nèi)聯(lián)。

            這一推理過(guò)程對(duì)于Base的構(gòu)造函數(shù)同樣適用,因此如果將Base內(nèi)聯(lián),所有添加進(jìn)其中的代碼同樣也會(huì)添加進(jìn)Derived的構(gòu)造函數(shù)中(通過(guò)Derived構(gòu)造函數(shù)調(diào)用Base構(gòu)造函數(shù)的過(guò)程)。同時(shí),如果string的構(gòu)造函數(shù)恰巧是內(nèi)聯(lián)的,那么Derived的構(gòu)造函數(shù)將為其復(fù)制出五份副本,分別對(duì)應(yīng)Derived對(duì)象中包含的五個(gè)字符串(兩個(gè)繼承而來(lái),另外三個(gè)系對(duì)象本身包括)。至于為什么“Derived的構(gòu)造函數(shù)是否該內(nèi)聯(lián)須深思熟慮”,現(xiàn)在可能就很容易理解了。對(duì)于Derived的析構(gòu)函數(shù)也一樣,無(wú)論如何,由Derived的構(gòu)造函數(shù)所初始化的所有對(duì)象必須全部恰當(dāng)?shù)牡玫戒N(xiāo)毀。

            庫(kù)設(shè)計(jì)者必須估算出將函數(shù)內(nèi)聯(lián)所帶來(lái)的影響,因?yàn)槟銦o(wú)法為庫(kù)中的客戶(hù)可見(jiàn)的內(nèi)聯(lián)函數(shù)提供目標(biāo)代碼級(jí)別的升級(jí)。換句話(huà)說(shuō),如果f是庫(kù)中的一個(gè)內(nèi)聯(lián)函數(shù),那么庫(kù)的客戶(hù)就會(huì)將f的函數(shù)體編譯進(jìn)他們的程序中。如果一個(gè)庫(kù)實(shí)現(xiàn)者在后期修改了f的內(nèi)容,那么所有曾經(jīng)使用過(guò)f的客戶(hù)必須要重新編譯。這一點(diǎn)是我們所不希望看到的。另一個(gè)角度講,如果f不是內(nèi)聯(lián)函數(shù),那么修改f只需要客戶(hù)重新連接一下就可以了。這樣要比重新編譯減少很多繁雜的工作,并且,如果庫(kù)中需要使用的函數(shù)是動(dòng)態(tài)鏈接的,那么它對(duì)于客戶(hù)就是完全透明的。

            從開(kāi)發(fā)優(yōu)質(zhì)程序的角度講,這些重要問(wèn)題應(yīng)時(shí)刻牢記。但是以編寫(xiě)代碼實(shí)際操作的角度來(lái)說(shuō),這一個(gè)事實(shí)將淹沒(méi)一切:大多數(shù)調(diào)試人員面對(duì)內(nèi)聯(lián)函數(shù)時(shí)會(huì)遇到麻煩。這并不會(huì)令人意外,你如何為一個(gè)不存在的函數(shù)設(shè)定一個(gè)跟蹤點(diǎn)呢?盡管一些構(gòu)建環(huán)境提供了內(nèi)聯(lián)函數(shù)調(diào)試的支持,但是大多數(shù)環(huán)境都在調(diào)試過(guò)程中直接禁止內(nèi)聯(lián)。

            對(duì)于“哪個(gè)函數(shù)應(yīng)該聲明為inline而哪些不應(yīng)該”這一問(wèn)題,我們可以由上文中引出一個(gè)邏輯上的策略。起初,不要內(nèi)聯(lián)任何內(nèi)容,或者僅挑選出那些不得不內(nèi)聯(lián)的函數(shù)(參見(jiàn)條目46)或者那些確實(shí)是很細(xì)小的程序(比如本節(jié)開(kāi)篇處出現(xiàn)的Person::age)進(jìn)行內(nèi)聯(lián)。謹(jǐn)慎引入內(nèi)聯(lián),你就為調(diào)試工作提供了方便,但是你仍然要為內(nèi)聯(lián)擺正位置:它屬于手工的優(yōu)化操作。不要忘記80-20經(jīng)驗(yàn)決定主義原則:一個(gè)典型的程序?qū)⒒ㄈ?0%的時(shí)間僅僅運(yùn)行20%的代碼。這是一個(gè)非常重要的原則,因?yàn)樗嵝阎覀冘浖_(kāi)發(fā)者的目標(biāo):找出你的代碼中20%的這部分進(jìn)行優(yōu)化,從而從整體上提高程序的性能。你可以花費(fèi)漫長(zhǎng)的時(shí)間進(jìn)行內(nèi)聯(lián)、修改函數(shù)等等,但如果你沒(méi)有鎖定正確的目標(biāo),那么你做再多的努力也是徒勞。

            時(shí)刻牢記

            僅僅對(duì)小型的、調(diào)用頻率高的程序進(jìn)行內(nèi)聯(lián)。這將簡(jiǎn)化你的調(diào)試操作,提供更靈活的目標(biāo)代碼可更新性,降低潛在的代碼膨脹發(fā)生的可能,并且可以讓程序獲得更高的速度。

            不要將模板聲明為inline的,因?yàn)樗鼈円话阍陬^文件中出現(xiàn)。

            posted on 2007-11-18 23:27 ★ROY★ 閱讀(1609) 評(píng)論(1)  編輯 收藏 引用 所屬分類(lèi): Effective C++

            評(píng)論

            # re: 【讀書(shū)筆記】[Effective C++第3版][第30條] 深入探究?jī)?nèi)聯(lián)函數(shù)  回復(fù)  更多評(píng)論   

            我怎么看ACE的源碼里這么多宏,他還是高性能框架呢
            2007-11-19 21:22 | evoup
            久久精品国产精品亜洲毛片| 久久一区二区三区99| 一本色道久久88精品综合| 久久精品国产亚洲AV影院| 97久久天天综合色天天综合色hd| 久久精品国产亚洲AV麻豆网站| 久久久青草青青亚洲国产免观| 久久亚洲中文字幕精品一区| 99久久精品免费看国产一区二区三区| 精品国产乱码久久久久久郑州公司| 久久久久夜夜夜精品国产| 久久强奷乱码老熟女网站| 91超碰碰碰碰久久久久久综合| 一日本道伊人久久综合影| 精品国产福利久久久| 亚洲午夜精品久久久久久浪潮| 青青草原精品99久久精品66| 国产成人久久久精品二区三区 | 一日本道伊人久久综合影| 国产亚洲欧美成人久久片| 亚洲国产精品无码久久久不卡| 久久91精品综合国产首页| 国产精品禁18久久久夂久| 免费久久人人爽人人爽av| 精品久久久久久久中文字幕| 欧美黑人又粗又大久久久| 国产精品久久久久蜜芽| 久久国产成人午夜aⅴ影院 | 亚洲精品蜜桃久久久久久| 久久无码精品一区二区三区| 久久久久久久99精品免费观看| 久久精品亚洲精品国产色婷| 久久久久久国产a免费观看黄色大片| 国产成人无码精品久久久免费 | 久久男人Av资源网站无码软件| 久久精品国产亚洲av麻豆图片| 综合久久一区二区三区 | 午夜精品久久久久久99热| 国内精品久久久久影院薰衣草| 99久久精品国产一区二区三区 | 色综合久久中文字幕无码|