33 ms·

> Doesn't making a variable constexpr ensure it is a compile time value It ensures that the variable could be evaluated at compile time, where "could be evalua

> Doesn't making a variable constexpr ensure it is a compile time value It ensures that the variable could be evaluated at compile time, where "could be evaluated at compile time" means "conforms to the rules set forth in the C++ standard". Whether or not it is computed at compile time is dependent on the compiler.

mehrdadn 9y ago
> It ensures that the variable could be evaluated at compile time Why couldn't a variable without constexpr be evaluated at compile-time? Nobody ever explains this.
- mikepurvis 9y ago
  There's precedent in C++ for keywords that give the compiler hints it doesn't necessarily promise to act on: inline.
  - mehrdadn 9y ago
    Happy to be corrected (EDIT: indeed, I stand corrected! see replies below), but I don't think the C++ spec says anything about 'inline' encouraging the compiler to inline the compiled code? 'auto' would've been an example, but that also got removed, because they realized it was useless. I don't get how constexpr is any different.
    - mikepurvis 9y ago
      I don't know my way around the spec, but Wikipedia is pretty unequivocal: "... it serves as a compiler directive that suggests (but does not require) that the compiler substitute the body of the function inline by performing inline expansion, i.e. by inserting the function code at the address of each function call, thereby saving the overhead of a function call." https://en.wikipedia.org/wiki/Inline_function https://en.wikipedia.org/wiki/Inline_function
      - mehrdadn 9y ago
        Thanks for this! I was very skeptical, but you made me look through every single mention of the word 'inline' in the spec, and you are indeed correct. :) Here is the relevant quote: > [7.1.2] [dcl.fct.spec] A function declaration with an inline specifier declares an inline function. The inline specifier indicates to the implementation that inline substitution of the function body at the point of call is to be preferred to the usual function call mechanism. An implementation is not required to perform this inline substitution at the point of call; however, even if this inline substitution is omitted, the other rules for inline functions defined by shall still be respected
  - mwkaufma 9y ago
    Shameless pedant kneejerk: 'inline' has semantics in additional to the optimization-hint. e.g. inlined functions won't trigger multiple-definition link-errors, even if they're left as ordinary functions in the executable.
- gpderetta 9y ago
  The option was discussed during standardization. It is expected that some corners of the language will never be available at compile time, for example I/O. So you need a keyword to declare a function to be callable a compile time, otherwise its constexpressness would depend on its implementation details and wouldn't be possible to check it in isolation. It might not be a great reason (some code becomes a keyword soup with all the pointless boilerplate, we really need a DWIM[1] keyword). [1] Declare With Implicit Meaning of course.
  - mehrdadn 9y ago
    > It is expected that some corners of the language will never be available at compile time, for example I/O. So you're saying functions that have side-effects like I/O can actually perform those operations at compile-time if marked with constexpr?
    - Joky 9y ago
      No: the purpose of constexpr is that the compiler would issue an error if a constexpr function contains such side-effects.
      - mehrdadn 9y ago
        No? Wouldn't it do that with a static_assert invoking the function too?
        Joky 9y ago
        No sure I get the question: static_assert can only invoke constexpr functions, and constexpr functions can only call themselves other constexpr functions. Since IO functions are not constexpr, you can't call them there.
  - mehrdadn 9y ago
    (EDIT to my last comment since I can't actually edit it -- I'm not sure if I misinterpreted your comment earlier or if you updated yours, but this is my updated reply.) > It is expected that some corners of the language will never be available at compile time, for example I/O. So you need a keyword to declare a function to be callable a compile time, otherwise its constexpressness would depend on its implementation details and wouldn't be possible to check it in isolation. Don't compilers already require the implementation of a function to be there in order to evaluate the code at compile-time? And don't they already have to verify that it can indeed be called at compile-time? I don't really get what the constexpr flag helps the compiler. It could just assume everything is constexpr implicitly unless proven otherwise.

mehrdadn 9y ago

> It ensures that the variable could be evaluated at compile time Why couldn't a variable without constexpr be evaluated at compile-time? Nobody ever explains this.

mikepurvis 9y ago
There's precedent in C++ for keywords that give the compiler hints it doesn't necessarily promise to act on: inline.
- mehrdadn 9y ago
  Happy to be corrected (EDIT: indeed, I stand corrected! see replies below), but I don't think the C++ spec says anything about 'inline' encouraging the compiler to inline the compiled code? 'auto' would've been an example, but that also got removed, because they realized it was useless. I don't get how constexpr is any different.
  - mikepurvis 9y ago
    I don't know my way around the spec, but Wikipedia is pretty unequivocal: "... it serves as a compiler directive that suggests (but does not require) that the compiler substitute the body of the function inline by performing inline expansion, i.e. by inserting the function code at the address of each function call, thereby saving the overhead of a function call." https://en.wikipedia.org/wiki/Inline_function https://en.wikipedia.org/wiki/Inline_function
    - mehrdadn 9y ago
      Thanks for this! I was very skeptical, but you made me look through every single mention of the word 'inline' in the spec, and you are indeed correct. :) Here is the relevant quote: > [7.1.2] [dcl.fct.spec] A function declaration with an inline specifier declares an inline function. The inline specifier indicates to the implementation that inline substitution of the function body at the point of call is to be preferred to the usual function call mechanism. An implementation is not required to perform this inline substitution at the point of call; however, even if this inline substitution is omitted, the other rules for inline functions defined by shall still be respected
- mwkaufma 9y ago
  Shameless pedant kneejerk: 'inline' has semantics in additional to the optimization-hint. e.g. inlined functions won't trigger multiple-definition link-errors, even if they're left as ordinary functions in the executable.
gpderetta 9y ago
The option was discussed during standardization. It is expected that some corners of the language will never be available at compile time, for example I/O. So you need a keyword to declare a function to be callable a compile time, otherwise its constexpressness would depend on its implementation details and wouldn't be possible to check it in isolation. It might not be a great reason (some code becomes a keyword soup with all the pointless boilerplate, we really need a DWIM[1] keyword). [1] Declare With Implicit Meaning of course.
- mehrdadn 9y ago
  > It is expected that some corners of the language will never be available at compile time, for example I/O. So you're saying functions that have side-effects like I/O can actually perform those operations at compile-time if marked with constexpr?
  - Joky 9y ago
    No: the purpose of constexpr is that the compiler would issue an error if a constexpr function contains such side-effects.
    - mehrdadn 9y ago
      No? Wouldn't it do that with a static_assert invoking the function too?
      - Joky 9y ago
        No sure I get the question: static_assert can only invoke constexpr functions, and constexpr functions can only call themselves other constexpr functions. Since IO functions are not constexpr, you can't call them there.
- mehrdadn 9y ago
  (EDIT to my last comment since I can't actually edit it -- I'm not sure if I misinterpreted your comment earlier or if you updated yours, but this is my updated reply.) > It is expected that some corners of the language will never be available at compile time, for example I/O. So you need a keyword to declare a function to be callable a compile time, otherwise its constexpressness would depend on its implementation details and wouldn't be possible to check it in isolation. Don't compilers already require the implementation of a function to be there in order to evaluate the code at compile-time? And don't they already have to verify that it can indeed be called at compile-time? I don't really get what the constexpr flag helps the compiler. It could just assume everything is constexpr implicitly unless proven otherwise.