Discussion
C++26: A User-Friendly assert() macro
nyc_pizzadev: 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.
omoikane: > (assert) doesn't follow the usual SCREAMING_SNAKE_CASE convention we associate with macrosThere 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.
MontagFTB: 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.
nyc_pizzadev: 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...
jmalicki: Side effects are bad of course, but anything beyond a straight boolean or equality is bad?`assert(vector.size() < 3)` is ridiculous to you?
throwpoaster: assert(spellcheck(“Friednly”));
BoingBoomTschak: 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.
amelius: Shouldn't the preprocessor be fixed, if it trips that easily on common C++ constructs?
tom_: I'm sure the standardization committee are always looking for fresh ideas!
semiinfinitely: "C++47: Finally, a Standard Way to Split a String by Delimiter"
grokcodec: Friedns shouldn't let Freidns post on HN without running spell check
nealabq: In C++ you should probably #include <cstdio> instead of <stdio.h> unless you have a good reason. And especially avoid #including both. <cstdio> provides the function std::getc(..) while <stdio.h> usually provides getc(..) as a macro.htons(..) and related socket-utility names are also often macros, but I'm pretty sure there is not a std::htons(..) in the C++ standard, partly because 'htons' is not an attractive name. Since it's (sometimes) a macro don't qualify its namespace like ::htons(..).A long time ago in the Microsoft C (and later C++) dev envs there were macros named "min" and "max", which I thought were terrible names for macros.
usrnm: I once spent several days debugging that same mistake. Stuff worked perfectly in tests but broke misteriously in production builds. Couldn't stop laughing for a few minutes when I finally figured it out.
nealabq: 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.
