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

[Howard Hinnant]

On Apr 2, 2012, at 3:10 PM, Jonathan Sauer wrote:

> Hello,
> 
>>> 
>>> Oh, no problem: First of all adapting my patch took me about 10 minutes, and second of all I did it on a whim,
>>> so any unnecessary work done by me is my own fault :-)
>>> 
>>> I prepared a new patch using _LIBCPP_CONSTEXPR and have it attached. Please review and, if ok, commit.
>> 
>> Thanks.  Two problems:
>> 
>> 1.  Please include a patch to CREDITS.TXT
>> 
>> 2.  Please test /test/numerics/rand and test/language.support/support.limits with constexpr turned off (say in C++03 mode).  I'm getting many failures under rand.
> 
> support.limits tests successfully with C++03. I fixed the few missing "const" in <random>, but since
> some of the static constants depend on method calls (namely to min() and max()), they won't compile
> with C++03 at all.
> 
> It would be possible, of course, to conditionally define those constants to either use min() and max()
> or _Min and _Max, respectively:
> 
> #if _LIBCPP_HAS_NO_CONSTEXPR
>    static const result_type _Min = _Engine::_Min;
>    static const result_type _Max = _Engine::_Max;
> #else
>    static _LIBCPP_CONSTEXPR const result_type _Min = _Engine::min();
>    static _LIBCPP_CONSTEXPR const result_type _Max = _Engine::max();
> #endif
> 
> But this would depend on the non-standard members _Min and _Max. And it would complicate the source, too.
> 
> What do you think?

This looks like the way to go to me.  I count 3 places in <random> and 1 place in <algorithm> that need this treatment.  User-written engines will either have to -std=c++11, or provide the non-standard interface.  I don't see another way around this.

> I attached a modified patch for <limits> and CREDITS.TXT, since I guess they are okay
> in either case.

Looks great, thanks!  I especially appreciate you updating the synopsis.  Committed revision 153888.

> Jonathan
> <limits.diff>
> 
> P.S: Testing with C++03, the files language.support/support.start.term/quick_exit.pass.cpp and
> language.support/support.types/nullptr_t.pass.cpp fail to compile here:
> 
> quick_exit.pass.cpp:19:10: error: no member named 'at_quick_exit' in namespace 'std'
>    std::at_quick_exit(f);
>    ~~~~~^
> quick_exit.pass.cpp:20:5: error: use of undeclared identifier 'quick_exit'
>    quick_exit(0);
>    ^
> 2 errors generated.
> /Users/rynnsauer/LLVM/libcxx/test/language.support/support.start.term/quick_exit.pass.cpp failed to compile
> Compile line was: /Users/rynnsauer/LLVM/build/Release+Asserts/bin/clang++ -stdlib=libc++ quick_exit.pass.cpp

<nod>  I'm counting on this being provided by the C library eventually.

> 
> nullptr_t.pass.cpp:57:24: error: reinterpret_cast from 'std::__1::nullptr_t' to 'std::ptrdiff_t'
>      (aka 'long') is not allowed
>    std::ptrdiff_t i = reinterpret_cast<std::ptrdiff_t>(nullptr);
>                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 1 error generated.
> /Users/rynnsauer/LLVM/libcxx/test/language.support/support.types/nullptr_t.pass.cpp failed to compile
> Compile line was: /Users/rynnsauer/LLVM/build/Release+Asserts/bin/clang++ -stdlib=libc++ nullptr_t.pass.cpp

<nod> Known bug for C++03 nullptr emulation.  This one passes in -std=c++11.

Thanks,
Howard