Shouldn't the preprocessor be fixed, if it trips that easily on common C++ constructs?
C++26: A User-Friednly assert() macro
11–20 of 89 posts
Re: C++26: A User-Friednly assert() macro
#12"C++47: Finally, a Standard Way to Split a String by Delimiter"
Re: C++26: A User-Friednly assert() macro
#13Shouldn't the preprocessor be fixed, if it trips that easily on common C++ constructs?
I'm sure the standardization committee are always looking for fresh ideas!
Re: C++26: A User-Friednly assert() macro
#14Friedns shouldn't let Freidns post on HN without running spell check
Re: C++26: A User-Friednly assert() macro
#15Shouldn't the preprocessor be fixed, if it trips that easily on common C++ constructs?
Preprocessor is just doing text transformations on the sources.
It's not really something that can be fixed, other than moving away from the preprocessor and putting metaprogramming capabilities into the language itself (which C++ has been doing).
Re: C++26: A User-Friednly assert() macro
#16> (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.
In C++ you should probably #include instead of unless you have a good reason. And especially avoid #including both. provides the function std::getc(..) while 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.
Re: C++26: A User-Friednly assert() macro
#17Putting 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.
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.
Re: C++26: A User-Friednly assert() macro
#18Putting 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.
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.
Re: C++26: A User-Friednly assert() macro
#19"C++47: Finally, a Standard Way to Split a String by Delimiter"
I'm still waiting for C++ to support Unicode properly.
Re: C++26: A User-Friednly assert() macro
#20Putting 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.
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.