When is a constexpr function not constexpr?

[2kaud]

Consider

constexpr int fc(int i)
{
	return i * 3;
}

....
	fc(4);

	int c = 8;
	fc(c);

fc(4) should be evaluated at compile time because the argument to fc is known at compile time. However fc(c) will be evaluated at run-time.

What would be nice is if there is a way to produce a compiler warning when a function defined as constexpr is not able to be evaluated at compile-time but is evaluated at run-time. Is this possible somehow?

[TubularX]

I think that's a job for a static analysis tool rather than the compiler.

This simple case should be possible to detect as a performance warning, suggesting "constexpr int c = 8;".

I'm not aware of any tool that actually does that, but some tools are open source so you can contribute if you want. For example "cppcheck" where you can always create a suggestion in the ticket system if you don't have time to write the code yourself.

[superbonzo]

fc(4) should be evaluated at compile time because the argument to fc is known at compile time.

this is not correct, a constexpr function is a function that *can* ( not should/may ) be evaluated at compile time and it *must* be evaluated statically only if such evaluation is required to be so ( ie, in contexts such as array bounds, non type template parameters, etc …. )

indeed the full expression “fc(4);” has the same chances language wise of been optimized ( via static evaluation ) whether fc is constexpr or a simple inline function.

of course, if you need a function to be evaluated *only* statically, just use it in a context requiring static evaluation

constexpr int c = fc( /*…*/ ); // this is required to be evaluated at compile time

… the only sensible reason I can think of why one would want to know whether a constexpr function is evaluated statically or not is to use a different algo in the two cases ( compile time algos may not be not runtime efficient, see recursion ). Otherwise, it probably means your use of constexpr functions is not appropriate…

[TubularX]

"constexpr functions *will* be evaluated at compile time when all its arguments are constant expressions and the result is used in a constant expression as well."

http://stackoverflow.com/questions/1...t-compile-time

[2kaud]

why one would want to know whether a constexpr function is evaluated statically or not

Now that c++14 has relaxed what can be performed with a constexpr function we're looking to undertake as much calculation as possible at compile time rather than run time. Making functions OK for constexpr wasn't that difficult with the c++14 language changes but we don't know whether these constexpr functions are being evaluated at compile or run time. We've chasing down in the many hundreds of program files where these constexpr functions are used and hoping that the changes we make cause them to be compile time evaluated. The compiler knows when a constexpr function is not evaluated at compile time so having it produce a warning message would be very useful.

[superbonzo]

"constexpr functions *will* be evaluated at compile time when all its arguments are constant expressions and the result is used in a constant expression as well."

yes, and the “and” part is the point I was trying to make; in the OP example, the fc(4) call is NOT required to be statically evaluated

The compiler knows when a constexpr function is not evaluated at compile time so having it produce a warning message would be very useful.

the compiler also to some extent knows when a regular function can be evaluated statically ( actually, in a more general way than the constexpr function rules allow ), do you want warnings also in such ( undoubtly useful ) cases ?

again, if you want to make sure that some computation is performed statically for performance reasons, just call those functions in a context that effectively requires so ( you can always do that ).

[2kaud]

just call those functions in a context that effectively requires so ( you can always do that ).

When changing existing code, that is what we are trying to achieve!