Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

solarianprogrammer.com

Post reply on HN
Print view View original

31–40 of 120 posts

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

#31

Post by reikonomusha »

jcelerier wrote: post #25
reikonomusha wrote: post #13

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 ?

I’m not sure that’s even close to equivalent in execution-time debugging, and doesn’t work well with large, existing code bases with crafted build steps. These are transparent, non-issues in Common Lisp.

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

#32

Post by phaedrus »

andrepd wrote: 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?

At first I was going to say that it's similar to asm.js - that it enabled an optimization but also could fall back to just running the code. However in trying to find references to back up my answer, I found a different explanation of constexpr which changed my own understanding.

https://stackoverflow.com/questions/38879475/why-cant-conste...

Quoting Ben Voigt: "What constexpr does is provide guarantees on what data-flow analysis a compliant compiler is required to do to detect1 compile-time-computable expressions, and also allow the programmer to express that intent so that they get a diagnostic if they accidentally do something that cannot be precomputed."

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

#33

Post by sehugg »

lazyjones wrote: post #15

I'm not sure this is really necessary. gcc and Apple's clang optimize the factorial code without "constexpr" and the fibonacci code might be an extreme case avoided by reasonable defaults for the numerous optimization parameters that can be adjusted: max-inline-recursive-depth max-inline-recursive-depth-auto Specifies the maximum recursion depth used for recursive inlining. For functions declared inline, --param max-…

This is probably why factorial(5) is statically eval'ed and fibonacci(10) is not.

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

#34

Post by mike_hock »

nurettin wrote: post #28
skrebbel wrote: post #14

Earlier quoted context omitted.

That makes the compiler not complain when your constexpr isn't a valid constexpr.

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

#35

Post by mnarayan01 »

andrepd wrote: 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?

> Doesn't making a variable constexpr ensure it is a compile time value

It ensures that the variable could be evaluated at compile time, where "could be evaluated at compile time" means "conforms to the rules set forth in the C++ standard". Whether or not it is computed at compile time is dependent on the compiler.

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

#37

Post by hzhou321 »

If you use a general meta layer preprocessor such as MyDef, you may be able to construct macros that comes from evaluations of code in any languages (instead of restricted in eg. C++ with rather complicated compiler mechanics)

A constexpr is a constant that is evaluated from a code at compile time, which is essentially just macros. Right?

A general preprocessor that just do language agnostic code manipulations are not difficult but rather useful. Much complicated syntax sugar I see in the recent language development become unnecessary if a general preprocessor is in place (where syntactic sugar belong). I wonder why it is often not used.

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

#38

Post by kxhost »

Elv13 wrote: post #17
uncle_bob wrote: post #8

C++ is never just C++. The build system for any C++ program includes both macro language and some form of make and/or make replacement. Explicitly generating tables at compile time and linking is bog standard at this point. Write a table generator program, have output create a table, splice in the order into make and/or make replacement. Sure it's three extra steps, but it's small steps that can be debugged. It also…

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

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

#39

Post by lazyjones »

teamhappy wrote: post #27
lazyjones wrote: post #15

I'm not sure this is really necessary. gcc and Apple's clang optimize the factorial code without "constexpr" and the fibonacci code might be an extreme case avoided by reasonable defaults for the numerous optimization parameters that can be adjusted: max-inline-recursive-depth max-inline-recursive-depth-auto Specifies the maximum recursion depth used for recursive inlining. For functions declared inline, --param max-…

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

#40

Post by tambre »

hzhou321 wrote: post #37

If you use a general meta layer preprocessor such as MyDef, you may be able to construct macros that comes from evaluations of code in any languages (instead of restricted in eg. C++ with rather complicated compiler mechanics) A constexpr is a constant that is evaluated from a code at compile time, which is essentially just macros. Right? A general preprocessor that just do language agnostic code manipulations are no…

> A constexpr is a constant that is evaluated from a code at compile time, [...]

It's rather a constant expression, which is quite a bit more than a mere constant.

> [...] which is essentially just macros. Right?

Macros are basically just text replacement. You can't write a macro and expect most compilers to execute the expressions and code inside the macro at compile-time. Some compilers may still to do that, but it's not very common for more complicated stuff. With constexpr you get a guarantee that the expression can be evaluated at compile-time and it gives quite a good hint to the optimizer to spend more time optimizing that portion of the code.

Post reply on HN