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

[David Blaikie]

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.

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