All of this is easy in Common Lisp, which includes interactive compile-time debugging. You can use #., EVAL-WHEN, LOAD-TIME-VALUE, and other things to control evaluation time, and use the same, usual, interactive debugger that you use for runtime code, without any extra infrastructure or scaffolding. In C++, to debug failed constexpr’s, often, you have to make it a non-constexpr and debug at runtime.
or you can just use a C++ repl like Cling ?
C++17 constexpr everything, or as much as the compiler can
41–50 of 120 posts
Re: C++17 constexpr everything, or as much as the compiler can
#42Earlier quoted context omitted.
And have all embedded engineers raging because you just made cross compilation an order of magnitude harder.
Embedded engineer here. Care to explain why ? Code generation is widely used, at least in automotive. Comparison of hard-to-read and hard-to-debug advanced template/constexpr machinery vs code generated by standalone tool that is easy to read and easy to debug would not be taken seriously
Example: for the credit dept of a now-ex investment bank many moons ago we had a set of blessed (including with the correct correlations) random numbers pre-computed and baked in via code generation.
I discovered that I could actually generate numbers faster at run-time with highly-tuned code because of the high cost of paging in the large-precompiled numbers array across the network.
Re: C++17 constexpr everything, or as much as the compiler can
#43Yes, we are building a substantial embedded system with (a constrained subset of; no heap, but some templates for example) C++ 11. Heretical, I understand.
Re: C++17 constexpr everything, or as much as the compiler can
#44Earlier quoted context omitted.
Until you make release
After 3 months of development all I have to do is make release and ...
Re: C++17 constexpr everything, or as much as the compiler can
#45Earlier quoted context omitted.
You should watch the talk that's mentioned in the article. They demo a constexpr json parser and a constexpr regex engine.
I tried to watch the more interesting parts, it just doesn't seem like a useful approach to me to try to get the compiler to do this work at every compilation instead of the traditional approach of doing it once by generating C(++) code/structures from text/json data in my build. Especially with the "cognitive cost" and debugging issues involved.
Re: C++17 constexpr everything, or as much as the compiler can
#46>In conclusion, at the time of this writing, you need to inspect the generated code of your compiler, if you want to be sure that something is really calculated at compile time. I don't get this. Why? Doesn't making a variable constexpr ensure it is a compile time value, or it will fail to compile?
namespace detail {
template
constexpr T eval() { return val; }
};
#define FORCE_COMPILE_TIME(x) detail::eval()Re: C++17 constexpr everything, or as much as the compiler can
#47>In conclusion, at the time of this writing, you need to inspect the generated code of your compiler, if you want to be sure that something is really calculated at compile time. I don't get this. Why? Doesn't making a variable constexpr ensure it is a compile time value, or it will fail to compile?
Literally the second example shows a failing case for Clang 5 where GCC is able to statically compute it at compile time.
Re: C++17 constexpr everything, or as much as the compiler can
#48Earlier quoted context omitted.
Apparently constexpr is like "inline". Just as the inline keyword doesn't actually guarantee that the compiler will inline a function, so constexpr doesn't require the compiler to precompute something, but rather just gives a hint to the compiler that you'd like it to if it can.
constexpr means you CAN use the function in a constant expression inline means you CAN define a function in multiple translation units without violating ODR no guarantees in the other direction
Re: C++17 constexpr everything, or as much as the compiler can
#49Earlier quoted context omitted.
Literally the second example shows a failing case for Clang 5 where GCC is able to statically compute it at compile time.
That sounds like a bug in Clang?