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.)
