问题 捕获带有副作用的assert（）

尽管这个问题已经收到许多无益的非答案，但我认为它在遗留代码库的上下文中有很多优点。

想象一下，多年来积累了许多断言，但由于没有使用NDEBUG构建/测试的习惯，一些副作用已经渗入断言，现在你不再禁用断言了。

您可以在测试套件中打开NDEBUG并检测一些测试失败，但将测试失败与“有效”断言联系起来并不是一件容易的事，因为它可能距离您检测到失败的位置非常远。即使是具有良好覆盖范围的测试套件也无法完全信任。

您可以对代码中的所有断言进行代码审查，但这可能是很多工作并且容易出现人为错误。如果某些静态分析已经可以消除所有断言，那将会好得多 证明 没有副作用出现，你只需要调查他们缺席的情况。

以下是如何使用编译器的优化器进行此类静态分析的方法。假设您组织替换的定义 assert 宏观：

extern int not_supposed_to_survive;
#define assert(expr) ((void)(not_supposed_to_survive || (expr)))

如果 expr 有任何副作用，效果的执行是以全局变量的值为条件的 not_supposed_to_survive。但如果 expr 没有任何副作用，全局变量的值无关紧要（注意 expr 结果被丢弃）。 一个好的优化器知道这一点，并将消除全局变量的负载 not_supposed_to_survive因此变量的名称。

如果我们的程序不包含符号的定义 not_supposed_to_survive，当没有消除负载时，我们将得到链接错误，我们可以使用它来检测可能有效的断言。

例如。与gcc 4.8：

int g;

int foo() { return ++g; }

int main() {
    assert(foo());
    return 0;
}

gcc -O2 assert_effect.c
/tmp/ccunynya.o: In function `main':
assert_effect.c:(.text.startup+0x2): undefined reference to `not_supposed_to_survive'
collect2: error: ld returned 1 exit status

编译器帮我找到了一个可疑的断言！另一方面，如果我更换 ++g 通过 g+1，链接错误消失，我不必调查。实际上，这种说法是无害的。

当然，可证明无副作用的概念受到优化器“可以看到”的限制。为了更精确的分析，我建议使用链接时间优化（gcc -flto）分析编译单元。

更新： 我使用gcc 5.3将它应用于现实生活中的C ++代码库。要使用链接时优化，您基本上使用 gcc -flto -g 作为编译器/链接器（ -g 编译器/链接器上的选项以获取链接错误的行引用）和 gcc-ar 和 gcc-ranlib 作为任何静态库的归档器/索引器。

这种设置可以极大地减少我必须调查的断言数量。凭借最小的人力，我能够让断言干净。我仍然需要手动拒绝的误报是由于：

• 虚函数调用
• 非平凡的循环/递归（优化器无法证明它们是有限的）

另外，我还会得到一些确实包含副作用的断言，但它们是无害的或不重要的，例如：

• 包含日志语句的函数
• 缓存其结果的函数