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

            熱轉印www.yxheatpress.com

            公司網站模板http://qiyemoban.software8.co/

            常用鏈接

            統計

            友情鏈接

            最新評論

            C++中動態資源管理

            昨天看到一個知識點覺得挺有意思的,而且自己還不是很清楚,覺得講得很好。主題是“以對象來管理資源”

            C++中用得最多的就是動態的內存分配,程序中的大部分bug也都是源自于內存泄露,這也是C++相較于其他高級語言更復雜的主要原因之一,不過考慮到它強大的功能和超高的效率,這樣的復雜度也是應該的,所以上天是公平的,有點扯遠了。內存只是我們必須管理的資源之一,其他常用到的資源還包括文件描述符,數據庫連接,socket等,不論是哪種資源,我們用完之后必須要歸還給操作系統,否則就會出現Memory Leak

            看下面一段代碼:

            #include <iostream>

            using namespace std;

            class Widget

            {

            public:

                  Widget()

                  {

                    cout<<"Widget()"<<endl;

                  }

             

                  ~Widget()

                  {

                    cout<<"~Widget()"<<endl;

                  }

             

            };

             

             

            Widget* CreateWidget()

            {

               Widget* pA = new Widget;

               return pA;

            }

            void MaybeMemoryLeak()

            {

               Widget* p = CreateWidget();

               //....

               //....

               //....

               if(p!=NULL)

                  return;

               delete p;

            }

            int main()

            {

                MaybeMemoryLeak();

                cout << "Hello world!" << endl;

                return 0;

            }

            乍一看,這段代碼沒有什么問題,仔細一想,這段代碼確實有問題,而且問題很大。在函數“MaybeMemoryLeak()”中極有可能發生內存泄露,這段代碼執行下來析構函數沒有被調用,也就是發生了內存泄露。原因就在于delete p之前函數已經返回了,所以delete p不會執行。

            有人肯定會說只要保證在delete p之前不執行return語句就可以了。貌似是這樣,但是如果程序都如我們所預想的邏輯那樣跑,那也就沒有bug一說了。即使我們在delete p之前保證沒有return語句,那么第二種可能是delete p語句位于循環內部,然而循環可能在delete p之前執行了continue語句或break語句而提前退出,這樣勢必也會發生內存泄露。有人說我也能保證這種情況不會發生,那么好吧,假如delete p語句之前的代碼發生了異常,那么delete p語句仍然執行不到,我相信任何人沒有敢拍著胸脯說他寫的代碼不會發生異常吧。

            所以這幾種情況造成了我們動態分配的內存很容易發生不能正確回收,從而造成內存泄露。

             

            好了,下面進入本文真正的主題,以對象來管理資源。

            根據對上面代碼的分析,為了確保函數CreateWidget()返回的資源總是能被正確釋放,我們需要將分配的資源放進對象內,當程序執行流離開MaybeMemoryLeak()時,該對象的析構函數會自動釋放那些資源,歧視我的理解是這樣的,對象在函數里就是一個局部變量,無論如何,函數結束該局部變量肯定要被釋放,釋放時又必然會調用該對象的析構函數。正是利用了這一點,我們可能將資源放在對象里,這樣我們便可以來c++析構函數自動調用機制確保資源被正確釋放。

            C++標準程序庫提供的auto_ptr正是針對這種形勢而設計的,auto_ptr是一個類指針對象,也可以理解為一個棧對象,其析構函數自動對其所指對象調用delete,注意是delete,而不是delete []

            所以我們可能將上面的代碼加以修改:

            #include <iostream>

            #include <memory>

            using namespace std;

            class Widget

            {

            public:

                  Widget()

                  {

                    cout<<"Widget()"<<endl;

                  }

             

                  ~Widget()

                  {

                    cout<<"~Widget()"<<endl;

                  }

             

            };

             

             

            Widget* CreateWidget()

            {

               Widget* pA = new Widget;

               return pA;

            }

            void MaybeMemoryLeak()

            {

               auto_ptr<Widget> p(CreateWidget());

               //....

               //....

               //....

               cout<<p.get()<<endl;

            }

            int main()

            {

                MaybeMemoryLeak();

                cout << "Hello world!" << endl;

                return 0;

            }

            下面是程序的執行效果

            可以看到,雖然我們沒有用delete p這樣的語句來釋放p,,但是析構函數仍然被調用,原因就是當對象p在函數MaybeMemoryLeak()返回時自動銷毀而對其所指對象執行delete操作。

            這里只是說明了為什么要以對象來管理資源,否則很容易出現MemoryLeak,具體以對象來管理資源的方法就是用到了智能指針,關于智能指針的用法和注意點這里就不多說了。比如說像auto_ptr復制時不能保值,所以在賦值操作時要特別注意。還有就是auto_ptr不能用作STL容器中的元素等等。

            posted on 2013-04-29 10:44 不聽話的 閱讀(1457) 評論(0)  編輯 收藏 引用

            久久综合日本熟妇| 久久精品国产影库免费看| 色综合久久88色综合天天 | 欧美亚洲日本久久精品| 久久综合亚洲色一区二区三区 | 午夜精品久久久久久中宇| 久久99亚洲网美利坚合众国| 99久久成人国产精品免费| 午夜精品久久影院蜜桃| 性欧美大战久久久久久久久| 91久久精品电影| 久久久久久综合网天天| 久久精品草草草| 久久久久亚洲AV成人网人人网站| 成人国内精品久久久久一区| 青青热久久国产久精品 | 午夜视频久久久久一区 | 亚洲国产综合久久天堂| 精品久久久久久久久午夜福利| 精品久久国产一区二区三区香蕉 | 久久国产精品国产自线拍免费| 午夜精品久久久久9999高清| 久久99国产精品久久99果冻传媒| 一本大道久久东京热无码AV| 91精品国产高清91久久久久久| 精品久久久久成人码免费动漫 | 欧美亚洲国产精品久久高清| 国产精品成人99久久久久| 久久人人妻人人爽人人爽| 久久毛片一区二区| 国内精品久久国产| 思思久久精品在热线热| 婷婷久久综合九色综合绿巨人| 国产精品热久久毛片| 久久精品18| 欧美粉嫩小泬久久久久久久| 久久99精品久久久久久齐齐| 国产福利电影一区二区三区久久老子无码午夜伦不 | 精品久久久久久久中文字幕| 狠狠色综合网站久久久久久久| 国产精品九九久久免费视频|