Re: constexpr question

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 9 June 2011 16:21, Andy Gibbs wrote:
>
> Thanks for your reply. ?I think that you're right that the compiler is
> probably working according to the logic you have suggested. ?Maybe it is a
> overlooked feature in the proposed new standard. ?I believe it isn't
> necessarily the case that you'd always want a constexpr function that also
> can be used as a normal (run-time) function since it may implement an
> algorithm suitable (i.e. possible) for compile-time use but unsuitable (i.e.
> inefficient) for run-time use. ?The idea, of course, would be to implement
> two different functions, one for use at compile-time, one for use at
> run-time. ?The problem for me is how to stop my users using the compile-time
> (i.e. inefficient) function at run-time. ?My experience is that
> documentation is often not enough! ?If it had worked, my wrapper idea would
> have been perfect: it would have stopped the compile-time function being
> used accidentally at run-time because the parameter wouldn't be constexpr
> and couldn't therefore be a template parameter; and the user would otherwise
> be able to decide whether to use the compile-time or the run-time function
> as he wished.

I don't think it's overlooked feature, I think the current behaviour
is by design.

[dcl.constexpr] p7 says it quite clearly:
A call to a constexpr function produces the same result as a call to
an equivalent non-constexpr function in all respects except that a
call to a constexpr function can appear in a constant expression.

N.B. _can_ appear in a constant expression. It must be a valid C++
function in all other respects, it is just possible to use in places
that didn't allow function calls previously.

A note on p1 says "Function parameters cannot be declared constexpr"
which precludes 'a' being a constant expression (it can only be
substituted by one during function invocation substitution, which only
occurs in the context of constant expressions.)