4 ms·

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 avo

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.

teamhappy 9y ago
You should watch the talk that's mentioned in the article. They demo a constexpr json parser and a constexpr regex engine.
- lazyjones 9y ago
  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.
  - teamhappy 9y ago
    Fair enough. I assumed you didn't consider the more complex use-cases because you mentioned compilers already doing this for small functions.
  - CamperBob2 9y ago
    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.
sehugg 9y ago
This is probably why factorial(5) is statically eval'ed and fibonacci(10) is not.
mwkaufma 9y ago
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.

teamhappy 9y ago

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

lazyjones 9y ago
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.
- teamhappy 9y ago
  Fair enough. I assumed you didn't consider the more complex use-cases because you mentioned compilers already doing this for small functions.
- CamperBob2 9y ago
  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.

sehugg 9y ago

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

mwkaufma 9y ago

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.