使用gdb调试C ++ STL / Boost的最佳实践

Question

使用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。

Answer 1

也许不是你想要的那种“小费”，但我不得不说我从C ++和C＆C转移几年后的经历。 STL到C ++＆amp;提升与STL是我现在在GDB中花费的时间比以前少了很多。我把它归结为很多东西：

• 提升智能指针（特别是“共享指针”，以及需要性能时的指针容器）。我不记得上次我必须写一个明确的删除（删除是C ++恕我直言的“转到”）。有很多GDB时间跟踪无效和泄漏指针。
• boost充满了经过验证的代码，你可能会把它们放在一起，而不是其他的劣质版本。例如boost::bimap对于LRU缓存逻辑的通用模式非常有用。还有另一堆GDB时间。
• 采用单元测试。 boost::test的AUTO宏意味着设置测试用例（easier than CppUnit）是一个绝对的傻瓜。这很长一段时间内它会被内置到你必须附加调试器的任何东西之前。
• 与此相关，像boost::bind这样的工具使设计测试更容易。例如，算法可以更通用，并且与它们所操作的类型的联系更少;这使得将它们插入测试垫片/代理/模拟对象等更容易（事实上，暴露于boost的模板 - tasticness将鼓励你“敢于模板化”你以前从未考虑过的事情，产生类似的测试好处）。
• boost::array。 “C阵列”性能，在调试版本中进行范围检查。
• boost充满了很棒的代码，你不能不学习

Answer 2

您可以查看：

Inspecting standard container (std::map) contents with gdb

Answer 3

我认为最简单和最多的选择是使用日志记录（我实际上使用调试打印，但我认为这不是一个问题）。最大的优点是，您可以检查任何类型的数据，每次执行程序多次，然后使用文本编辑器搜索它以查找有趣的数据。请注意，这非常快。缺点很明显，您必须预先选择要记录的数据和记录的位置。但是，这不是一个严重的问题，因为你通常知道代码中的错误发生在哪里（如果不是，你只需要在这里和那里添加健全性检查，然后，你就会知道）。

检查/调试库是好的，但它们作为测试工具更好（例如，运行它并查看我是否做错了什么），并且不如调试特定问题。他们无法检测用户代码中的缺陷。

否则，我使用普通的GDB。听起来并没有那么糟糕，尽管可能是因为你被“print x”打印出一堆垃圾而感到害怕。但是，如果您有调试信息，例如打印std::vector成员的工作，如果有任何失败，您仍然可以通过x命令检查原始内存。但如果我知道我在寻找什么，我会使用选项1 - 记录。

请注意，“难以检查”的结构不仅包括STL / Boost，还包括其他库，如Qt / KDE。