C++:contst static DEBUG 和 if 语句，实际的执行时间开销是多少

C++: contst static DEBUG and if statements, what is the actual execution-time overhead?

本文关键字：执行时间 开销 多少 语句 contst static DEBUG if C++      更新时间：2023-10-16

在学校里，我经常被教导预处理器语句很容易失控，因为你定义的字符串，例如：

#define PI 3.1415926

在代码中的每个位置都被替换，当变量名包含字符串PI时，会导致奇怪的替换。

因此，在调试时，我避免使用以下方法：

#define _DEBUG
...
#ifdef _DEBUG
    // debug code
#endif
...

但硬，使用起来会"更安全"：

const static bool DEBUG = true
int main()
{
    ...
    if(DEBUG){ /* debug code*/ }
    ...
}

这很好用，但我想知道与预处理器语句方法相比，这种方法在运行时的开销是多少？使用预处理器方法，一切都发生在编译之前，因此不会产生运行时开销。

我知道一个简单的 if -语句的开销几乎被忽略了，但是当它深入到一些运行大量次数的嵌套循环中时，这并不成立（小事情加起来就是大事情）。

编译器是否认识到DEBUG const static并将其硬编码到可执行文件中，已经在编译时启用或禁用调试代码？让我怀疑的是，前几天，在处理一些不相关的代码时，编译器警告我代码的某些部分已经过时，因为围绕它的if语句永远不会成为现实（如果我没记错的话）。

不可能

给出硬保证：这取决于每个编译器如何处理你提供给它的代码。

但是，任何实际的编译器都会为您优化这一点。它是现有最简单、最琐碎的优化之一，即使您禁用优化，大多数编译器也可能会这样做。

为本质上if (true)的东西生成代码是没有意义的。

因此，运行时的开销应该为零。

标准中没有任何内容说编译器不能完全省略一段代码，如果它可以静态地（在编译时）确定它永远不会运行。

另一方面，标准中也没有说编译器必须进行优化（在一般情况下）。

因此，如果您为编译器提供足够的信息，并打开其优化功能，则很有可能完全消除这些分支。但确定的唯一方法是查看生成的代码。

对于像这样的"琐碎"调试启用代码，大多数现代编译器在大多数情况下都会完全消除死块。

在学校里，我经常被教导预处理器语句很容易失控，因为你定义的字符串，例如：

#define PI 3.1415926

在代码中的每个位置都被替换，当变量名称包含字符串 PI 时会导致奇怪的替换

不，PI只替换整个单词（令牌）PI，而不是在另一个令牌内。 例如 myPI不会扩展PI.

这是一个细节，但由于 DEBUG 现在是常量布尔值，你应该用小写字母来写它：

const static bool debug = true;

大写名称保留给预处理器宏。

相关文章：