4 ms·

> a computation is not and cannot be constant Sure it can - but you know that - a compile time computation can be a run time constant. There’s loads of reasons

by dahart 2y ago

> a computation is not and cannot be constant Sure it can - but you know that - a compile time computation can be a run time constant. There’s loads of reasons to want constant values built out of compile-time computation. You haven’t had to write any high performance code? Start with something like constexpr float angle_threshold = 45.0f; constexpr float degToRad = M_PI / 180.0f; constexpr float x_threshold = cosf( angle \* degToRad ); The nice thing about having this be an expression is it’s semantic, and I can tune my angle in degrees, not have some raw number that isn’t adjustable. Maybe I need a small table of these, suddenly running a little code at compile time looks great. Doing it during compilation is a lot nicer than having a script dependency and having to write a build step for it. The bigger issue with constexpr specifically is that it doesn’t actually guarantee compile time evaluation…

nullc 2y ago
yet any remotely competent compiler would have turned degToRad to a constant regardless.
- biorach 2y ago
  That's a rather dickish way of completely missing the point
  - nullc 2y ago
    I apologize for offending, it certainly wasn't the intent. But I don't believe one can justify the existence of constexpr simply by pointing to code that absolutely any compiler would make into constants absent it. Perhaps in your example one could say that the value is that you really want the compilation to abort should changes happen to the code that make it impossible for the compiler to turn it into constants, since doing so is performance critical-- I think that would be a fair point.
    - dahart 2y ago
      Sounds like you’re close to justifying the existence of constexpr, that sounds similar to the summary of what it’s for. I wasn’t trying to justify the existence of constexpr, I was justifying the existence of compile time constant computation in response to what @38_14 said about there being no such thing as a computation that’s constant, which is, you probably agree, a bit silly. The top comment didn’t seem to be talking about constexpr specifically since the point was about computation and they said “constexpr and similar” which I assume includes const, consteval, as well as the general idea of baking the results of compute at compile time. HN isn’t really the right place to demand justifying the existence of constexpr, but its existence has been debated at length by people who know a lot more about C++ than me. If you want to read about why it exists, there are lots of good places like cppreference.com and isocpp.org and even stack overflow.
- dahart 2y ago
  degToRad wasn’t the point, the list of cosines being computed at compile time was the point… or something similar, or something different… use your imagination. I used cosf() because it’s clearly a function call doing compile time compute, and I suggested a list because it makes a more clear case for compile time compilation, and because that might start to get into the reasons one would want constexpr allocation. And yes of course a good compiler absolutely will turn things into constants if it can, regardless of how they’re declared, including without any special const* specifiers at all. That is not why either const or constexpr exist, right?

by dahart 2y ago

nullc 2y ago

yet any remotely competent compiler would have turned degToRad to a constant regardless.

biorach 2y ago
That's a rather dickish way of completely missing the point
- nullc 2y ago
  I apologize for offending, it certainly wasn't the intent. But I don't believe one can justify the existence of constexpr simply by pointing to code that absolutely any compiler would make into constants absent it. Perhaps in your example one could say that the value is that you really want the compilation to abort should changes happen to the code that make it impossible for the compiler to turn it into constants, since doing so is performance critical-- I think that would be a fair point.
  - dahart 2y ago
    Sounds like you’re close to justifying the existence of constexpr, that sounds similar to the summary of what it’s for. I wasn’t trying to justify the existence of constexpr, I was justifying the existence of compile time constant computation in response to what @38_14 said about there being no such thing as a computation that’s constant, which is, you probably agree, a bit silly. The top comment didn’t seem to be talking about constexpr specifically since the point was about computation and they said “constexpr and similar” which I assume includes const, consteval, as well as the general idea of baking the results of compute at compile time. HN isn’t really the right place to demand justifying the existence of constexpr, but its existence has been debated at length by people who know a lot more about C++ than me. If you want to read about why it exists, there are lots of good places like cppreference.com and isocpp.org and even stack overflow.
dahart 2y ago
degToRad wasn’t the point, the list of cosines being computed at compile time was the point… or something similar, or something different… use your imagination. I used cosf() because it’s clearly a function call doing compile time compute, and I suggested a list because it makes a more clear case for compile time compilation, and because that might start to get into the reasons one would want constexpr allocation. And yes of course a good compiler absolutely will turn things into constants if it can, regardless of how they’re declared, including without any special const* specifiers at all. That is not why either const or constexpr exist, right?