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

[Howard Hinnant]

On Apr 1, 2012, at 3:33 AM, 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.

Another thing that is wrong is that I have an ugly hack in <__config> that needs to be fixed:

#ifdef _LIBCPP_HAS_NO_CONSTEXPR
#define constexpr const
#endif

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!)

Like I said, this has been on my to-do list, and I guess now is the time.

> P.S: I noticed that class uniform_int_distribution is defined in <algorithm> instead of
> <random>, even though according to 26.5.2 it should be in <random>. Is there a special
> reason for this move?

Yes, it is to support:

template<class _RandomAccessIterator, class _UniformRandomNumberGenerator>
    void shuffle(_RandomAccessIterator __first, _RandomAccessIterator __last,
                 _UniformRandomNumberGenerator&& __g);

which is declared/defined in <algorithm>.

<random> includes <algorithm> as an implementation detail, so this refactoring should not cause a problem.  Getting the "right" (non-circular) header dependency for the std::lib is just loads of fun. ;-)

Howard