C++26: A User-Friednly assert() macro • Hacker News Board

Re: C++26: A User-Friednly assert() macro

#41

Post by andrepd » Sat, Mar 28, 2026, 9:14 PM UTC

MontagFTB wrote: post #5

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.

Rust has assert and debug_assert, which are self-explanatory. But it also has an assert_unchecked, which is what other languages incl C++ call an "assume" (meaning "this condition not holding is undefined behaviour"), with the added bonus that debug builds assert that the condition is true.

Re: C++26: A User-Friednly assert() macro

#42

Post by puschkinfr » Sat, Mar 28, 2026, 9:17 PM UTC

wpollock wrote: post #39

> assert(x > 0 && "x was not greater than zero"); Shouldn't that be "||" rather than "&&"? We want the message only if the boolean expression is false.

No, because the string will be implicitly converted to `true` and `(a && true) == a` (for boolean `a`), so it will only be `false` if the assertion fails. Using || would always evaluate to `true`

Re: C++26: A User-Friednly assert() macro

#43

Post by nealabq » Sat, Mar 28, 2026, 9:32 PM UTC

toxik wrote: post #20

nealabq wrote: post #17

Earlier quoted context omitted.

I don't mean to be that guy, but for "functional" programmers a print statement has "side effects". But your meaning is clear. In an assert expression, don't call functions that might change the program/database state. Be as "const" as possible.

Not just for functional programmers. Prints and other I/O operations absolutely are side effects. That's not running counter to the point being made. Print in an assert and NDEBUG takes away that behavior.

You're right of course. I was thinking specifically of printing log/debug statements in the assert(..), but that usually only happens if the assert(..) fails and exits, and in that case the "no side effects" rule no longer matters.

Re: C++26: A User-Friednly assert() macro

#44

Post by bluGill » Sat, Mar 28, 2026, 9:53 PM UTC

MontagFTB wrote: post #5

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.

Related our logging system has a debug which is not logged by default but can be turned on if a problem in an area is found (in addition to the normal error/info which is logged). I had the idea that if a test fails we should print all these debugs - easy enough to turn on but a number of tests failed because of side effects that didn't show up when off.

i'm trying to think of how/if we can run tests with all logging off to find the error and info logs with side effects.

Re: C++26: A User-Friednly assert() macro

#45

Post by dataflow » Sat, Mar 28, 2026, 10:03 PM UTC

dccsillag wrote: post #22

maccard wrote: post #21

Earlier quoted context omitted.

Indeed. bool is_even(int* valPtr) { assert(valPtr != nullptr); return *valPtr % 2; } Does not do what you think it does with nullptr. A major game engine [0] has a toggle to enable asserts in shipping builds, mostly for this reason [0] https://dev.epicgames.com/documentation/en-us/unreal-engine/...

I'm sorry, but what exactly is the problem with the code? I've been staring at it for quite a while now and still don't see what is counterintuitive about it.

Depends on where you're coming from, but some people would expect it to enforce that the pointer is non-null, then proceed. Which would actually give you a guaranteed crash in case it is null. But that's not what it does in C++, and I could see it not being entirely obvious.

Re: C++26: A User-Friednly assert() macro

#46

Post by [deleted] » Sat, Mar 28, 2026, 10:36 PM UTC

puschkinfr wrote: post #42

wpollock wrote: post #39

> assert(x > 0 && "x was not greater than zero"); Shouldn't that be "||" rather than "&&"? We want the message only if the boolean expression is false.

No, because the string will be implicitly converted to `true` and `(a && true) == a` (for boolean `a`), so it will only be `false` if the assertion fails. Using || would always evaluate to `true`

[deleted]

Re: C++26: A User-Friednly assert() macro

#47

Post by [deleted] » Sat, Mar 28, 2026, 10:44 PM UTC

maccard wrote: post #21

MontagFTB wrote: post #5

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.

Indeed. bool is_even(int* valPtr) { assert(valPtr != nullptr); return *valPtr % 2; } Does not do what you think it does with nullptr. A major game engine [0] has a toggle to enable asserts in shipping builds, mostly for this reason [0] https://dev.epicgames.com/documentation/en-us/unreal-engine/...

[deleted]

Re: C++26: A User-Friednly assert() macro

#48

Post by IshKebab » Sat, Mar 28, 2026, 10:55 PM UTC

dataflow wrote: post #45

dccsillag wrote: post #22

Earlier quoted context omitted.

I'm sorry, but what exactly is the problem with the code? I've been staring at it for quite a while now and still don't see what is counterintuitive about it.

Depends on where you're coming from, but some people would expect it to enforce that the pointer is non-null, then proceed. Which would actually give you a guaranteed crash in case it is null. But that's not what it does in C++, and I could see it not being entirely obvious.

Assert doesn't work like that in any language.

Re: C++26: A User-Friednly assert() macro

#49

Post by IshKebab » Sat, Mar 28, 2026, 10:57 PM UTC

nmilo wrote: post #37

omoikane wrote: post #8

Earlier quoted context omitted.

assert() is meant to be compiled away if NDEBUG is defined, otherwise it shouldn't be called assert(). Given that assert() may be compiled away, it makes sense not to give it anything that has side effects. Abseil has the convention where instead of assert(), users call "CHECK" for checks that are guaranteed to happen at run time, or "DCHECK" for checks that will be compiled away when NDEBUG is defined. https://githu…

If your assert compiles down to `if (condition) {}` in production then the compiler will optimize away the condition while keeping any side effects.

Yeah which may not be what you want. E.g. `assert(expensive_to_compute() == 0)`.

The correct way to solve this is with debug asserts (as in Rust, or how the parent described).

Re: C++26: A User-Friednly assert() macro

#50

Post by comex » Sat, Mar 28, 2026, 11:02 PM UTC

IshKebab wrote: post #48

dataflow wrote: post #45

Earlier quoted context omitted.

Depends on where you're coming from, but some people would expect it to enforce that the pointer is non-null, then proceed. Which would actually give you a guaranteed crash in case it is null. But that's not what it does in C++, and I could see it not being entirely obvious.

Assert doesn't work like that in any language.

It does in Rust: assert is always enabled, whereas the debug-only version is called debug_assert.

But yes, “assert” in most languages is debug-only.