5 ms·

> I don't think it's that simple. You need a way to differentiate code that runs at compile time and code that runs at runtime (because at compile time you can

> I don't think it's that simple. You need a way to differentiate code that runs at compile time and code that runs at runtime (because at compile time you can afford a "slow" algorithm, while at run-time you'll be calling into a proprietary binary which will do the computation on a GPU or something like that). You mean std::is_constant_evaluated()? You don't need constexpr to be able to have that.

jcelerier 5y ago
but how will you differentiate a call that you want to perform at compile-time vs at run-time? e.g. if you want to run some unit tests to check the two algos, today you'd do: int res = my_algo(); CHECK(res == 123); ... constexpr int res = my_algo(); CHECK(res == 123); // compile-time version is the same with int my_algo() { if constexpr(is_constant_evaluated()) { return 123; else return some_lib->very_advanced_computation(); } how do you do the same without the constexpr keyword ? i'd rather not introduce a template struct just to get a constexpr context, à la template<auto Value> struct manually_constexpr { static constexpr auto value = Value; }; CHECK(manually_constexpr<my_algo()>::value == 123);
- petters 5y ago
  "constexpr" does not do what you think it does. For example, "if constexpr(is_constant_evaluated())" is always true, I think. See also the new C++ keyword "consteval" (yes, really!)
  - jcelerier 5y ago
    ah yes, that'll teach me to type on my phone :) what do you think that I think that constexpr does ? constexpr in a variable forces the variable's value to be evaluated in a constant expression context (which comes with footgunes, see an in-depth coverage of the issue there: https://gist.github.com/Som1Lse/5309b114accc086d24b842fd803ba9d2 https://gist.github.com/Som1Lse/5309b114accc086d24b842fd803b...)
- dataflow 5y ago
  > but how will you differentiate a call that you want to perform at compile-time vs at run-time? You could never do that to begin with. The compiler was always free to evaluate your function at compile time (and already did so in some cases). > e.g. if you want to run some unit tests to check the two algos Just make two separate functions and compare their outputs. That's what functions are for! So you don't put everything in one giant block of code. > i'd rather not introduce a template struct just to get a constexpr context, à la The standard library could do that for you instead of introducing a new keyword. In fact it practically already did so with std::integral_constant; they just need to update it for C++20 to avoid the redundancy. Or they could've introduced a [[pure]] attribute, or other less intrusive mechanisms. The keyword wasn't necessary for anything you mentioned. Also, as the sibling comment said, you might want to check out consteval.
  - jcelerier 5y ago
    > You could never do that to begin with. The compiler was always free to evaluate your function at compile time (and already did so in some cases). no, that is false. the constant expression context is specified by the standard - the following will always hold if your compiler is not braindead : https://gcc.godbolt.org/z/zEEbWbhvr https://gcc.godbolt.org/z/zEEbWbhvr
    - dataflow 5y ago
      >> You could never do that to begin with. The compiler was always free to evaluate your function at compile time (and already did so in some cases). > no, that is false. Your sentence is false, not mine. See below. > the constant expression context is specified by the standard Expressions can be evaluated at compile-time outside of "constant expression contexts", under the as-if rule. That's one of the main things compilers do when optimizing code.
      - jcelerier 5y ago
        > Expressions can be evaluated at compile-time outside of "constant expression contexts", under the as-if rule. yes, but that does not make it a constexpr context, which is something explicitely specified by the standard. See my code example: the compiler is obviously able to evaluate foo() at compile time, yet it knows that the evaluation it does at compile time will yield a different result that the one it does in a constexpr context.

jcelerier 5y ago

but how will you differentiate a call that you want to perform at compile-time vs at run-time? e.g. if you want to run some unit tests to check the two algos, today you'd do: int res = my_algo(); CHECK(res == 123); ... constexpr int res = my_algo(); CHECK(res == 123); // compile-time version is the same with int my_algo() { if constexpr(is_constant_evaluated()) { return 123; else return some_lib->very_advanced_computation(); } how do you do the same without the constexpr keyword ? i'd rather not introduce a template struct just to get a constexpr context, à la template<auto Value> struct manually_constexpr { static constexpr auto value = Value; }; CHECK(manually_constexpr<my_algo()>::value == 123);

petters 5y ago
"constexpr" does not do what you think it does. For example, "if constexpr(is_constant_evaluated())" is always true, I think. See also the new C++ keyword "consteval" (yes, really!)
- jcelerier 5y ago
  ah yes, that'll teach me to type on my phone :) what do you think that I think that constexpr does ? constexpr in a variable forces the variable's value to be evaluated in a constant expression context (which comes with footgunes, see an in-depth coverage of the issue there: https://gist.github.com/Som1Lse/5309b114accc086d24b842fd803ba9d2 https://gist.github.com/Som1Lse/5309b114accc086d24b842fd803b...)
dataflow 5y ago
> but how will you differentiate a call that you want to perform at compile-time vs at run-time? You could never do that to begin with. The compiler was always free to evaluate your function at compile time (and already did so in some cases). > e.g. if you want to run some unit tests to check the two algos Just make two separate functions and compare their outputs. That's what functions are for! So you don't put everything in one giant block of code. > i'd rather not introduce a template struct just to get a constexpr context, à la The standard library could do that for you instead of introducing a new keyword. In fact it practically already did so with std::integral_constant; they just need to update it for C++20 to avoid the redundancy. Or they could've introduced a [[pure]] attribute, or other less intrusive mechanisms. The keyword wasn't necessary for anything you mentioned. Also, as the sibling comment said, you might want to check out consteval.
- jcelerier 5y ago
  > You could never do that to begin with. The compiler was always free to evaluate your function at compile time (and already did so in some cases). no, that is false. the constant expression context is specified by the standard - the following will always hold if your compiler is not braindead : https://gcc.godbolt.org/z/zEEbWbhvr https://gcc.godbolt.org/z/zEEbWbhvr
  - dataflow 5y ago
    >> You could never do that to begin with. The compiler was always free to evaluate your function at compile time (and already did so in some cases). > no, that is false. Your sentence is false, not mine. See below. > the constant expression context is specified by the standard Expressions can be evaluated at compile-time outside of "constant expression contexts", under the as-if rule. That's one of the main things compilers do when optimizing code.
    - jcelerier 5y ago
      > Expressions can be evaluated at compile-time outside of "constant expression contexts", under the as-if rule. yes, but that does not make it a constexpr context, which is something explicitely specified by the standard. See my code example: the compiler is obviously able to evaluate foo() at compile time, yet it knows that the evaluation it does at compile time will yield a different result that the one it does in a constexpr context.