[cfe-commits] [Patch][Review] constexpr-ification of <limits> and random number generators

[Howard Hinnant]

On Apr 1, 2012, at 2:53 PM, Jonathan Sauer wrote:

> Hello,
> 
>>> the attached patch constexpr-ifies <limits> as specified in FDIS as well as removes the
>>> workarounds in libc++'s random number generators due to missing constexpr (the workarounds
>>> don't work when using a non-standard PRNG). The corresponding tests are modified as well.
>>> 
>>> Please review and, if ok, commit.
>>> 
>>> 
>>> With many thanks in advance,
>>> Jonathan
>> 
>> Thanks Jonathan.  I've been meaning to take care of this.  The current libc++ is a mess with respect to constexpr.
>> 
>> 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.
> 
> No, it indeed does not. As libc++ currently uses said hack in <__config>, I simply worked from there.
> I was not aware of the desired C++03 backwards compatibility. BTW, are new C++11 headers supposed to be
> backwards compatible, too?

Most of them yes (random, forward_list, unordered....  I gave up on <tuple>).  Variadics on other things is very poorly supported in C++03.

> 
>> [...]
>> 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:
>> 
>> #ifndef _LIBCPP_HAS_NO_CONSTEXPR
>> #define _CONSTEXPR_1 constexpr
>> #define _CONSTEXPR_0 constexpr
>> #else
>> #define _CONSTEXPR_1 const
>> #define _CONSTEXPR_0
>> #endif
>> 
>> (better macro names would be great!)
> 
> How about _CONSTEXPR_FUNC for a constexpr function/method and _CONSTEXPR_STATIC for a constexpr static
> member constant:
> 
> #ifndef _LIBCPP_HAS_NO_CONSTEXPR
> #define _CONSTEXPR_STATIC static constexpr
> #define _CONSTEXPR_FUNC constexpr
> #else
> #define _CONSTEXPR_STATIC static const
> #define _CONSTEXPR_FUNC
> #endif
> 
> I took the liberty of trying this out with <limits>; the patch is attached (I did not touch <random> this
> time).

After looking over Richard's suggestion I'm toying with:

#ifdef _LIBCPP_HAS_NO_CONSTEXPR
#define constexpr
#endif

Then use

constexpr const int n = 5;

for variables, and

struct S {
   constexpr S();
   constexpr int f() const;
   static constexpr const int bool = true;
};

for functions and constructors.

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?

Howard