为什么是Q_ASSERT而不是assert

Question

在Qt中有一个Q_ASSERT宏。使用它而不是<cassert>的assert有什么好处？

Answer 1

Q_ASSERT是一个自定义assert宏，它可以增强标准的assert函数。

错误消息由处理，它在某些平台上的行为可能比标准的assert宏稍好一些。例如，在Windows上，它将在断言失败时触发Visual Studio调试器，而不仅仅是调用abort()。

您还可以使用将Qt错误消息函数(如qFatal )的输出重定向到您的自定义消息处理程序(使用qInstallMessageHandler() )。例如，如果您想要将错误消息重定向到文件，它可能会很有用。

还要注意，使用宏QT_NO_DEBUG禁用了Q_ASSERT (而NDEBUG禁用了assert )：这可以用来将断言与Qt相关的代码和其他代码分开。

Answer 2

来自同一个文档：

如果在编译过程中定义了QT_NO_DEBUG，则

不执行任何操作。

因此，想想看：Q_ASSERT并不像assert那样依赖于NDEBUG的缺失。assert()做任何事情都需要#ifndef NDEBUG，而且经常用它来界定用户(可能还有库？)中其他仅限调试的常规内容。代码。

对于那些只想调试与Qt相关的东西的人来说，使用单独的宏是有好处的，因为如果没有定义NDEBUG，那么就不会留下未定义的NDEBUG，从而会使用仅限调试的东西来拖累其余的代码，如果没有定义assert()，这些东西会使程序变得臃肿。

因此，如果你想用发布模式的语义编译“普通”的东西，但仍然将调试应用于Qt内容，那么你可以使用-DNDEBUG而不是-DQT_NO_DEBUG进行编译。

这在开发复杂的GUI应用程序时肯定非常有用。我不使用Qt (还没有？)但是看到在我选择的GTK+/gtkmm ...which工具包中使用这些东西的好处我确信存在，但我还没有查找它们;-)

我记得最近在这里进行了一次关于这方面的生动讨论，与一个正交提案的讨论交织在一起：ISO C++ Standard - Future Proposals › Exception stack trace information.