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

[Matthieu Monrocq]

Le 1 avril 2012 21:02, Howard Hinnant <hhinnant at apple.com> a écrit :

>
> 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
>
>
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.

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.

-- Matthieu.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120401/15c98140/attachment.html>