C++ 运行时调试（诊断策略和构造）答案

【问题标题】：C++ runtime debugging (diagnostic strategies and constructs)C++ 运行时调试（诊断策略和构造）
【发布时间】：2010-11-09 01:02:40
【问题描述】：

我计划在我的软件中添加广泛的诊断功能。现在我正在考虑如何做到这一点的总体策略，因为临时添加这样的代码可能会导致严重的混乱。

你有这方面的经验吗？

我要监控：

从选定子集中创建对象的密集程度。
调用密集选择的方法的程度。
选定时间段内的其他事件数。
对于选定的方法，收集有关调用者的信息 (libcwd allows this?)
每个线程按时间段顺序消耗的时间量。

我的软件是一个类似处理的工具，它通常像其他处理或计算工具一样工作，例如 lame mp3 编码器。这就是为什么这种整体统计数据收集对我来说确实有意义的原因。

我目前正计划为每个要监视创建/破坏的对象添加一个基类。基类将在其构造函数和析构函数中记录适当的信息。 还能做什么？

class LifeCycleProbe {
    char * name;
    LifeCycleProbe(char * _name) : name(_name) {
       some::important::object.created(_name);
    }
    ~LifeCycleProbe() {
       some::important::object.destroyed(_name);
    }
}
class MonitorMe : private LifeCycleProbe {
    MonitorMe() : LifeCycleProbe("MonitorMe") {
        // ...
    }
}

【问题讨论】：

标签： c++ multithreading debugging logging diagnostics

【解决方案1】：

+1 给那些建议使用外部分析器的人。我只会在开发或测试周期中非常激烈的情况下绑定分析代码，绝对不会在生产代码库中。

那时，当我使用 C++ 工作时，有一个非常棒的工具，叫做 BugTrapper。大约 7 年前，他们是一家初创公司，他们制作的软件令人印象深刻。我认为从那时起他们已经成熟了很多，并且据我所知looking at their site 一直在做生意。曾经是很酷的东西，虽然我不知道它现在是什么样子。无论如何，在重新发明轮子之前尝试现成的解决方案是值得的。恕我直言。

【讨论】：

【解决方案2】：

这听起来像是 YAGNI 的一个经典案例——我建议首先将时间花在设计和正确编写软件上。

【讨论】：

【解决方案3】：

我能想到的第一件事是，您可能可以充分利用单独的分析工具。这也将消除更改源代码以允许它的需要。

我可以推荐的工具：

Valgrind 和 KCachegrind 作为 Linux 的前端
XPerf 适用于 Windows（Vista、7 和更高版本）

这些工具可以轻松帮助您找到所有问题的答案。

【讨论】：

【解决方案4】：

这看起来像是一个好的分析器应该能够为您收集的东西，而无需更改您的源代码。

我使用 kprof 和 valgrind，也许这些工具可以帮助你。

【讨论】：