On Apr 2, 2012, at 2:44 AM, Jonathan Sauer wrote:
> Hello,
>
>> [...]
>> That's a good argument, thanks. I guess I'm now favoring Richard's exact
>> proposal:
>>
>> #ifndef _LIBCPP_HAS_NO_CONSTEXPR
>> #define _LIBCPP_CONSTEXPR constexpr
>> #else
>> #define _LIBCPP_CONSTEXPR
>> #endif
>>
>> Then use
>>
>> _LIBCPP_CONSTEXPR const int n = 5;
>>
>> for variables, and
>>
>> struct S {
>> _LIBCPP_CONSTEXPR S();
>> _LIBCPP_CONSTEXPR int f() const;
>> };
>>
>> for functions.
>>
>> I like it better than Jonathan's, and my first _CONSTEXPR_1, _CONSTEXPR_0
>> because of the single macro that is either going to be constexpr or not.
>> The source code won't be as compact, but I find it more readable (though
>> just a little too verbose).
>>
>> Jonathan, I really appreciate you're work in <limits> and <random> and sorry
>> about thrashing you around on this issue. But I felt it important to hammer
>> this out before we get too invested in the wrong strategy, as we already are
>> with my ill-fated:
>
> 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.
Howard
_______________________________________________
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
