<br><br><div class="gmail_quote">Le 20 janvier 2012 00:35, Howard Hinnant <span dir="ltr"><<a href="mailto:hhinnant@apple.com">hhinnant@apple.com</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Jan 19, 2012, at 6:28 PM, Howard Hinnant wrote:<br>
<br>
> On Jan 19, 2012, at 5:55 PM, Richard Smith wrote:<br>
><br>
>> On Thu, January 19, 2012 19:56, Howard Hinnant wrote:<br>
>>> On Jan 19, 2012, at 2:30 PM, Matthieu Monrocq wrote:<br>
>>>> Le 19 janvier 2012 17:52, Jonathan Sauer <<a href="mailto:jonathan.sauer@gmx.de">jonathan.sauer@gmx.de</a>> a écrit :<br>
>>>>>> Do you know if the same apply (I would guess so) to std::strlen ?<br>
>>>>>><br>
>>>>>><br>
>>>>>> It seems a pity that such a trivial function could not be constexpr as<br>
>>>>>> making it constexpr is actually dead simple. I wonder if it would be<br>
>>>>>> worth a Defect Report.<br>
>>>>>><br>
>>>>> This would seem very reasonable to me...<br>
>>>>><br>
>>>><br>
>>>> As well as a lot (all?) of the math functions in cmath. And clang's<br>
>>>> built-ins (__builtin_sin etc), too.<br>
>>>><br>
>>>><br>
>>>> What do you think?<br>
>>>> Jonathan<br>
>>>><br>
>>>><br>
>>>> I haven't followed the C11 proposal, is the "constexpr" idea addressed<br>
>>>> there or would it be a specific C++ issue ?<br>
>>>><br>
>>>> C++ imports a massive amount of C functions, and keeping their signature<br>
>>>> as-is will be a hindrance, I don't fancy the idea of recoding them all in<br>
>>>> pure C++ to allow such optimizations! It seems like at least the `std::`<br>
>>>> versions could be made `constexpr` when possible.<br>
>>>><br>
>>>> I am putting Howard in copy since this seems something libc++ would be<br>
>>>> interested in, and perhaps his C++ committee experience could help us here.<br>
>>>><br>
>>>><br>
>>>> -- Matthieu<br>
>>>><br>
>>><br>
>>> I have not come up to speed on constexpr.  However, I do know that if it is<br>
>>> the case that no conforming program could detect (or behave differently --<br>
>>> besides performance) if the constexpr is added to a C function, then it<br>
>>> should be ok.<br>
>><br>
>> It is not the case; whether an expression is a constant expression can be<br>
>> detected in a SFINAE context:<br>
>><br>
>><br>
>> template<typename T> T declval();<br>
>><br>
>> template<typename T, T V> struct Value {<br>
>> constexpr static T value = value;<br>
>> };<br>
>><br>
>> template<typename F, F f,<br>
>>        typename ...A, A ...a,<br>
>>        int = (f(a...), 0)><br>
>> constexpr bool isConstexpr(Value<F, f> fn, Value<A, a> ...args) { return true; }<br>
>><br>
>> template<typename ...T><br>
>> constexpr bool isConstexpr(...) { return false; }<br>
>><br>
>> int f(int);<br>
>> constexpr int g(int n) { return n; }<br>
>><br>
>> #define VALUE(x) Value<decltype(x), x>()<br>
>> constexpr bool test1 = isConstexpr(VALUE(&f), VALUE(0));<br>
>> constexpr bool test2 = isConstexpr(VALUE(&g), VALUE(0));<br>
>> static_assert(!test1, "");<br>
>> static_assert(test2, "");<br>
><br>
> Like I said about not being up the learning curve on constexpr. ;-)<br>
><br>
> In this case, if the LWG wants to allow this, we'll need some Chapter 17 verbage to allow it.<br>
><br>
> I recommend someone more educated on constexpr than myself open an issue on this.  The directions for opening an LWG issue are here:<br>
><br>
> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#submit_issue" target="_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#submit_issue</a><br>
><br>
> 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.<br>
<br>
</div></div>Never mind, the issue has already been opened:<br>
<br>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2013" target="_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2013</a><br>
<span class="HOEnZb"><font color="#888888"><br>
Howard<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br></div></div></blockquote><div>Thanks Howard for the reference.<br><br>I would have gone for a slightly different proposal (giving an exhaustive list of the C functions that should be so tagged) as the current proposal seems to create some non-portable situations (unless you wrap all such functions in functions of your own and resort to the SFINAE trick exposed by Richard).<br>
<br>I am also a bit sad that the last activity on this issue is recorded as being nearly a year ago. Is there a way to bump issues ?<br><br>-- Matthieu <br></div></div>