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

             

            C++ RAII

                RAII是resource acquisition 
            is initialization的縮寫,意為“資源獲取即初始化”。它是C++之父Bjarne Stroustrup提出的設計理念,其核心是把資源和對象的生命周期綁定,對象創(chuàng)建獲取資源,對象銷毀釋放資源。在RAII的指導下,C++把底層的資源管理問題提升到了對象生命周期管理的更高層次。
                說起來,RAII的含義倒也不算復雜。用白話說就是:在類的構造函數(shù)中分配資源,在析構函數(shù)中釋放資源。這樣,當一個對象創(chuàng)建的時候,構造函數(shù)會自動地被調(diào)用;而當這個對象被釋放的時候,析構函數(shù)也會被自動調(diào)用。于是乎,一個對象的生命期結束后將會不再占用資源,資源的使用是安全可靠的。
            C
            ++ RAII體現(xiàn)出了簡潔、安全、實時的特點:

            1.概念簡潔性:讓資源(包括內(nèi)存和非內(nèi)存資源)和對象的生命周期綁定,資源類的設計者只需用在類定義內(nèi)部處理資源問題,提高了程序的可維護性
            2.類型安全性:通過資源代理對象包裝資源(指針變量),并利用運算符重載提供指針運算方便使用,但對外暴露類型安全的接口
            3.異常安全性:棧語義保證對象析構函數(shù)的調(diào)用,提高了程序的健壯性
            4.釋放實時性:和GC相比,RAII達到了和手動釋放資源一樣的實時性,因此可以承擔底層開發(fā)的重任

            也許你還在驚訝RAII如此簡單的時候,關于RAII的主要內(nèi)容已經(jīng)介紹完了。簡單不意味著簡陋,在我看來RAII雖然不像GC一樣,是一套具體的機制,但它蘊含的對象與資源關系的哲學深度的理解卻使得我對Bjarne Stroustrup肅然起敬!

            最后,不得不提醒RAII的理念固然簡單,不過在具體實現(xiàn)的時候仍有需要小心的地方。比如對于STL的auto_ptr,可以視為資源的代理對象,auto_ptr對象間的賦值是一個需要特別注意的地方。簡單說來資源代理對象間賦值的語義不滿足“賦值相等”,其語義是資源管理權的轉移。

            什么是“賦值相等”呢?比如:

            int a;  int b = 10;  a = b; //這句話執(zhí)行后 a == b 但對于資源代理對象,這是不滿足的,比如:

            auto_ptr
            <int> a(null);  auto_ptr<int> b(new int(123));  a = b; //這句話執(zhí)行后a != b,賦值的語義是b把資源的管理權交給了a 

            auto_ptr是這樣一種指針:它是“它所指向的對象”的擁有者。這種擁有具有唯一性,即一個對象只能有一個擁有者,嚴禁一物二主。當auto_ptr指針被摧毀時,它所指向的對象也將被隱式銷毀,即使程序中有異常發(fā)生,auto_ptr所指向的對象也將被銷毀。


            關于auto_ptr的幾種注意事項:
            1、auto_ptr不能共享所有權。
            2、auto_ptr不能指向數(shù)組
            3、auto_ptr不能作為容器的成員。
            4、不能通過賦值操作來初始化auto_ptr
            std::auto_ptr
            <int> p(new int(42));     //OK
            std::auto_ptr<int> p = new int(42);    //ERROR
            這是因為auto_ptr 的構造函數(shù)被定義為了explicit
            5、不要把auto_ptr放入容器

            下面便是在C
            ++中實現(xiàn)RAII的典型代碼:
            class file
            {
            public:
                file(
            string const& name) {
                    m_fileHandle
            =fopen(name.cstr());
                }
                
            ~file() {
                    fclose(m_fileHandle);
                }
                
            //
            private:
                handle m_fileHandle;
            }

            很典型的“在構造函數(shù)里獲取,在析構函數(shù)里釋放”。如果我寫下代碼:   
            void fun1() {
                file myfile(
            "my.txt");
                 
            //操作文件
            //此處銷毀對象,調(diào)用析構函數(shù),釋放資源
            當函數(shù)結束時,局部對象myfile的生命周期也結束了,析構函數(shù)便會被調(diào)用,資源會得到釋放。而且,如果函數(shù)中的代碼拋出異常,那么析構函數(shù)也會被調(diào)用,資源同樣會得到釋放。所以,在RAII下,不僅僅資源安全,也是異常安全的。

            但是,在如下的代碼中,資源不是安全的,盡管我們實現(xiàn)了RAII:
            void fun2() {
                file pfile
            =new file("my.txt");
                 
            //操作文件
            }
            因為我們在堆上創(chuàng)建了一個對象(通過new),但是卻沒有釋放它。我們必須運用delete操作符顯式地加以釋放:
            void fun3() {
                file pfile
            =new file("my.txt");
                 
            //操作文件
                    delete pfile;
            }
            否則,非但對象中的資源得不到釋放,連對象本身的內(nèi)存也得不到回收。(將來,C
            ++的標準中將會引入GC(垃圾收集),但正如下面分析的那樣,GC依然無法確保資源的安全)。
            現(xiàn)在,在fun3(),資源是安全的,但卻不是異常安全的。因為一旦函數(shù)中拋出異常,那么delete pfile;這句代碼將沒有機會被執(zhí)行。

            C
            ++領域的諸位大牛們告誡我們:如果想要在沒有GC的情況下確保資源安全和異常安全,那么請使用智能指針:
            void fun4() {
                auto_ptr
            <file> spfile(new file("my.txt"));
                 
            //操作文件
            //此處,spfile結束生命周期的時候,會釋放(delete)對象
            那么,智能指針又是怎么做到的呢?下面的代碼告訴你其中的把戲(關于智能指針的更進一步的內(nèi)容,請參考std::auto_ptr,boost或shared_ptr的智能指針)。
            也就是說,智能指針通過RAII來確保內(nèi)存資源的安全,也間接地使得對象上的RAII得到實施。不過,這里的RAII并不是十分嚴格:對象(所占的內(nèi)存也是資源)的創(chuàng)建(資源獲取)是在構造函數(shù)之外進行的。廣義上,我們也把它劃歸RAII范疇。
            但是,Matthew Wilson在《Imperfect C
            ++》一書中,將其獨立出來,稱其為RRID(Resource Release Is Destruction)。
            RRID的實施需要在類的開發(fā)者和使用者之間建立契約,采用相同的方法獲取和釋放資源。比如,如果在shared_ptr構造時使用malloc(),便會出現(xiàn)問題,因為shared_ptr是通過delete釋放對象的。

            posted on 2011-03-22 14:25 天下 閱讀(9429) 評論(0)  編輯 收藏 引用 所屬分類: C/C++C++必殺技法

            <2010年11月>
            31123456
            78910111213
            14151617181920
            21222324252627
            2829301234
            567891011

            導航

            統(tǒng)計

            常用鏈接

            留言簿(4)

            隨筆分類(378)

            隨筆檔案(329)

            鏈接

            最新隨筆

            搜索

            最新評論

            日韩影院久久| 女人高潮久久久叫人喷水| 久久这里只有精品18| 久久66热人妻偷产精品9| 91久久精品91久久性色| 久久91这里精品国产2020| 久久久久99这里有精品10 | 久久99精品国产| 久久久精品国产Sm最大网站| 无码人妻久久一区二区三区蜜桃| 欧美熟妇另类久久久久久不卡| Xx性欧美肥妇精品久久久久久| 久久久久久精品免费看SSS| 久久r热这里有精品视频| 亚洲欧美日韩精品久久亚洲区| 精品久久久久久无码专区| 久久黄色视频| 久久成人影院精品777| 久久天天躁夜夜躁狠狠躁2022 | 久久人人爽人人爽人人片AV高清 | 国产精品伊人久久伊人电影| 亚洲а∨天堂久久精品| 久久精品国产91久久综合麻豆自制| 久久91精品国产91| 久久精品这里只有精99品| 亚洲午夜久久久精品影院| 久久久久久亚洲AV无码专区| 久久99久久99精品免视看动漫| 亚洲午夜精品久久久久久浪潮 | 久久伊人精品青青草原高清| 久久九九久精品国产免费直播| 四虎影视久久久免费观看| 草草久久久无码国产专区| 国产精品视频久久久| 高清免费久久午夜精品| 久久青青草原精品国产| 久久国产精品无码HDAV| 久久综合噜噜激激的五月天| 人妻精品久久无码专区精东影业| 久久精品国产精品亚洲精品| 亚洲中文字幕无码一久久区|