• <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條:部分同意。我們不能為用技巧而用技巧;當程序需要技巧的時候就用技巧,畢竟‘工欲善其事,必先利其器’嘛,^_^  回復  更多評論
              

            精品人妻伦一二三区久久| 久久亚洲精品国产亚洲老地址| 蜜臀av性久久久久蜜臀aⅴ| 久久精品无码一区二区无码| 久久精品国产亚洲综合色| 久久久久久毛片免费看| 色综合久久久久久久久五月| 精品熟女少妇aⅴ免费久久| 2021最新久久久视精品爱| 久久国产精品一区二区| 东方aⅴ免费观看久久av| 国产精品狼人久久久久影院 | 亚洲欧洲精品成人久久曰影片 | 国产一区二区三区久久精品| 久久久久久久免费视频| 青青青青久久精品国产 | 国产—久久香蕉国产线看观看| 综合网日日天干夜夜久久| 久久久国产精华液| 亚洲成色999久久网站| 久久精品午夜一区二区福利| 精品久久久久久无码不卡| 久久精品国产WWW456C0M| 久久成人精品视频| 国产午夜免费高清久久影院| 无码国产69精品久久久久网站| 青青青青久久精品国产h久久精品五福影院1421 | 久久99精品久久久久久9蜜桃| 97久久超碰国产精品旧版| 无码超乳爆乳中文字幕久久| 欧美激情一区二区久久久| 伊人伊成久久人综合网777| 久久精品视屏| 无码精品久久一区二区三区| 久久精品中文字幕有码| 久久婷婷五月综合97色直播| 精品久久久久中文字幕一区| 精品久久久久久久久久中文字幕| 国产精品久久久久乳精品爆 | 伊人久久大香线蕉精品不卡| 久久亚洲天堂|