Using Assert in Release Builds

There are a few ways to keep certain assert() calls active in release builds:

Option 1: Rather than defining the global NDEBUG macro disable assert() calls, we can implement our own conventions. For example, we could use #ifdef directives with macros that have names like ENABLE_ASSERTIONS and ENABLE_RELEASE_ASSERTIONS:

1#include <cassert>
2
3int Divide(int x, int y) {
4#ifdef ENABLE_RELEASE_ASSERTIONS
5  assert(y != 0 && "Cannot divide by zero");
6#endif
7  return x / y;
8}

We then have more granular control over which assertions are enabled, based on which definitions we provide in our project settings

Option 2: Create a custom assert-like macro that isn't disabled in release builds. In the following example, our RELEASE_ASSERT() macro will be used whether or not NDEBUG is defined:

1#include <iostream>
2
3#define RELEASE_ASSERT(expr)                 \
4  if (!(expr)) {                             \
5    std::cerr << "Assertion failed: " #expr; \
6    abort();                                 \
7  }
8
9int Divide(int x, int y) {
10  RELEASE_ASSERT(y != 0);  
11  return x / y;
12}
13
14int main() {
15  Divide(2, 0);
16}

1Assertion failed: y != 0

Option 3: Use logging libraries like spdlog or Boost.Log that offer assertion-like checks which remain enabled in release builds by default.

In general, the decision to keep assertions enabled in release builds is a tradeoff between performance and catching/logging critical errors. Enable them selectively for the most crucial checks.