使用gdb进行调试，任何使用STL / boost的c代码仍然是一场噩梦 . 任何使用过STL的gdb的人都知道这一点 . 例如，请参阅代码here中的一些调试会话的示例运行 .
我试图通过收集提示来减轻疼痛 . 您能否对我在下面收集的提示发表评论（特别是您使用过的提示以及您建议的任何更改） - 我列出的提示是技术性的降序 .
-
是否有人使用"Stanford GDB STL utils"和"UCF GDB utils"？是否有一些这样的工具用于boost数据结构？上面的util似乎不是递归可用的，例如用于在一个命令内以清晰的方式打印boost :: shared_ptr的向量 .
-
编写.gdbinit文件 . 例如，包括C相关的美化器，列在UCF GDB工具的底部 .
-
使用checked / debug STL / Boost库，例如STLport .
-
使用日志记录（例如here所述）
更新：GDB有一个new C++ branch .
3 回答
也许不是你想要的那种"tip"，但我不得不说我从C＆STL搬到C＆boost＆STL几年后的经验是我现在在GDB上花的时间比以前少了很多 . . 我把它归结为以下几点：
提升智能指针（尤其是"shared pointer"，以及需要性能时的指针容器） . 我不记得上次我必须写一个明确的删除（删除是C IMHO的"goto"） . 有很多GDB时间跟踪无效和泄漏指针 .
boost充满了经过验证的代码，你可能会把它们放在一起，而不是劣质版本 . 例如
boost::bimap非常适合LRU缓存逻辑的通用模式 . 还有另一堆GDB时间 .采用单元测试 .
boost::test's AUTO macros mean it'是设置测试用例的绝对点头（easier than CppUnit） . 这很长一段时间内它会被内置到你必须附加调试器的任何东西之前 .与此相关，像
boost::bind这样的工具使设计测试更容易 . 例如，算法可以更通用，并且与它们所操作的类型的联系更少;这使得将它们插入到测试填充/代理/模拟对象等中更容易（事实上，暴露于此之前从未考虑过，产生类似的测试优势） .boost::array. "C array"性能，在调试版本中进行范围检查 .boost充满了伟大的代码，你不能不学习
你可能会看：
Inspecting standard container (std::map) contents with gdb
我认为最简单和最多的选择是使用日志记录（我实际上使用调试打印，但我认为这不是一个问题） . 最大的优点是，您可以检查任何类型的数据，每次执行程序多次，然后使用文本编辑器搜索它以查找有趣的数据 . 请注意，这非常快 . 缺点很明显，您必须预先选择要记录的数据和记录的位置 . 然而，这不是一个严重的问题，因为你通常知道代码中的坏事发生在哪里（如果没有，你只需要在这里和那里添加健全性检查，然后，你就会知道） .
检查/调试库是好的，但它们作为一种测试工具更好（例如，运行它并查看我是否做错了什么），并且不如调试特定问题 . 他们无法检测用户代码中的缺陷 .
否则，我使用普通的GDB . 听起来并不是那么糟糕，尽管可能是因为你被“
print x”打印了一大堆垃圾而感到害怕 . 但是，如果您有调试信息，例如打印std::vector工作的成员，如果有任何失败，您仍然可以通过x命令检查原始内存 . 但如果我知道我在寻找什么，我会使用选项1 - 记录 .请注意，“难以检查”的结构不仅是STL / Boost，还来自其他库，如Qt / KDE .