> make sure you know what your assert does, and when it does that, if you have a debug and release build Absolutely. Probably the most common difference I've s

> make sure you know what your assert does, and when it does that, if you have a debug and release build Absolutely. Probably the most common difference I've seen in "Debug" and "Release" builds relying on the standard library headers is when NDEBUG is defined as a macro when <assert.h> is included, which causes assert to become a no-op [0]. This has interesting implications when developers accidentally rely on the side effects of functions and assert on the return value of that helper. On "Release" builds that side effect would be compiled out. For that case, clang-tidy has the bugprone-assert-side-effect [1] checker if you want to enforce this in your CI. [0] https://en.cppreference.com/w/c/error/assert https://en.cppreference.com/w/c/error/assert [1] https://clang.llvm.org/extra/clang-tidy/checks/bugprone-assert-side-effect.html https://clang.llvm.org/extra/clang-tidy/checks/bugprone-asse...