On 2022-08-17 at 16:52, Florian Gavril via Std-Proposals wrote:
> Hello,
>
> As everyone knows that, the assert macro is very useful to find out
> unexpected conditions on the development stage, but for the production
> builds, the NDEBUG is usually enabled and assert is actually disabled.
> If assert is used, for example, in a function, to check if one of the
> parameters is not NULL, the program execution is terminated and some
> messages are displayed. But if NDEBUG is defined, the program will
> silently continue until the disaster happens. In order to avoid this
> situation, the programmer adds a double check for that parameter with a
> retur routine.
>
> Basic example:
> int func(int *p) {
> * assert(p);
> if (p == NULL) {
> return 0;
> }*
> ..........
> return 1;
> }
>
> My proposal is to re-define assert or define a new macro (let's say
> assertr, pretty much like assertm) which will take two arguments:
> condition and the return value for non-debug builds, In this case, the
> previous code may be compacted:
> int func(int *p) {
> *assertr(p, 0);*
> ..........
> return 1;
> }
>

Nothing stops you from defining additional macros for your projects. Why
do they have to be standardized?

The way to enable asserts in non-debug builds is otherwise

#undef NDEBUG
#include <cassert>