[LLVMdev] Using C++'11 language features in LLVM itself

[Matthieu Monrocq]

On Sun, Jan 13, 2013 at 7:00 PM, David Blaikie <dblaikie at gmail.com> wrote:

> On Sun, Jan 13, 2013 at 9:57 AM, David Blaikie <dblaikie at gmail.com> wrote:
> > On Sun, Jan 13, 2013 at 5:18 AM, Matthieu M. <matthieu.monrocq at gmail.com>
> wrote:
> >> Hello all,
> >>
> >> Using the Apache Wiki [1] I summed up what can be used simultaneously
> by gcc,
> >> MSVC and clang.
> >>
> >> I mostly considered only the latest versions of the proposals where
> there were
> >> several, where not there is a link to a note at the bottom. Furthermore
> I did
> >> not scourge through 3 bug databases and I implicitly trusted the wiki
> page.
> >>
> >>
> >> I drew up a list of profiles, listing the base capabilities for the
> first and
> >> then what each of them adds to the previous one. The version of clang
> is the
> >> minimum possible adjusted so as not to limited what the gcc/MSVC
> combination
> >> provides.
> >>
> >>
> >> gcc 4.3, MSVC 10, clang 3.0
> >> => main benefits: decltype v1.0 [2], static_assert and built-in type
> traits.
> >>
> >> gcc 4.4, MSVC 10, clang 3.0
> >> => main additions: late specified return type.
> >>
> >> gcc 4.5, MSVC 10, clang 3.0
> >> => only addition (sorry Chris): local types as template arguments.
> >
> > FWIW - I'd hope to argue in favor of allowing lambdas even with our
> > base set at MSVC 10 (I believe that's already been stated as pretty
> > much non-negotiable in an immediate timeframe (even in the 3.4 release
> > window, I'd expect) - but it's useful to see where we are going
> > forward as well), just relying on the intersection of available
> > features across the compilers. The major inconvenience is no implicit
> > conversion to non-member function pointer for stateless lambdas, but
> > I'd hate to throw out lambdas entirely just because we can't use that.
> > (there are some other caveats/gotchas too, apparently, the MSVC
> > article is a little vague on the specifics - perhaps some of those
> > complications are so problematic as to be worth avoiding MSVC 10's
> > lambdas entirely, but I hope not)
>
> Similar comment on rvalue references too. It sounds like MSVC 10's
> r-value v2.0 just has a slight pessimism compared to v2.1. I doubt
> that's worth avoiding the whole feature for.
>
>
Good points David, I don't feel qualified to evaluate the differences
between those versions though... Perhaps Richard or Doug could comment here
?

-- Matthieu


> >> gcc 4.5, MSVC 11, clang 3.1
> >> => main additions: atomic, lambda v1.1, r-value v2.1 [3], strongly
> typed enum.
> >>
> >> gcc 4.6, MSVC 11, clang 3.1
> >> => main additions: forward enum, nullptr, range-based for.
> >>
> >> gcc 4.7, MSVC 11, clang 3.1
> >> => main additions: override/final, template aliases.
> >>
> >> gcc 4.7, MSVC 11 nov' 12, clang 3.1
> >> => main additions: initializer lists, variadic templates v1.0 [4].
> >>
> >>
> >> Even though the later profiles may not be of immediate interest, I
> included them
> >> for completeness and to maybe help shape up the C++11 inclusion road
> map.
> >>
> >> I hope this might prove helpful in the upcoming decision. I would
> advise people
> >> who want a closer look to check the Apache page summing up the compiler
> >> capabilities by themselves.
> >>
> >>
> >> -- Matthieu.
> >>
> >>
> >> PS: thanks to Stephen Kelly for showing me how to use gmane to barge in.
> >>
> >> [1]: http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport
> >>
> >> [2]: "decltype v1.0 (n2343)" is subsided by "decltype v1.1 (n3276)"
> which drops
> >> the completeness requirement of return types; unfortunately it seems no
> known
> >> version of gcc implements v1.1.
> >>
> >> [3]: "r-value v2.1 (n2844 + core issue 1138)" is subsided by "r-value
> v3.0
> >> (n3053)" but I could not understand the gist of the differences;
> furthermore it
> >> seems no known version of MSVC implements v3.0.
> >>
> >> [4]: a prior implementation of variadic templates (dubbed v0.9) was
> available as
> >> soon as gcc 4.4 (with issues regarding template template parameters
> matching),
> >> however MSVC never implemented it and jumped straight to v1.0 in the
> CTP release.
> >>
> >>
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130113/9a1b8b7d/attachment.html>