boost :: filesystem :: path導致內存差異

我們有幾個單元測試使用Win32 _CrtMemCheckpoint/_CrtMemDifference方法來檢測被測代碼中的內存泄漏。在x64機器上（Windows 7），其中一些測試報告了x86（32位）機器上未報告的內存泄漏。在這些x64計算機，編譯以下代碼要麼VS2008或VS2012和使用Boost 1.52.0，結果是「內存泄漏檢測！」：boost :: filesystem :: path導致內存差異

#include <boost/filesystem.hpp> 
#include <crtdbg.h> 

int main(int argc, char **argv) 
{ 
    _CrtMemState state1, state2, state3; 
    _CrtMemCheckpoint(&state1); 

    { 
     boost::filesystem::path remoteDirPath("c:/"); 
    } 

    _CrtMemCheckpoint(&state2); 

    int res = _CrtMemDifference(&state3, &state1, &state2); 
    if (res != 0) 
    { 
     _CrtDumpMemoryLeaks(); 
     std::cout << "Memory leak detected!"; 
    } 
}

這是實際的boost ::文件系統中的內存泄漏：：路徑？我想這是一些庫initalization左右，因爲

int main(int argc, char **argv) 
{ 
    { 
     boost::filesystem::path initDummy("c:/"); 
    } 
    _CrtMemState state1, state2, state3; 
    _CrtMemCheckpoint(&state1); 

    { 
     boost::filesystem::path remoteDirPath("c:/"); 
    } 

    _CrtMemCheckpoint(&state2); 

    int res = _CrtMemDifference(&state3, &state1, &state2); 
    if (res != 0) 
    { 
     _CrtDumpMemoryLeaks(); 
     std::cout << "Memory leak detected!"; 
    } 
}

不會輸出「內存泄漏檢測！」。

我的問題是：如何避免單元測試出現這樣的問題？在開始測試之前初始化這樣一個變量是否是解決方案？在使用其他代碼時，我還需要做更多這樣的事情嗎？或者通常做這樣的測試是一個壞主意？

感謝您的想法！

來源

2013-07-03 Philipp

由於你的第二個代碼示例，我會說boost :: filesystem :: path正在初始化一些靜態的內部狀態（它一直分配到你的程序結束）。

如何避免單元測試出現這樣的問題？

創建在獲取第一個內存檢查點之前執行的測試初始化方法。

理想情況下，您應該能夠自定義分配和取消分配以跟蹤（覆蓋新建/刪除，添加自定義分配器等），但這會更困難並且可能不被允許執行，具體取決於您使用的庫。

在開始測試之前初始化這樣一個變量的解決方案？

這是一種解決方法。不是很優雅，但最終，它告訴你你想知道什麼。

使用其他代碼時，我需要做更多這樣的事情嗎？

取決於您使用的庫以及它們的靈活性。如果你正在測試你自己擁有的代碼，你應該考慮在內部使用分配器類型（一個你可以自定義來跟蹤分配的std :: allocator），定製新的和刪除或者編寫一些你可以提供多個實現的分配API。你也可以使用不明確依賴於_CrtMem * Windows API的測試代碼（boost :: test庫有一個運行時參數來檢測內存泄漏，所以你不必親自實際實現它，但我不'不知道它在Win64下的功能如何。

來源

2013-07-03 12:24:29 utnapistim

boost :: filesystem :: path導致內存差異

回答

相關問題