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

            洛譯小筑

            別來無恙,我的老友…
            隨筆 - 45, 文章 - 0, 評論 - 172, 引用 - 0
            數據加載中……

            [ECPP讀書筆記 條目14] 要注意資源管理類中的復制行為

            條目13中介紹了“資源獲取即初始化”(Resource Acquisition Is Initialization,簡稱RAII)的概念,它是資源管理的中心內容。同時條目13中還使用auto_ptrtr1::shared_ptr作為示例,描述了如何利用這一概念來管理堆上的資源。然而并不是所有的資源都分配于堆上,對于不分配于堆上的資源,諸如auto_ptrtr1::shared_ptr這一類的智能指針并不適合于處理它們。這是千真萬確的,你必須不時地自己動手,創建自己的資源管理類。

            舉例說,你正使用一個C版本的API所提供的lockunlock函數來處理Mutex類型的互斥對象:

            void lock(Mutex *pm);              // 通過pm為互斥量上鎖

            void unlock(Mutex *pm);            // 為互斥量解鎖

            為了確保你曾上鎖的互斥量都得到解鎖,你應該自己編寫一個類來管理互斥鎖。這樣的類的基本結構應遵循RAII的原理,那就是:資源在構造過程中獲得,在析構過程中釋放:

            class Lock {

            public:

              explicit Lock(Mutex *pm)

              : mutexPtr(pm)

              { lock(mutexPtr); }                   // 獲取資源

             

              ~Lock() { unlock(mutexPtr); }         // 釋放資源

             

            private:

              Mutex *mutexPtr;

            };

            客戶通過傳統的RAII風格來使用Lock類:

            Mutex m;                           // 定義互斥量以便使用

            ...

            {                                  // 創建程序塊用來定義臨界區

             Lock ml(&m);                      // 為互斥量上鎖

            ...                                // 進行臨界區操作

            }                                  // 在程序塊末尾互斥量將自動解鎖

            這樣可以正常工作,但是如果復制一個Lock對象,將會發生些什么呢?

            Lock ml1(&m);                      // m上鎖

             

            Lock ml2(ml1);                     // ml1復制給ml2

                                               // 將會發生什么呢?

            有一個問題是所有的RAII類創建者必須面對的,那就是:當復制一個RAII對象時應做些什么。以上是對于這個一般化問題的一個較具體的示例。大多數時候,以下四種可行的方案供你選擇。

            禁止復制。在許多情況下,允許RAII被復制沒有任何意義。比如對于Lock類來說就是這樣,因為復制同步原型在大多數情況下都沒有什么意義。當復制一個RAII類無意義時,你就應該禁止它。條目6中詳細介紹了實現方法:將拷貝賦值運算符聲明為私有的。對于Lock而言,應該是下面的情形:

            class Lock: private Uncopyable {      // 防止復制 參見條目6

            public:

             ...                                   // 同上

            };

            為潛在生成的資源進行引用計數。有時,我們期望能保留對一個資源的所有權,直到其所涉及的最后一個對象被刪除為止。在這種情況下,復制一個RAII對象將會添加一個引用資源對象的計數。這就是tr1::shared_ptr所使用的“復制”的含義。

            通常情況下,RAII類可以通過包含一個tr1::shared_ptr數據成員來實現引用計數復制行為。舉例說,如果Lock在設計時之初就期望使用引用計數,它可能會用tr1::shared_ptr<Mutex>代替Mutex*來作為mutexPtr的類型。但是不幸的是,tr1::shared_ptr默認的行為是:當引用計數值變為零時,刪除其所指向的內容,但這不是我們想要的。當一個Mutex用完時,我們希望對其進行的操作是解鎖,而不是刪除它。

            所幸的是,tr1::shared_ptr允許指定一個“刪除器”,它是一個函數或一個函數對象,用于在引用計數值為零時進行調用。(auto_ptr并不包含這一特性,它總是刪除它所指向的內容。)刪除器是tr1::shared_ptr構造函數的第二個(可選的)參數,所以代碼應該是這樣的:

            class Lock {

            public:

              explicit Lock(Mutex *pm)     // 初始化shared_ptr,參數為

              : mutexPtr(pm, unlock)       // 指向Mutex的指針和解鎖函數

             

                lock(mutexPtr.get());      // 關于"get"的信息請參見條目15

              }

             

            private:

              std::tr1::shared_ptr<Mutex> mutexPtr;

            };                             // 使用shared_ptr而不是原始指針

            在本示例中,請注意Lock類不再聲明析構函數。這是因為我們不再需要它了。條目5中介紹了類的析構函數(無論是編譯器自動生成的還是用戶自定義的)會自動為類的非靜態數據成員進行析構。就像本示例中的mutexPtr。然而,當互斥量的引用計數變為零時,mutexPtr將會自動調用tr1::shared_ptr的刪除器unlock。(此時如果你為代碼添加了一段注釋,告訴人們你并沒有忘記編寫析構函數,你只是借助了默認的編譯器行為。人們看了這樣的注釋思路會更清晰一些。他們會感激你的。)

            復制潛在生成的資源。一些時候,你可以在需要的情況下為資源復制出任意份數的副本,此時你需要一個資源管理類的唯一理由就是:確保每份副本在其工作完成之后得到釋放。在這種情況下,復制資源管理對象的同時,也要復制出其所涉及的資源。也可以說,復制一個資源管理對象時,將進行“深度復制”。

            標準string類型的一些實現版本中,包含著一個指向堆內存的指針,這個指針所指向的就是字符串所保存的位置。這樣的string對象包含著一個指向堆內存的指針。當一個string對象被復制時,將同時復制這一指針和其指向的內存。這樣的string就進行了一次深度復制。

            傳遞潛在生成資源的所有權。在少數情況下,你可能需要確保僅僅有一個RAII對象引用了一個原始的資源,當復制這一RAII對象時,資源的所有權也將從源對象傳遞到目標對象。如同條目13中所解釋的,這是通過auto_ptr所實現的“復制”的含義。

            拷貝函數(拷貝構造函數和拷貝賦值運算符)可以由編譯器自動生成,但是如果編譯器自動生成版本無法滿足你的需要(條目5中解釋了C++的默認行為),你就應該自己編寫這些函數。在一些情況下,你可能還會需要支持這些函數的一般化的版本。這些版本將在條目45中介紹。

            時刻牢記

            由于復制一個RAII對象必須要同時復制其所管理的資源,因此資源的復制行為決定RAII對象的復制行為。

            RAII類有兩種一般性的復制行為:禁止復制和進行資源計數。同時其他的行為也是可能存在的。

            posted on 2007-05-11 18:40 ★ROY★ 閱讀(942) 評論(1)  編輯 收藏 引用 所屬分類: Effective C++

            評論

            # re: 【翻譯】[Effective C++第三版?中文版][第14條]要留心資源管理類中的復制行為  回復  更多評論   

            boost的scoped_ptr使用的第一個策略:禁止復制

            :)
            2007-05-23 10:15 | recorder
            91久久九九无码成人网站| 久久久久久无码Av成人影院| 久久一区二区三区免费| 亚洲美日韩Av中文字幕无码久久久妻妇 | 国产精品伊人久久伊人电影| 国产亚洲精午夜久久久久久| 久久综合久久鬼色| 久久久久高潮综合影院| 9久久9久久精品| 青青热久久国产久精品| 亚洲av日韩精品久久久久久a| 国产精品国色综合久久| 国内精品久久久久久久涩爱 | 久久久精品2019免费观看| 99久久精品免费看国产免费| 亚洲日本va午夜中文字幕久久 | 国内精品伊人久久久久av一坑| 成人a毛片久久免费播放| 久久亚洲精品无码aⅴ大香 | 久久免费美女视频| 久久这里的只有是精品23| 久久婷婷国产麻豆91天堂| 久久天天躁夜夜躁狠狠| 91久久国产视频| 久久国产精品77777| 伊人久久国产免费观看视频| 婷婷综合久久狠狠色99h| 久久久无码精品亚洲日韩京东传媒 | 久久久久国产一区二区| 久久精品国产亚洲AV无码偷窥 | 久久久久久久综合日本| 99re久久精品国产首页2020| 欧美精品乱码99久久蜜桃| 精品无码久久久久久久久久| 久久精品国产亚洲AV香蕉| 久久久久久久久久久精品尤物| 久久九九免费高清视频| 99久久综合国产精品二区| 精品久久久久久成人AV| 国产A三级久久精品| 久久毛片一区二区|