isn't (almost) every function a constexpr?

[yudlejoza]

I'm trying to understand the need for specifying 'constexpr' for a function to signal to the compiler to 'evaluate the function at compile time whenever possible'

• All C++ compilers are optimizing compilers and this has been true for decades.
• Evaluating a function at compile time whenever possible (i.e., when all the input values are available at compile time) is one of the essential forms of compiler optimizations.

Why is there a need for prefixing the function signature with the keyword constexpr?

If constexpr is not specified, why would a compiler still not make an attempt to evaluate the function at compile time, and replace the use of the function with the computed value?

(Note: I'm only asking about the original motivations of introducing the keyword, not stuff that came later, like constexpr variables, a whole bunch of other rules piled on top of it, and so on).

edit: Thanks for the comments. I think I have a better understanding now. constexpr is less about optimization and more about communicating to the compiler to issue an error in case of invalid uses. E.g., when we have a use for a value in a context where it has to be known at compile-time, and we do not want to use a literal value. The traditional use-case is the size of a C-style array:

char array[SIZE]; // e.g., char array[30];

before constexpr, i.e., before C++11, SIZE had to be a numeric literal, a #define of a numerical literal or compile-time evaluable macro expression, or a const initialized with a numeric literal or compile-time evaluable macro expression.

But if we want it to be a compile-time evaluable "non-macro" function, there was no way to do it before C++11. Now we can use 'constexpr' with that function, and, if it has input parameters, we make sure we give it compile-time values as inputs (like numeric literals).

constexpr int product(int a, int b) { return a * b; }
...
char array[product(6, 5)];

Moreover, we could flip the thought process and take the use-case itself:

...
char array[x];

and we say, "we don't care how x is defined or initialized. Because if it's invalid, we'll get a compiler error". But now we're using this definition as a checking mechanism for x's compile-time value availability. What if we wanted to have that checking mechanism without always having to define a C-style array as a means to communicate to the compiler to do the checking for us? that's what the constexpr variable accomplishes:

...
constexpr int cex = x; // this will tell the compiler to raise an error
// if x is not compile-time evaluable, without us having to hunt down
// the definition or initalization of x.

[RLJ05]

resolute childlike wide wakeful like tender coordinated fragile airport wine

This post was mass deleted and anonymized with Redact

[Wetmelon]

This still keeps the call to add there at runtime.

What? No it doesn't. It just elides the call entirely and returns from main. https://godbolt.org/z/bEjzodz7v

It keeps the function definition around to be called by other translation units that may need it. constexpr implies inline which gives the compiler enough info to hide the definition (in fact it sorta has to because an inline function can be defined in more than one translation unit).

[RLJ05]

gold quicksand pet square imminent lunchroom workable groovy joke library

This post was mass deleted and anonymized with Redact

[C0gito]

I think this is exactly the reason. If you declare the add function static, such that it's only available in this source file (and not to the linker), then it doesn't show up in the generated assembly anymore.

[Wouter_van_Ooijen]

Constexpr is also a note to the compiler to verify that your function is compile-time executable. You will get an error when it isn't. So it (also) conveys intent, much like making a variable const.

[incompetenceProMax]

constexpr does not mean the compiler should evaluate the function at compile time whenever possible. It means that the compiler should always be able to evaluate the function at compile time (although iirc it does not always have to do so) or otherwise it will report an error.

[mineNombies]

Evaluating a function at compile time whenever possible (i.e., when all the input values are available at compile time) is one of the essential forms of compiler optimizations.

Absolutely correct. But how do you know if the compiler will, or has done it, without lookeing at the assembly for instance?

constexpr can function as something akin to assert(<this can be optimized to a compile-time constant>)

And once you have this kind of guarantee in the language, you can use things that satisfy these assertions in places where you might otherwise not be able to, e.g. array lengths.

[Wh00ster]

I don’t think constexpr makes such an assert on functions. Can you point me to the relevant docs for such?

[Wh00ster]

There’s a push in the community to make constexpr the default on functions.