I had some fun recently using (abusing?) `constexpr` to process string literals at compile time to ‘compress’ then in the binary and save a few bytes in my microcontroller.
https://gist.github.com/th-in-gs/7f2104440aa02dd36264ed6bc38...
I’m just shaving some bits off - but I guess in principle you could do anything that’s `constexpr` evaluatable. Gzip compression of static buffers?…
Godbolt example:
Why
uint8_t b = 0b1111'1111;
uint8_t b = 0b1111_1111;
In-line class static variables ... finally.
if constexpr is neat (along with a bunch of the other constexpr/compile-time features that have been coming along), but I feel like this will have both... good and bad uses, and I fear for the astronauts who will go crazy with this.
The enhanced conditionals, this I kind of like though it would take some while to get used to... kind of surprised this got in, being such a departure from C.
Small thing: hardware_destructive_interference_size is nice. Wish I had this in Rust.
Looks like it was asked for (https://github.com/rust-lang/rfcs/issues/1756) but went nowhere.
Isn’t polymorphic memory allocator the most significant recent C++ addition for embedded systems that allows preventing runtime memory allocation after the init phase and thus allows conformity to MISRA and other guidelines for critical SW development (esp. when using stdlib)?
Not really sure they are that useful for embedded systems. I think the most useful thing is in 20, and that is coroutines. For bare metal embedded systems this simplifies a lot of things. But isn't super common on embedded toolchains yet.
Not a C++ developer but nodiscard is gross in my opinion. I've seen codebases littered with it for no good reason. Why should you care if the caller uses the return value or not?
Hey rust - check it out. Compile time evaluation without macros, isn’t that neat?
Wrt hardware_destructive_interference_size, what happens if you compile for X86 which is then run on a machine (Rosetta) that has a (2x) bigger cacheline internally?
So much of modern c++ is trying to get around just using the preprocessor.
`if constexpr` is such a disaster. They were so close to getting it right (not introducing a scope) but they missed.
Similarly constexpr itself is also genuinely ridiculous: (I have said this on hackernews before) It's such a stupid idea to require an annotation everywhere you want to evaluate things at compile time, practically everything will inevitably be evaluatable at compile time, and you need the implementation anyway, so just let it fail rather than ask for permission everywhere.
Having the keyword for variables and constants is fine (i.e. top down and bottom up constraints need to be dictated) but you shouldn't need to write constexpr more than that.
What compiler is he/she using? I cannot get this to compile at all but I might not know the magic compiler incantation to get it to work.
template<typename T>
auto length(const T& value) noexcept {
if constexpr (std::integral<T>::value) { // is number
return value;
}
else {
return value.length();
}
}I'm sure other languages would have more than 17 useful features.
The whole discussion about constexpr (even though a useful feature), is one example, out of many, of what a f up language C++ is/has become. It's astonishing how many people have to say... I don't like the language but there's no good alternative for the context we are working in.
I added 0b binary literals to C++ back in the 1980s.
https://www.digitalmars.com/ctg/ctgLanguageImplementation.ht...