现代C ++使内存泄漏更难发现

Question

您应该如何测试现代C ++的内存泄漏？

外单元测试用例通常看起来像这样：

TestCase {
  Instantiate testObject
  testObject->AllocateSomeResources
  testObject->PerformATest
  testObject->DeallocateResources
  Destroy testObject
}

我们使用valgrind来检测内存泄漏。如果使用new和delete完成资源分配，这将非常有效，但是当资源作为智能指针存储在标准容器中时，testObject销毁时的自动清除会阻止我们发现错误。

当系统处于活动状态时。资源容器可能会由于错误的重新分配过程而随着时间增长。确定分配是否使用new和delete完成将是微不足道的。

是否有任何技术可以弥补现代C ++的这一方面？

想法：

• 使所有析构函数测试分配的资源。这会相当影响生产代码库。
• 创建更多分离且可测试的分配和释放程序。当然，但是由于我们使用更传统的C ++可以大量“免费”使用此软件，因此我仍然希望找到替代方法。

显然，我在标准容器和智能指针中看到了好处，对单击诱饵标头表示抱歉

编辑

示例：

class A {
  int* resource;
  public:
    void allocate(){ resource = new int; }
    void deallocate(){ /*delete resouce;*/ }
};

class B {
  std::unique_ptr<int> resource;
  public:
    void allocate(){ resource = std::make_unique<int>(); }
    void deallocate(){ /*resource.reset();*/ }
};
A类和B类都有相同的缺陷。 deallocate函数中的错误使它们在调用deallocate之后保留了不需要的内存。对于A类，这是一个“实际泄漏”，对于在单元测试中用Valgrind等进行检测很简单。对于B类，我只能通过将私有资源公开为公共资源来检测单元测试中的缺陷，而我不想这样做。这个问题不是关于Valgrind的，而是是否有一些模式可以帮助我获得与Valgrind和A类相同的高质量产品，而是使用标准容器和智能指针来存储我的私有资源。

涉及的对象可以生存数周，在此期间分配了不同数量的资源。

您应该如何测试现代C ++的内存泄漏？单元测试用例通常如下所示：TestCase {实例化testObject testObject-> AllocateSomeResources testObject-> ...

Answer 1

您还可以在单​​元测试中测试Instantiate的各个方法，而不是一次测试所有方法。独立运行每个测试。然后，您可以在每种方法中找到泄漏的位置。