3 ms·

`std::is_constant_evaluated` seems bananas to me - looks like a great way to end up with almost untraceable bugs, where the same function may or may not have bu

`std::is_constant_evaluated` seems bananas to me - looks like a great way to end up with almost untraceable bugs, where the same function may or may not have bugs depending on whether its evaluated at runtime or at compile time. Are there good ways to run unit tests against both const and non-const evaluations?! But then again, most new C++ features seem bananas to me, so I wouldn't read into it.

jcelerier 5y ago
How would you implement something like strlen so that you have the strict, hard guarantee that strlen("foo") is evaluated at compile-time?
- arcticbull 5y ago
  I'm saying a conditional branch that offers a different path of execution for a constant evaluation than for a runtime evaluation gives you a function that behaves differently in different contexts. In Rust, for instance, constant functions have to evaluate the same in both compile time and run time - you can't have a different code path depending on which. If you want that, make two functions. Trivially: constexpr bool is_even(int x) { if (std::is_constant_evaluated()) { return true; } else { return ((x % 2) == 0); } } How would you unit test this in a way that catches that only the constant evaluation is broken?
  - StephanTLavavej 5y ago
    Here’s what we do in MSVC’s STL: constexpr bool test_is_even() { assert(is_even(0)); assert(!is_even(1)); // … more test coverage return true; } int main() { test_is_even(); // runtime coverage static_assert(test_is_even()); // compile-time coverage This lets us run all test cases at both runtime and compiletime. (The static_assert performs constant evaluation, and if an assert within test_is_even would fail, it won’t be a constant expression.)
    - arcticbull 5y ago
      That's very cool, thank you for sharing!
  - jcelerier 5y ago
    But then you can't have generic functions that are efficient at run-time and work at compile-time ? This feature is added to c++ not for fun but because if you can't have a run-time branch that will do some AVX-fu, or invoke some runtime function from BLAS or LAPACK, the whole "evaluate at compile-time" thing is... Not useless but not far either

jcelerier 5y ago

How would you implement something like strlen so that you have the strict, hard guarantee that strlen("foo") is evaluated at compile-time?

arcticbull 5y ago
I'm saying a conditional branch that offers a different path of execution for a constant evaluation than for a runtime evaluation gives you a function that behaves differently in different contexts. In Rust, for instance, constant functions have to evaluate the same in both compile time and run time - you can't have a different code path depending on which. If you want that, make two functions. Trivially: constexpr bool is_even(int x) { if (std::is_constant_evaluated()) { return true; } else { return ((x % 2) == 0); } } How would you unit test this in a way that catches that only the constant evaluation is broken?
- StephanTLavavej 5y ago
  Here’s what we do in MSVC’s STL: constexpr bool test_is_even() { assert(is_even(0)); assert(!is_even(1)); // … more test coverage return true; } int main() { test_is_even(); // runtime coverage static_assert(test_is_even()); // compile-time coverage This lets us run all test cases at both runtime and compiletime. (The static_assert performs constant evaluation, and if an assert within test_is_even would fail, it won’t be a constant expression.)
  - arcticbull 5y ago
    That's very cool, thank you for sharing!
- jcelerier 5y ago
  But then you can't have generic functions that are efficient at run-time and work at compile-time ? This feature is added to c++ not for fun but because if you can't have a run-time branch that will do some AVX-fu, or invoke some runtime function from BLAS or LAPACK, the whole "evaluate at compile-time" thing is... Not useless but not far either