boost::filesystem::path导致内存差异

boost::filesystem::path causing memory difference

本文关键字：内存 filesystem path boost      更新时间：2023-10-16

我们有几个单元测试，它们使用Win32 _CrtMemCheckpoint/_CrtMemDifference方法来检测被测代码中的内存泄漏。在x64计算机（Windows 7）上，其中一些测试报告了x86（32位）计算机上没有报告的内存泄漏。在这些x64计算机上，使用VS2008或VS2012编译以下代码并使用Boost 1.52.0，结果是"检测到内存泄漏！"：

#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:：filesystem：：path中的内存泄漏吗？我想这是某种图书馆初始化，因为

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!";
    }
}

不输出"检测到内存泄漏！"。

我的问题是：如何避免单元测试中出现这样的问题？在开始测试之前初始化这样一个变量是解决方案吗？在使用其他代码时，我是否需要做更多这样的事情？还是一般来说做这样的测试是个坏主意？

谢谢你的想法！

由于您的第二个代码示例，我想说boost:：filesystem:：path正在初始化一些静态内部状态（在程序结束之前一直分配）。

如何避免单元测试中出现此类问题？

创建一个测试初始化方法，在获取第一个内存检查点之前执行该方法。

理想情况下，您应该能够自定义要跟踪的分配和解除分配（覆盖新的/删除、添加自定义分配器等），但这更困难，可能不允许这样做，具体取决于您使用的库。

在开始测试之前初始化这样一个变量是解决方案吗？

这是一个变通办法。不是很优雅，但最终，它会告诉你你想知道的。

在使用其他代码时，我是否需要做更多这样的事情？

这取决于您使用的库以及它们的灵活性。如果您正在测试您完全拥有的代码，您应该考虑在内部使用分配器类型（可以自定义以跟踪分配的std:：分配器）、自定义新的和删除或编写一些可以提供多个实现的分配API。

您也可以使用不明确依赖_CrtMem*Windows API的测试代码（boost:：test库有一个运行时参数来检测内存泄漏，所以您不必亲自实现它，但我不知道它在Win64中到底在做什么。

相关文章：