4 ms·

> Not really. The whole point of constexpr is to state that an expression is constant, thus the value returned by the function is computed at compile time. Tha

> Not really. The whole point of constexpr is to state that an expression is constant, thus the value returned by the function is computed at compile time. That's not even one point of constexpr, let alone the whole point. Putting constexpr in front of a function declaration does absolutely nothing to the codegen. See for yourself: https://gcc.godbolt.org/z/34h6Tanzn https://gcc.godbolt.org/z/34h6Tanzn Notice that both h() and f() are called despite being constexpr. > To me it seems thay annotating a function with constexpr is the clearest and most straight-forward way to go about expressing constant expressions. Again, it doesn't do what you think (see above). It does absolutely nothing to a function. > To each his own, but if the whole point is to represent constant expressions then the constexpr keyword seems to be straight-forward. This isn't an opinion thing. The consteval literally does what you're imagining constexpr does. Just replace constexpr with consteval in the code above. (I could probably argue that one has little use too, but that's not what I'm arguing here.)

thezilch 5y ago
What? https://gcc.godbolt.org/z/EzrWW9ss5 https://gcc.godbolt.org/z/EzrWW9ss5
- deleted 5y ago
  [deleted]
- dataflow 5y ago
  You're seeing the compiler opportunistically make an optimization by taking constexpr as an extra inlining hint. I showed you it's not something you can rely on in my example. You have to realize constexpr only talks about what is allowed to happen, not what is guaranteed to happen. You want consteval for that.
  - thezilch 5y ago
    Of course I want consteval, if a later C++ is available to me, but that doesn't excuse you writing constexpr does absolutely nothing, when it clearly does. It's no surprise your example doesn't fold calls without `-O3` or that one could produce a `constexpr` that doesn't fold to a constant (go ahead and try though :>). But consteval function is also not a literal replacement constexpr. For example, you can't take a pointer to the former. There's a reason they co-exist and are not useless.
    - dataflow 5y ago
      > Of course I want consteval, if a later C++ is available to me, but that doesn't excuse you writing constexpr does absolutely nothing, when it clearly does. consteval wasn't intended to be excusing anything. I was just letting you know you're misunderstanding what constexpr does, and that what you're thinking it's supposed to do is in fact consteval's job. You seem very confused about language specifications. That GCC and Clang happen to interpret constexpr as an extra "please inline" hint under -O3 is not evidence of constexpr "doing" something, and certainly not justification for including it in the language standard. That's like saying HN's orange color is "doing something" just because you really like to go eat an orange every time you see it. I suspect you will have a hard time finding any evidence that constexpr was ever intended to be a "this is technically optional but please really, really try to inline this" hint of sorts to the compiler by the committee. > But consteval function is also not a literal replacement constexpr. I didn't say it was. > For example, you can't take a pointer to the former. "Therefore constexpr is useful" does not follow from this. > There's a reason they co-exist and are not useless. There's a mediocre reason for consteval, and a bad reason for constexpr. The former is probably unnecessary IMO though still of marginal utility, and in any case I can concede there's a debate that could be had there. The latter would be practically useless if the language cared to just make it the implicit default. It's really only solving a problem it created. If you're using constexpr as an "optional but highly recommended inline" hint like you're showing me in your examples, you're doing the equivalent of pulling up HN's orange color so it coaxes you (or someone else) to go eat an orange. You are certainly welcome do that (hopefully it's a free country where you live) and I'm not stopping you per se, but it's missing both the letter and the spirit of the keyword(/color) by a colossal margin.

thezilch 5y ago

What? https://gcc.godbolt.org/z/EzrWW9ss5 https://gcc.godbolt.org/z/EzrWW9ss5

deleted 5y ago
[deleted]
dataflow 5y ago
You're seeing the compiler opportunistically make an optimization by taking constexpr as an extra inlining hint. I showed you it's not something you can rely on in my example. You have to realize constexpr only talks about what is allowed to happen, not what is guaranteed to happen. You want consteval for that.
- thezilch 5y ago
  Of course I want consteval, if a later C++ is available to me, but that doesn't excuse you writing constexpr does absolutely nothing, when it clearly does. It's no surprise your example doesn't fold calls without `-O3` or that one could produce a `constexpr` that doesn't fold to a constant (go ahead and try though :>). But consteval function is also not a literal replacement constexpr. For example, you can't take a pointer to the former. There's a reason they co-exist and are not useless.
  - dataflow 5y ago
    > Of course I want consteval, if a later C++ is available to me, but that doesn't excuse you writing constexpr does absolutely nothing, when it clearly does. consteval wasn't intended to be excusing anything. I was just letting you know you're misunderstanding what constexpr does, and that what you're thinking it's supposed to do is in fact consteval's job. You seem very confused about language specifications. That GCC and Clang happen to interpret constexpr as an extra "please inline" hint under -O3 is not evidence of constexpr "doing" something, and certainly not justification for including it in the language standard. That's like saying HN's orange color is "doing something" just because you really like to go eat an orange every time you see it. I suspect you will have a hard time finding any evidence that constexpr was ever intended to be a "this is technically optional but please really, really try to inline this" hint of sorts to the compiler by the committee. > But consteval function is also not a literal replacement constexpr. I didn't say it was. > For example, you can't take a pointer to the former. "Therefore constexpr is useful" does not follow from this. > There's a reason they co-exist and are not useless. There's a mediocre reason for consteval, and a bad reason for constexpr. The former is probably unnecessary IMO though still of marginal utility, and in any case I can concede there's a debate that could be had there. The latter would be practically useless if the language cared to just make it the implicit default. It's really only solving a problem it created. If you're using constexpr as an "optional but highly recommended inline" hint like you're showing me in your examples, you're doing the equivalent of pulling up HN's orange color so it coaxes you (or someone else) to go eat an orange. You are certainly welcome do that (hopefully it's a free country where you live) and I'm not stopping you per se, but it's missing both the letter and the spirit of the keyword(/color) by a colossal margin.