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

[Howard Hinnant]

On Jan 19, 2012, at 6:28 PM, Howard Hinnant wrote:

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

Never mind, the issue has already been opened:

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

Howard