llvm dev - Jan 2013 - [LLVMdev] Using C++'11 language features in LLVM itself

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>

> Good points David, I don't feel qualified to evaluate the differences
> between those versions though... Perhaps Richard or Doug could comment
here?
Unless I'm misreading the buildbots, we don't actually have anything
trying to build with MSVC. Have we considered how we're going to
enforce these rather subtle distinctions?

Tim.

On Sun, Jan 13, 2013 at 10:26 AM, Tim Northover <t.p.northover at
gmail.com> wrote:
>> Good points David, I don't feel qualified to evaluate the
differences
>> between those versions though... Perhaps Richard or Doug could comment
here?
>
> Unless I'm misreading the buildbots, we don't actually have
anything
> trying to build with MSVC. Have we considered how we're going to
> enforce these rather subtle distinctions?
The buildbots on lab.llvm.org don't cover Windows, but Takumi
maintains Windows buildbots & fairly diligently (autoreporting to IRC,
plus manual follow up on review threads, etc) maintains them. Some
other developers (such as Michael Spencer) work on Windows on a
regular basis, so they'll essentially come screaming if it breaks ;)