<br><br><div class="gmail_quote">Le 1 avril 2012 21:02, 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="im"><br>
On Apr 1, 2012, at 2:53 PM, Jonathan Sauer wrote:<br>
<br>
> Hello,<br>
><br>
>>> the attached patch constexpr-ifies <limits> as specified in FDIS as well as removes the<br>
>>> workarounds in libc++'s random number generators due to missing constexpr (the workarounds<br>
>>> don't work when using a non-standard PRNG). The corresponding tests are modified as well.<br>
>>><br>
>>> Please review and, if ok, commit.<br>
>>><br>
>>><br>
>>> With many thanks in advance,<br>
>>> Jonathan<br>
>><br>
>> Thanks Jonathan.  I've been meaning to take care of this.  The current libc++ is a mess with respect to constexpr.<br>
>><br>
>> One of the things I want to do is to allow libc++ to emulate correct behavior even when it is compiled in C++03 mode.  And I don't believe this patch will do this.<br>
><br>
> No, it indeed does not. As libc++ currently uses said hack in <__config>, I simply worked from there.<br>
> I was not aware of the desired C++03 backwards compatibility. BTW, are new C++11 headers supposed to be<br>
> backwards compatible, too?<br>
<br>
</div>Most of them yes (random, forward_list, unordered....  I gave up on <tuple>).  Variadics on other things is very poorly supported in C++03.<br>
<div class="im"><br>
><br>
>> [...]<br>
>> This is just wrong, but taking it out is going to take a little more work.  I haven't nailed down exactly how we want to support both C++03 and C++11 mode, but I'm imagining something similar to the way we're handling noexcept:<br>

>><br>
>> #ifndef _LIBCPP_HAS_NO_CONSTEXPR<br>
>> #define _CONSTEXPR_1 constexpr<br>
>> #define _CONSTEXPR_0 constexpr<br>
>> #else<br>
>> #define _CONSTEXPR_1 const<br>
>> #define _CONSTEXPR_0<br>
>> #endif<br>
>><br>
>> (better macro names would be great!)<br>
><br>
> How about _CONSTEXPR_FUNC for a constexpr function/method and _CONSTEXPR_STATIC for a constexpr static<br>
> member constant:<br>
><br>
> #ifndef _LIBCPP_HAS_NO_CONSTEXPR<br>
> #define _CONSTEXPR_STATIC static constexpr<br>
> #define _CONSTEXPR_FUNC constexpr<br>
> #else<br>
> #define _CONSTEXPR_STATIC static const<br>
> #define _CONSTEXPR_FUNC<br>
> #endif<br>
><br>
> I took the liberty of trying this out with <limits>; the patch is attached (I did not touch <random> this<br>
> time).<br>
<br>
</div>After looking over Richard's suggestion I'm toying with:<br>
<br>
#ifdef _LIBCPP_HAS_NO_CONSTEXPR<br>
#define constexpr<br>
#endif<br>
<br>
Then use<br>
<br>
constexpr const int n = 5;<br>
<div class="im"><br>
for variables, and<br>
<br>
struct S {<br>
</div>   constexpr S();<br>
   constexpr int f() const;<br>
   static constexpr const int bool = true;<br>
};<br>
<br>
for functions and constructors.<br>
<br>
Every single time I #define a keyword I live to regret it.  But I'm getting tempted again.  Anyone see the downside on this one?<br>
<div class="HOEnZb"><div class="h5"><br>
Howard<br>
<br></div></div></blockquote><div><br>I do: it was not a keyword in C++03 so there might be code which actually used it as identifier... and your macro will not do well there.<br><br>I think it is better, if not so readable, to stick to identifiers reserved to the implementation (__constexpr ?), at least if it happens to collide with user code, it's the user code that needs to be fixed.<br>
<br>-- Matthieu. <br></div></div>