46

使用 gdb 调试，任何使用 STL/boost 的 c++ 代码仍然是一场噩梦。任何使用过 STL 的 gdb 的人都知道这一点。例如，在此处查看代码中一些调试会话的示例运行。

我试图通过收集提示来减轻痛苦。您能否评论一下我在下面收集的提示（特别是您一直在使用的提示以及您建议对它们进行的任何更改）-我列出的提示是技术性的降序。

  • 有人在使用“Stanford GDB STL utils”和“UCF GDB utils”吗？是否有一些用于提升数据结构的工具？上面的实用程序似乎不能递归使用，例如用于在一个命令中以清晰的方式打印 boost::shared_ptr 的向量。
  • 编写您的 .gdbinit 文件。例如，包括 C++ 相关的美化器，列在 UCF GDB 实用程序的底部。
  • 使用检查/调试 STL/Boost 库，例如 STLport。
  • 使用日志记录（例如这里描述的）

更新：GDB 有一个新的 C++ 分支。

4

3 回答 3

15

也许不是您正在寻找的那种“提示”，但我不得不说，在从 C++ 和 STL 转向 C++ 和 boost 和 STL 几年后，我现在在 GDB 上花费的时间比我少得多习惯了。我把这归结为几件事：

  • 提升智能指针（特别是“共享指针”，以及需要性能时的指针容器）。我不记得上次我必须写一个显式删除（删除是 C++ 恕我直言的“goto”）。有很多 GDB 时间跟踪无效和泄漏的指针。
  • boost 充满了经过验证的代码，这些代码你可能会用其他的低级版本来破解。egboost::bimap非常适合 LRU 缓存逻辑的常见模式。还有一大堆 GDB 时间。
  • 采用单元测试。 boost::test的 AUTO 宏意味着设置测试用例绝对是轻而易举的事（比 CppUnit 更容易）。这在它被构建到任何你必须附加调试器的东西之前很久就捕获了很多东西。
  • 与此相关的是，像这样的工具boost::bind使测试设计变得更容易。例如，算法可以更通用，并且与它们所操作的类型的联系更少；这使得将它们插入测试垫片/代理/模拟对象等变得更容易（而且暴露于 boost 的模板特性将鼓励你“敢于模板化”你以前从未考虑过的东西，从而产生类似的测试好处）。
  • boost::array. “C 数组”性能，在调试版本中进行范围检查。
  • boost 充满了你不禁要学习的优秀代码
于 2009-01-12T14:39:17.160 回答
5

你可能会看：

使用 gdb 检查标准容器 (std::map) 内容

于 2009-01-11T19:16:06.197 回答
3

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

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

否则，我使用普通的 GDB。这并不像听起来那么糟糕，尽管如果你被“ print x”打印满屏的垃圾吓到了，那可能会是这样。但是，如果你有调试信息，比如打印一个作品的成员，如果有任何失败，你仍然可以通过命令std::vector检查原始内存。x但如果我知道我在寻找什么，我会使用选项 1 - 日志记录。

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

于 2009-01-11T17:05:12.437 回答