C++ 混淆Valgrind输出：间接丢失块但没有错误？

我正在运行valgrind 3.5.0，试图消除程序中的内存泄漏。 我这样援引它：

valgrind --tool=memcheck --leak-check=yes --show-reachable=yes

在我的程序完成后，valgrind报告说

==22926==
==22926== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
==22926== malloc/free: in use at exit: 20,862 bytes in 425 blocks.
==22926== malloc/free: 25,361 allocs, 24,936 frees, 772,998 bytes allocated.
==22926== For counts of detected errors, rerun with: -v
==22926== searching for pointers to 425 not-freed blocks.
==22926== checked 91,884 bytes.

尽管告诉我有0个错误，但我担心分配和释放的数量不匹配。更多 令人担忧的是：

==22926== LEAK SUMMARY:
==22926==    definitely lost: 68 bytes in 1 blocks.
==22926==    indirectly lost: 20,794 bytes in 424 blocks.
==22926==      possibly lost: 0 bytes in 0 blocks.
==22926==    still reachable: 0 bytes in 0 blocks.
==22926==         suppressed: 0 bytes in 0 blocks.

OneTwoThree::OneTwoThree (const Scenario* scenario) :
    Choice("123", scenario, new Solution (scenario->name(), scenario)),
    seen_(new bool [sol_->numVisits()])
{
}

还有额外的输出，与似乎是泄漏的内容有关：

==22926== 20,862 (68 direct, 20,794 indirect) bytes in 1 blocks are definitely lost in loss record 9 of 17
==22926==    at 0x40269EE: operator new(unsigned int) (vg_replace_malloc.c:224)
==22926==    by 0x807960B: OneTwoThree::OneTwoThree(Scenario const*) (onetwothree.cc:22)
==22926==    by 0x804DD69: main (scsolver.cpp:654)

在OneTwoThree的构造函数中有问题的行中，我有以下内容：

==22926== LEAK SUMMARY:
==22926==    definitely lost: 68 bytes in 1 blocks.
==22926==    indirectly lost: 20,794 bytes in 424 blocks.
==22926==      possibly lost: 0 bytes in 0 blocks.
==22926==    still reachable: 0 bytes in 0 blocks.
==22926==         suppressed: 0 bytes in 0 blocks.

OneTwoThree::OneTwoThree (const Scenario* scenario) :
    Choice("123", scenario, new Solution (scenario->name(), scenario)),
    seen_(new bool [sol_->numVisits()])
{
}

稍后，在析构函数中，seen_uu被删除，如下所示：

OneTwoThree::~OneTwoThree ()
{
    delete [] seen_;
}

不存在与内存相关的内存重新分配；我只在测试过程中将布尔值翻转为真/假 运行我的程序

我看不到这里有漏洞，我也不明白瓦尔格兰德想告诉我什么。我一直在通读报纸 valgrind手册（特别是），但 我没有得到多少启发

---

有人能帮我查一下这篇文章吗？

这篇文章的评论员都很到位；在构造函数中创建的解决方案对象从未被删除。我已经修复了令人震惊的疏忽，并且摆脱了在负责对象的构造函数之外创建新对象的丑陋代码

---

谢谢阿泰利乌斯、尼古拉和乔纳森

解决方案

对象本身是否可能永远不会被销毁？Choice类是否会取消分配它在构造函数中获得的指针？看起来更好的设计应该是在同一个类中拥有指针所有权-如果有一个或两个三个分配内存，那么同一个实例应该取消分配内存。Choice构造函数及其相关函数是否完全释放了所有内容？此外，在持有资源时，赋值运算符中可能会出现内存泄漏。遵循三大法则：无论何时编写复制构造函数、赋值运算符或析构函数；另外两个也要写。就我个人而言，我认为赋值运算符最好使用复制和交换习惯用法编写。