C++26: A User-Friednly assert() macro
sandordargo.com
C++26: A User-Friednly assert() macro
1–10 of 89 posts
Re: C++26: A User-Friednly assert() macro
#2[deleted]
Re: C++26: A User-Friednly assert() macro
#3The 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.
Re: C++26: A User-Friednly assert() macro
#4> (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.
Re: C++26: A User-Friednly assert() macro
#5Putting 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.
Re: C++26: A User-Friednly assert() macro
#6Putting 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.
This is just a symptom of a bad assert() implementation, which funny enough is the standard. If you properly (void) it out, side effects are maintained.
https://github.com/fiberfs/fiberfs/blob/7e79eaabbb180b0f1a79...
Re: C++26: A User-Friednly assert() macro
#7Putting 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.
Side effects are bad of course, but anything beyond a straight boolean or equality is bad?
`assert(vector.size() < 3)` is ridiculous to you?
Re: C++26: A User-Friednly assert() macro
#8Putting 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.
This is just a symptom of a bad assert() implementation, which funny enough is the standard. If you properly (void) it out, side effects are maintained. https://github.com/fiberfs/fiberfs/blob/7e79eaabbb180b0f1a79...
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://github.com/abseil/abseil-cpp/blob/0093ac6cac892086a6...
https://github.com/abseil/abseil-cpp/blob/0093ac6cac892086a6...
Re: C++26: A User-Friednly assert() macro
#9The 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.
Yeah, but the macro system being so pitiful makes me long for one that allows something as magical as fiveam's is (https://github.com/lispci/fiveam/blob/e43d6c8e7da5a80d5c33e8...) instead of having to write special cases for unary and binary predicates.
Re: C++26: A User-Friednly assert() macro
#10assert(spellcheck(“Friednly”));