用于C ++的Instrumentation（诊断）库

Question

我正在考虑将代码添加到我的应用程序中，该代码将收集诊断信息以供以后检查。是否为此目的创建了任何C ++库？我想要做的是类似于分析，但它不一样，因为收集的数据将更多地用于调试而不是分析。

编辑：
平台：Linux
要收集的诊断信息：由应用程序逻辑，各种断言和统计信息产生的信息。

Answer 1

我倾向于为此目的使用日志记录。 Log4cxx就像魅力一样。

Answer 2

您可能还想查看libcwd：

  

Libcwd是一个用于C ++的线程安全，功能齐全的调试支持库   开发人员。它包括基于ostream的调试输出和自定义调试   通道和设备，强大的内存分配调试支持   作为打印源文件的运行时支持：行号信息   和demangled类型名称。

• List of features
• Tutorial
• Quick Reference
• Reference Manual

另外，另一个有趣的日志记录库是pantheios：

  

Pantheios是一个开源的C / C ++日志API库，提供了一个   100％类型安全，效率，通用性的最佳组合   和可扩展性。它易于使用和扩展，高度便携（平台   和编译器无关的），最重要的是，它坚持你的C传统   只支付您使用的费用。

Answer 3

如果您正在进行调试，可能需要使用调试器。 GDB脚本很容易编写和使用。与代码并行维护它们可能具有挑战性。

编辑 - 附加Annecdote：

我维护的软件包括一个自行开发的仪器系统。宏用于对日志消息进行排队，配置选项控制记录的消息类别以及要记录的详细信息级别。线程处理日志队列，将消息刷新到文件，并在文件变得太大时旋转文件（通常这样做）。该系统提供了大量细节，但通常它会提供巨大的文件，我们的支持工程师必须花费数小时才能找到有用的东西。

现在，我只使用GDB几次诊断错误，但对于这些问题，它比日志系统有一些很好的优势。 GDB脚本允许我收集新的仪器数据，而无需添加新的仪器线并将新的软件版本部署到客户端。 GDB可以从第三方库生成消息（需要在一个点调试到openssl）。 GDB在不使用时不会对软件产生运行时影响。 GDB在打印对象内容方面做得很好;当新对象需要记录其状态时，代码级日志记录系统需要写入新的宏。

其中一个缺点是我生成的gdb脚本与源代码没有明确的关系;源文件和gdb脚本是独立开发的。理想情况下，对源文件的更改应影响并更新gdb脚本。一种想法是在代码中放置特殊格式的注释，并使用脚本语言传递源文件以生成源文件的调试器脚本文件。最后，让makefile在构建周期中执行此脚本。

考虑将GDB用于此目的的潜力是一个有趣的练习，但我必须承认，可能有更好的代码级解决方案。

Answer 4

如果在Linux中执行应用程序，可以使用“ulimit”在应用程序崩溃时生成核心（或断言（false）或kill -6），稍后，您可以使用gdb进行调试（gdb -c core_file binary_file）并分析堆栈。

Salu2。

PD。要进行性能分析，请使用gprof