[cfe-commits] r148374 - in /cfe/trunk: lib/AST/ExprConstant.cpp test/SemaCXX/constexpr-strlen.cpp
Howard Hinnant
hhinnant at apple.com
Thu Jan 19 15:28:01 PST 2012
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
More information about the cfe-commits
mailing list