c++ - 是否有任何理由不将 assert() 包装在解析为 gcc 中的 __builtin_unreachable() 的宏中？

Question

上下文:在这个answer ，我了解到 gcc 的 __builtin_unreachable() 可能会对性能产生一些令人惊讶的影响，因为看起来如下:

if(condition) __builtin_unreachable();

被完全剥离，用作优化提示，只要condition可以保证没有任何副作用。

所以我对此的直接 react 是我应该创建以下宏，并且绝对在我通常使用 assert() 的所有地方使用它，因为在 assert 中会产生副作用() 首先会是一个主要错误:

// TODO: add handling of other compilers as appropriate.
#if defined(__GNUC__) && defined(NDEBUG)
  #define my_assert(condition) \
    if(!(condition)) __builtin_unreachable()
#else 
  #define my_assert(condition) assert(condition)
#endif

从标准的角度来看，这将在正常和 NDEBUG 构建之间创建功能拆分，您可以将此宏排除在 assert()< 的标准行为之外。但是，由于无论如何在断言失败的情况下我的代码在功能上都会死于水中，因此从行为的角度来看它是完全等价的。

所以我的问题是:谁能想到不这样做的理由(除了涉及大量间接的断言)？

在你问之前，是的，我已经检查过 gcc 的行为是在 NDEBUG 构建中放弃断言。

Answer 1

是的，有理由不使用它。有些人使用以下结合断言和异常的防御代码实践 (assert(x>0); if (!(x<0)) throw std::logic_error("..")) - 请参阅此答案:

Test Cases AND assertion statements

您的宏会默默地破坏发布版本的异常部分。