C++ 调试最佳实践 STL/Boost 与 gdb
使用 gdb 进行调试，任何使用 STL/boost 的 C++ 代码仍然是一场噩梦。 任何使用过 gdb 和 STL 的人都知道这一点。 例如，请参阅此处代码中某些调试会话的示例运行。
我正在尝试通过收集提示来减轻痛苦。 您能否对我在下面收集的提示发表评论（特别是您一直在使用哪些提示以及您建议对其进行的任何更改） - 我列出的提示按技术性的降序排列。
- 有人使用 "Stanford GDB STL utils" 和 "UCF GDB utils"？ 是否有一些此类用于增强数据结构的实用程序？ 上面的实用程序似乎不能递归使用，例如在一个命令中以清晰的方式打印 boost::shared_ptr 的向量。
- 编写您的 .gdbinit 文件。 例如，包括 C++ 相关的美化器，列在 UCF GDB utils 的底部。
- 使用检查/调试STL/Boost库，例如STLport。
- 使用日志记录（例如此处所述）
更新：GDB 有新的 C++ 分支。
Debugging with gdb, any c++ code that uses STL/boost is still a nightmare. Anyone who has used gdb with STL knows this. For example, see sample runs of some debugging sessions in code here.
I am trying to reduce the pain by collecting tips. Can you please comment on the tips I have collected below (particularly which ones you have been using and any changes you would recommend on them) - I have listed the tips is decreasing order of technicality.
- Is anyone using "Stanford GDB STL utils" and "UCF GDB utils"? Is there some such utils for boost data structures? The utils above do not seem to be usable recursively, for example for printing vector of a boost::shared_ptr in a legible manner within one command.
- Write your .gdbinit file. Include, for example, C++ related beautifiers, listed at the bottom of UCF GDB utils.
- Use checked/debug STL/Boost library, such as STLport.
- Use logging (for example as described here)
Update: GDB has a new C++ branch.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
也许不是您正在寻找的那种“技巧”，但我不得不说，我从 C++ 和 C++ 迁移几年后的经验是值得的。 STL 到 C++ 和 升压和 STL 是我现在花在 GDB 上的时间比以前少了很多。 我将其归结为以下几件事：
boost::bimap非常适合 LRU 缓存逻辑的常见模式。 又浪费了一大堆 GDB 时间。boost::test的 AUTO 宏意味着设置测试用例绝对是轻而易举的事情 (比 CppUnit 更容易）。 早在它被构建到你必须附加调试器的任何东西之前，它就捕获了很多东西。boost::bind这样的工具使测试设计变得更加容易。 例如，算法可以更加通用，并且与它们所操作的类型的联系更少； 这使得将它们插入测试垫片/代理/模拟对象等变得更容易（事实上，接触 boost 的模板特性将鼓励您“敢于模板化”您以前从未考虑过的事情，从而产生类似的测试好处）。boost::array。 “C 数组”性能，在调试版本中进行范围检查。Maybe not the sort of "tip" you were looking for, but I have to say that my experience after a few years of moving from C++ & STL to C++ & boost & STL is that I now spend a lot less time in GDB than I used to. I put this down to a number of things:
boost::bimapis great for the common pattern of LRU caching logic. There goes another heap of GDB time.boost::test's AUTO macros mean it's an absolute doddle to set up test cases (easier than CppUnit). This catches lots of stuff long before it gets built into anything you'd have to attach a debugger to.boost::bindmake it easier to design-for-test. e.g algorithms can be more generic and less tied up with the types they operate on; this makes plugging them into test shims/proxies/mock objects etc easier (that and the fact that exposure to boost's template-tasticness will encourage you to "dare to template" things you'd never have considered before, yielding similar testing benefits).boost::array. "C array" performance, with range checking in debug builds.您可以查看：
使用 gdb 检查标准容器 (std::map) 内容
You might look at:
Inspecting standard container (std::map) contents with gdb
我认为最简单和最多的选择是使用日志记录（我实际上使用调试打印，但我认为这不是重点）。 最大的优点是，您可以在每次程序执行时多次检查任何类型的数据，然后使用文本编辑器进行搜索以查找有趣的数据。 请注意，这非常快。 缺点很明显，您必须预先选择要记录的数据以及记录的位置。 然而，这并不是一个严重的问题，因为您通常知道代码中哪里发生了不好的事情（如果没有，您只需在这里或那里添加健全性检查，然后您就会知道）。
检查/调试库很好，但它们作为测试工具更好（例如运行它并看看我是否做错了什么），并且不擅长调试特定问题。 他们无法检测用户代码中的缺陷。
否则，我使用普通的 GDB。 这并不像听起来那么糟糕，尽管如果您被“
print x”打印满屏垃圾吓到的话，情况可能会很糟糕。 但是，如果您有调试信息，例如打印std::vector的成员之类的操作，并且如果出现任何失败，您仍然可以通过x命令检查原始内存。 但如果我知道我在寻找什么，我会使用选项 1 - 日志记录。请注意，“难以检查”的结构不仅来自 STL/Boost，还来自其他库，例如 Qt/KDE。
I think the easiest and most option is to use logging (well I actually use debug prints, but I think that's not a point). The biggest advantage is that you can inspect any type of data, many times per program execution and then search it with a text editor to look for interesting data. Note that this is very fast. The disadvantage is obvious, you must preselect the data which you want to log and places where to log. However, that is not such a serious issue, because you usually know where in the code bad things are happening (and if not, you just add sanity checks here and there and then, you will know).
Checked/debug libraries are good, but they are better as a testing tool (eg. run it and see if I'm doing anything wrong), and not as good at debugging a specific issue. They can't detect a flaw in user code.
Otherwise, I use plain GDB. It is not that bad as it sounds, although it might be if you are scared by "
print x" printing a screenful of junk. But, if you have debugging information, things like printing a member of astd::vectorwork and if anything fails, you still can inspect the raw memory by thexcommand. But if I know what I'm looking for, I use option 1 - logging.Note that the "difficult to inspect" structures are not only STL/Boost, but also from other libraries, like Qt/KDE.