Live data from Hacker News

C++17 constexpr everything, or as much as the compiler can

solarianprogrammer.com

41–50 of 120 posts

Re: C++17 constexpr everything, or as much as the compiler can

#41

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 ?

What the C++ repl does with constexpr functions would be unrelated to the code generated by the actual C++ compiler.

Re: C++17 constexpr everything, or as much as the compiler can

#42
post #38
post #17

Earlier 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

Both approaches have their problems, but resolving to compile-time constants with simple expressions is NOT "hard-to-debug" if done with care. As ever, tools can be abused, and real life can astonish.

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

#43
I am already a big fan of constexpr-ing everything that doesn't run away or make the compiler cry for our embedded application.

Yes, 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

#44

Earlier quoted context omitted.

Until you make release

After 3 months of development all I have to do is make release and ...

If you guys are going three days without testing a release build (let alone three months), then you probably have bigger issues to work through than what constexpr is doing...

Re: C++17 constexpr everything, or as much as the compiler can

#45

Earlier 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.

Fair enough. I assumed you didn't consider the more complex use-cases because you mentioned compilers already doing this for small functions.

Re: C++17 constexpr everything, or as much as the compiler can

#46
post #19

>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?

For integral values you can use a little hack to ensure compile-time evaluation:

    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
post #19

>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.

That sounds like a bug in Clang?

Re: C++17 constexpr everything, or as much as the compiler can

#48
post #22

Earlier 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

Gotcha, I think I understood it.

Re: C++17 constexpr everything, or as much as the compiler can

#49
post #47

Earlier 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?

It may not be a bug. The computation of Fibbonacci(10) requires a stack of ten frames. It may be that Clang has a limit on the depth of the stack for pre-compiled code.
Post reply on HN