[cfe-commits] r148374 - in /cfe/trunk: lib/AST/ExprConstant.cpp test/SemaCXX/constexpr-strlen.cpp

[Howard Hinnant]

On Jan 19, 2012, at 5:55 PM, Richard Smith wrote:

> On Thu, January 19, 2012 19:56, Howard Hinnant wrote:
>> On Jan 19, 2012, at 2:30 PM, Matthieu Monrocq wrote:
>>> Le 19 janvier 2012 17:52, Jonathan Sauer <jonathan.sauer at gmx.de> a écrit :
>>>>> Do you know if the same apply (I would guess so) to std::strlen ?
>>>>> 
>>>>> 
>>>>> It seems a pity that such a trivial function could not be constexpr as
>>>>> making it constexpr is actually dead simple. I wonder if it would be
>>>>> worth a Defect Report.
>>>>> 
>>>> This would seem very reasonable to me...
>>>> 
>>> 
>>> As well as a lot (all?) of the math functions in cmath. And clang's
>>> built-ins (__builtin_sin etc), too.
>>> 
>>> 
>>> What do you think?
>>> Jonathan
>>> 
>>> 
>>> I haven't followed the C11 proposal, is the "constexpr" idea addressed
>>> there or would it be a specific C++ issue ?
>>> 
>>> C++ imports a massive amount of C functions, and keeping their signature
>>> as-is will be a hindrance, I don't fancy the idea of recoding them all in
>>> pure C++ to allow such optimizations! It seems like at least the `std::`
>>> versions could be made `constexpr` when possible.
>>> 
>>> I am putting Howard in copy since this seems something libc++ would be
>>> interested in, and perhaps his C++ committee experience could help us here.
>>> 
>>> 
>>> -- Matthieu
>>> 
>> 
>> I have not come up to speed on constexpr.  However, I do know that if it is
>> the case that no conforming program could detect (or behave differently --
>> besides performance) if the constexpr is added to a C function, then it
>> should be ok.
> 
> It is not the case; whether an expression is a constant expression can be
> detected in a SFINAE context:
> 
> 
> template<typename T> T declval();
> 
> template<typename T, T V> struct Value {
>  constexpr static T value = value;
> };
> 
> template<typename F, F f,
>         typename ...A, A ...a,
>         int = (f(a...), 0)>
> constexpr bool isConstexpr(Value<F, f> fn, Value<A, a> ...args) { return true; }
> 
> template<typename ...T>
> constexpr bool isConstexpr(...) { return false; }
> 
> int f(int);
> constexpr int g(int n) { return n; }
> 
> #define VALUE(x) Value<decltype(x), x>()
> constexpr bool test1 = isConstexpr(VALUE(&f), VALUE(0));
> constexpr bool test2 = isConstexpr(VALUE(&g), VALUE(0));
> static_assert(!test1, "");
> static_assert(test2, "");

Like I said about not being up the learning curve on constexpr. ;-)

In this case, if the LWG wants to allow this, we'll need some Chapter 17 verbage to allow it.

I recommend someone more educated on constexpr than myself open an issue on this.  The directions for opening an LWG issue are here:

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#submit_issue

If anyone needs help on how to get an issue opened, I *am* an expert on that, so please let me know.  I can assure you that this issue will be taken seriously on the LWG.

Howard