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

            兔子的技術博客

            兔子

               :: 首頁 :: 聯(lián)系 :: 聚合  :: 管理
              202 Posts :: 0 Stories :: 43 Comments :: 0 Trackbacks

            留言簿(10)

            最新評論

            閱讀排行榜

            評論排行榜

            以前知道,在一個模塊中 new 一塊內存,然后在其它模塊中釋放,會導致異常。 但這次出現(xiàn)的問題比較古怪,剛開始根本沒想到是內存的原因。
            查找原因比較曲折,但后來用虛函數(shù)的方法解決了問題,沒有修改代碼邏輯,感覺還是比較巧妙的^_^
            執(zhí)行環(huán)境簡單介紹如下:
            一個靜態(tài)庫工程 MyShare.lib ,關鍵代碼如下:

             
            // CMyObject 類部分代碼

             
            class CMyObject
             {
             
            public:
                 CMyClient 
            *m_pParent;
                 
            void FinalObject();            
             };
             

            void CMyObject::FinalObject()
            {
                
                m_pParent
            ->UnBand(this);    
                
            }

            // CMyClient 類部分代碼

            class CMyClient
            {
                std::map
            <CMyObject *,int> m_mapObjects;
            public:
                
            void Band(CMyObject *pObject);
                
            void UnBand(CMyObject *pObject);
            };

            void CMyClient::Band(CMyObject *pObject)
            {
                m_mapObjects[pObject] 
            = 1;
            }

            void CMyClient::UnBand(CMyObject *pObject)
            {
                m_mapObjects.erase(pObject);            
            // 這里出現(xiàn)異常!
            }


            一個引用了 MyShare.lib 的 dll 工程:MyCommon.dll,關鍵代碼如下
            // 一個從 CMyObject 派生的類
            class CMyCommonObject : public CMyObject
            {
                
            };

            // 創(chuàng)建一個 CMyCommonObject 
            CMyObject * CreateObject()
            {
                
            return static_cast<CMyObject *>(new CMyCommonObject);
            }

            // 釋放對象
            void ReleaseObject(CMyObject * pObject)
            {
                pObject
            ->FinalObject();
                delete pObject;
            }

            一個引用了以上兩個模塊 exe工程:MyTest.exe,關鍵代碼如下:
            int main(int argc, TCHAR* argv[])
            {
                CMyClient client;

                
            // 調用 MyCommon.dll 中的代碼創(chuàng)建一個對象
                CMyObject * pObject = CreateObject();

                
            // 初始化對象
                client.Band(pObject);
                pObject->m_pParent = &client;

                

                
            // 使用完畢,調用 MyCommon.dll 中的代碼釋放對象
                ReleaseObject(pObject);    
            }

            以上代碼,在運行時,會在 m_mapObjects.erase(pObject);  處出現(xiàn)異常;如果單純看類的每個函數(shù),很難看出問題,另外,工程本身比較復雜,所以一直沒有懷疑是因為不同模塊之間分配和釋放內存導致的問題。
            值得注意的是,這里的 MyTest.exe 和 MyCommon.dll 中包含了同一個靜態(tài)庫,也就是說,他們之中都有 CMyObject 和 CMyClient 的二進制代碼!很容易向導的是,問題應該出在 Band 和 UnBand 。毫無疑問,以上代碼中的 client.Band 執(zhí)行的是 MyTest.exe 中的代碼。那么,m_pParent->UnBand 執(zhí)行的是哪里的代碼呢?之前我想當然的以為,既然 m_pParent 指針都是從 MyTest.exe 中傳遞來的,那肯定是執(zhí)行的 MyTest.exe 中的代碼。后來在VC中調試時偶然發(fā)現(xiàn),執(zhí)行UnBand 的代碼在 MyCommon.dll  中,才突然想到,調用類的成員函數(shù)不就相當于普通函數(shù)加一個 this 參數(shù)嗎?而普通函數(shù)編譯時就確定了地址,那肯定是指向自己模塊中的二進制代碼了。 那么,m_pParent->UnBand 肯定執(zhí)行的 MyCommon.dll 中的代碼!這樣問題就真相大白了:在 MyTest.exe 中向 map 加入元素,而在 MyCommon.dll  中釋放,肯定會出錯!因為加入或刪除元素極可能造成堆內存分配的變化!

            現(xiàn)在問題找到了,怎么解決呢?如果修改代碼邏輯,則會造成其它關聯(lián)代碼的修改,想起來都有些頭痛。問題主要是函數(shù)地址,什么函數(shù)是延遲綁定地址的呢?突然想到了虛函數(shù)!從 C++ 機制我們知道,調用虛函數(shù)其實是調用虛函數(shù)表中的函數(shù)指針,而虛函數(shù)表的內容是對象分配的時候填寫的!那么,這樣就能保證,無論在哪里調用虛函數(shù),都是調用分配該對象的模塊中的代碼!

            馬上將 CMyClient 中的 Band 和 UnBand 改成虛函數(shù),再試,問題果然消失了,而且再次用 VC 調試,發(fā)現(xiàn)從 MyCommon.dll  調用 UnBand 時 ,也是在MyTest.exe 中執(zhí)行 !^_^
            posted on 2009-09-22 14:29 會飛的兔子 閱讀(452) 評論(2)  編輯 收藏 引用 所屬分類: C++及開發(fā)環(huán)境

            Feedback

            # re: 不同模塊中釋放內存出錯 2009-09-23 10:55 岳...
            1. 搞的太復雜了,lib/dll/exe,來回折騰,要共享代碼,要簡單清晰,只用靜態(tài)lib就行,把大量公共代碼重用,這是有多個模塊時最好;
            2. dll的使用最好是私密的,不想共享代碼的;這里就會出現(xiàn)模塊分配內存的問題;
            3. 在封裝dll時一定注意2條:
            1. 輸出純虛接口,這樣容易思考,直接隔離;
            2. dll內部的內存分配與釋放,都在它自己內部完成;
            4. C++有很多種方式和技巧,一定要只選一種最簡單最適合自己的思考方式,不要混用,要不然根本沒時間和精力思考應用邏輯,大量時間消耗在C++本身的技巧上,得不嘗失;

            呵呵。。。。。。。。。
              回復  更多評論
              

            # re: 不同模塊中釋放內存出錯 2009-09-23 11:54 會飛的兔子
            回復老岳:
            很好,有一定道理;
            1條:現(xiàn)在系統(tǒng)必須這樣,又要 lib (有些公共代碼),又要 dll(COM組件)
            2、3條:同意!
            4條:部分同意。我們不能為用技巧而用技巧;當程序需要技巧的時候就用技巧,畢竟‘工欲善其事,必先利其器’嘛,^_^  回復  更多評論
              

            久久99精品国产一区二区三区| 久久久高清免费视频| 国产成人精品久久一区二区三区| 久久99精品久久久久久久不卡| 一级做a爱片久久毛片| 久久久久久青草大香综合精品| 伊人久久一区二区三区无码| 久久精品人人做人人爽电影蜜月| 国内精品久久久久久久涩爱 | 2021国内精品久久久久久影院| 久久天堂AV综合合色蜜桃网| 久久久久亚洲AV成人网人人软件| 亚洲中文字幕无码久久精品1| 91麻豆精品国产91久久久久久| 久久久久亚洲AV成人网人人网站| 人人狠狠综合久久亚洲88| 亚洲国产另类久久久精品小说 | 无码人妻久久一区二区三区蜜桃 | 亚洲午夜无码AV毛片久久| 久久99国产精品久久99| 久久精品国产99国产精品亚洲| 国产精品一区二区久久精品无码| 亚洲va久久久噜噜噜久久天堂 | 中文字幕乱码人妻无码久久| 久久精品亚洲精品国产欧美| 久久亚洲高清观看| 日产精品久久久久久久性色| 久久久久国产精品人妻| 欧美国产成人久久精品| 久久99国产一区二区三区| 日本一区精品久久久久影院| 成人久久精品一区二区三区| 亚洲中文字幕久久精品无码喷水| 综合久久一区二区三区 | 999久久久无码国产精品| 久久无码AV中文出轨人妻| 久久强奷乱码老熟女| 人妻精品久久久久中文字幕| 久久影视综合亚洲| 久久久久久极精品久久久| 污污内射久久一区二区欧美日韩|