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

Re:C++17 constexpr everything, or as much as the compiler can by lazyjones on Thursday December 28, 2017 @09:04AM (#16022006)

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-inline-recursive-depth is taken into
  account. For functions not declared inline, recursive inlining happens only when
   -finline-functions (included in -O3) is enabled and --param
  max-inline-recursive-depth-auto is used. The default value is 8.

[ Parent | on HN ]

Re:C++17 constexpr everything, or as much as the compiler can by teamhappy on Thursday December 28, 2017 @10:28AM (#16022456)

You should watch the talk that's mentioned in the article. They demo a constexpr json parser and a constexpr regex engine.

[ Parent | on HN ]

Re:C++17 constexpr everything, or as much as the compiler can by lazyjones on Thursday December 28, 2017 @10:57AM (#16022704)

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.

[ Parent | on HN ]

Re:C++17 constexpr everything, or as much as the compiler can by CamperBob2 on Thursday December 28, 2017 @02:34PM (#16024284)

Exactly. This technique will be high on my list of things to try the next time I find myself complaining that my compiler is too fast.

Yet another C++ innovation that solves a problem that no one actually has.

[ Parent | on HN ]

Re:C++17 constexpr everything, or as much as the compiler can by teamhappy on Thursday December 28, 2017 @11:26AM (#16022966)

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

[ Parent | on HN ]

Re:C++17 constexpr everything, or as much as the compiler can by mwkaufma on Thursday December 28, 2017 @06:25PM (#16026018)

Although ordinary functions can be evaluated at compile time without the constexpr annotation, only constexpr functions will raise an error if it _can't_ be evaluated at compile time (irrespective of if the compile thinks it should be). it's a judgement call for when explicit intent > implicit side-effects.

[ Parent | on HN ]

Re:C++17 constexpr everything, or as much as the compiler can by sehugg on Thursday December 28, 2017 @10:33AM (#16022495)

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

[ Parent | on HN ]