I don't get this. Why? Doesn't making a variable constexpr ensure it is a compile time value, or it will fail to compile?
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.
Why couldn't a variable without constexpr be evaluated at compile-time? Nobody ever explains this.
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.
> 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.
Meaning its entire purpose is to just be an easier version of a compile-time unit-test like static_assert(f(1) == 2)?
So you're saying functions that have side-effects like I/O can actually perform those operations at compile-time if marked with constexpr?
'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.
"... 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."
> [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
https://stackoverflow.com/questions/38879475/why-cant-conste...
Quoting Ben Voigt: "What constexpr does is provide guarantees on what data-flow analysis a compliant compiler is required to do to detect1 compile-time-computable expressions, and also allow the programmer to express that intent so that they get a diagnostic if they accidentally do something that cannot be precomputed."
inline means you CAN define a function in multiple translation units without violating ODR
no guarantees in the other direction
namespace detail {
template<class T, T val>
constexpr T eval() { return val; }
};
#define FORCE_COMPILE_TIME(x) detail::eval<decltype(x), x>()BTW, you can also enforce compile time evaluation like this:
enum { aux1 = X };
use(aux1);
enum aux1 = X;Here's a better idea, if you really need a compile time value in your program you calculate it yourself (or just run it at program startup and cache the value).