Avoiding Side Effects in Assertions

In general, it's best practice to avoid side effects in assertions. Assertions should be used to check invariants and preconditions, not to modify state or perform logic that affects program behavior.

Here's an example of an assertion with a side effect:

1#include <cassert>
2
3void risky_increment(int& x) {
4  assert(++x > 0);
5}
6
7int main() {
8  int a = 0;
9  risky_increment(a);
10  // What's the value of a here?
11}

The problem with this is:

1. It's not immediately clear that x is being modified by the assertion.
2. The behavior of the function changes depending on whether assertions are enabled (e.g. in debug vs release builds).

Instead, perform any necessary modifications separately and then assert on the result:

1#include <cassert>
2
3void safe_increment(int& x) {
4  ++x;
5  assert(x > 0);
6}

This makes the increment explicit and ensures the function behavior is consistent regardless of assertion settings.

A similar guideline applies to assertions in constructors or destructors. Avoid complex logic or side effects that could leave the object in an indeterminate state if an assertion fails:

1class User {
2  std::string name;
3  int age;
4public:
5  User(std::string name, int age) : name(name), age(age) {
6    assert(age >= 0);
7  }
8};

Here, if the age assertion fails, the User object will still be constructed with whatever name value was provided. It's cleaner to validate the inputs before performing any initialization.

In summary:

• Keep assertions side-effect free when possible
• Perform any complex validation or mutation logic outside of assertions
• Be mindful of assertions in special member functions to avoid half-initialized or half-destructed states