2014-05-22 70 views
0

我是MFC新手。MFC中的資源泄漏SendMessage()

如何發佈以(WPARAM)SendMessage()中傳遞的資源。

這裏我使用「新」爲它創建。以下是相同的快照。

void Build::BuildCube() 
{ 

    SCtPt *data = new SCtPt; 
    data->vm = true; 
    int dir = 100; 
    MFrame()->SendMessage(WM_MAP_NEW, (WPARAM)data, (LPARAM) dir); 
} 

我想確保此功能的「數據」資源獲得釋放。

謝謝...

+0

什麼是MFrame,它是如何處理該消息的?它是否在某處保留對該指針的引用?假設不是,在完成處理該消息後,您可以安全地刪除它,這將在SendMessage返回後進行。 –

+0

此外,如果不是,則可能更容易創建自動變量或使用shared_ptr。 –

回答

3

作爲SendMessage() API是同步的API,它返回之前將消息發送到其它窗口過程。當調用SendMessage()回報,那麼數據可以釋放/發佈:

void Build::BuildCube() 
{ 
    SCtPt *data = new SCtPt; 
    data->vm = true; 
    int dir = 100; 
    MFrame()->SendMessage(WM_MAP_NEW, (WPARAM)data, (LPARAM)dir); 
    delete data; 
} 

或者,更好的,你可以完全避免的堆上分配數據。只需將它分配在棧上,讓RAII處理其餘部分:

void Build::BuildCube() 
{ 
    SCtPt data;  // don't use "new", so you won't get a pointer 
    data.vm = true; 
    int dir = 100; 
    MFrame()->SendMessage(WM_MAP_NEW, (WPARAM)data, (LPARAM)dir); 
    // no delete necessary! 
} 
+7

請注意,這意味着它不需要在堆上分配。把它變成一個堆棧變量。 –

+0

是否可以,如果我刪除它處理此消息的函數或如果它是同步API,那麼我想在這裏刪除它是安全的。 – user1833852

+1

在處理消息的函數中刪除是可以的,但是你需要記住不要在BuildCube()中再次刪除,更好的解決辦法是在SendMessage返回後刪除,所以分配和釋放是在集中控制下。 –

5

你考慮寫這樣的代碼:

void Build::BuildCube() 
{ 
    SCtPt data; 
    data.vm = true; 
    int dir = 100; 
    MFrame()->SendMessage(WM_MAP_NEW, (WPARAM)&data, (LPARAM)dir); 
} 

這種方式發送,WPARAM的數據仍然是指向你的對象,但是當應用程序退出此方法的作用域時,它將調用析構函數併爲您執行清理。

+1

這究竟是爲什麼被投票呢?鑑於最初的問題,這是要走的路。除非您打算將指針存儲在某處供以後使用,否則無需分配SendMessage。 – imbtfab

+0

這也是我的建議。除了data-> vm s/b data.vm之外,由於它不是指針。 –

0

我們通常這樣做:

在數據分配點,註釋狀態明確在那裏將被釋放。

void Build::BuildCube() 
{ 

    SCtPt *data = new SCtPt; // Will be deallocated in handler of message WM_MAP_NEW 
    data->vm = true; 
    int dir = 100; 
    MFrame()->SendMessage(WM_MAP_NEW, (WPARAM)data, (LPARAM) dir); 
} 

LRESULT CMainFrame::OnMapNew(WPARAM wParam, LPARAM) 
{ 
    SCtPt *data = (SCtPt*) wParam; 
    // do something with data; 

    delete data; 
} 
+0

評論非常好,但對於阻止資源泄漏沒有多大幫助。它依賴程序員不犯錯誤,我們都知道這不太可能。 :-)如果你確實需要一個,最好在接收窗口過程中複製數據。讓調用者和被調用者保持獨立的內存管理。代碼審查更容易以這種方式捕獲錯誤。 –

+0

同意!這並不完美。 – Max