3 ms·

Like "const", it's so the compiler can produce better feedback for the programmer, not better executables. constexpr will raise an error if a function _can't_ b

Like "const", it's so the compiler can produce better feedback for the programmer, not better executables. constexpr will raise an error if a function _can't_ be evaluated at compile-time, just as const functions will raise an error if they do any non-const stuff.

mehrdadn 9y ago
> Like "const", it's so the compiler can produce better feedback for the programmer, not better executables. constexpr will raise an error if a function _can't_ be evaluated at compile-time, just as const functions will raise an error if they do any non-const stuff. But how does it lead to better feedback? constexpr is purely suggesting an optimization that the compiler was already allowed to do anyway, and which it can still refuse to perform even with the keyword. If the programmer's goal is to ensure compile-time evaluation is guaranteed, constexpr won't cut it, since the compiler can (and compilers currently do) silently fall back to run-time evaluation. Alternatively, if the programmer's goal is to ensure compile-time evaluation is possible, constexpr still doesn't provide any value, since that's already obvious from the compiler analyzing the body of the function and noticing, say, that fopen() is getting called (and the compiler already has to do this anyway). The situation is very critically different from const, too. Adding 'const' to a method that was previously non-const, even when it is legal and compiles perfectly fine, can entirely change the semantics of the code, and hence you want that decision to be explicit, not implicit. This isn't the case with constexpr.
- mwkaufma 9y ago
  >> But how does it lead to better feedback? Because you can use static_asset (only accepts constexprs) and in C++17 static-if (a first class cousin to #if)
  - Too 9y ago
    Add std::array size initialization to that list, as demonstrated in the article.

mehrdadn 9y ago

> Like "const", it's so the compiler can produce better feedback for the programmer, not better executables. constexpr will raise an error if a function _can't_ be evaluated at compile-time, just as const functions will raise an error if they do any non-const stuff. But how does it lead to better feedback? constexpr is purely suggesting an optimization that the compiler was already allowed to do anyway, and which it can still refuse to perform even with the keyword. If the programmer's goal is to ensure compile-time evaluation is guaranteed, constexpr won't cut it, since the compiler can (and compilers currently do) silently fall back to run-time evaluation. Alternatively, if the programmer's goal is to ensure compile-time evaluation is possible, constexpr still doesn't provide any value, since that's already obvious from the compiler analyzing the body of the function and noticing, say, that fopen() is getting called (and the compiler already has to do this anyway). The situation is very critically different from const, too. Adding 'const' to a method that was previously non-const, even when it is legal and compiles perfectly fine, can entirely change the semantics of the code, and hence you want that decision to be explicit, not implicit. This isn't the case with constexpr.

mwkaufma 9y ago
>> But how does it lead to better feedback? Because you can use static_asset (only accepts constexprs) and in C++17 static-if (a first class cousin to #if)
- Too 9y ago
  Add std::array size initialization to that list, as demonstrated in the article.