Putting code with side effects into an assert is asking for trouble. Compile with NDEBUG set and the effects mysteriously disappear! Anything beyond an equality expression or straight boolean should be avoided.

> (assert) doesn't follow the usual SCREAMING_SNAKE_CASE convention we associate with macros

There are a few things like that, for example:

https://en.cppreference.com/w/c/numeric/math/isnan - isnan is an implementation defined macro.

https://en.cppreference.com/w/c/io/fgetc - `getc` may be implemented as a macro, but often it's a function.

The nice thing about assert() is you can just define your own:

https://github.com/fiberfs/fiberfs/blob/7e79eaabbb180b0f1a79...

In this case, the ability to see the actual values that triggered the assert is way more helpful.

One of my favorite things from ATL/WTL was the _ASSERT_E macro which additionally converts the source expression to text for a better message to be logged

Friedns shouldn't let Freidns post on HN without running spell check

Shouldn't the preprocessor be fixed, if it trips that easily on common C++ constructs?

"C++47: Finally, a Standard Way to Split a String by Delimiter"

assert(spellcheck(“Friednly”));