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

On Fri, Jan 11, 2013 at 11:32 AM, Sebastian Redl
<sebastian.redl at getdesigned.at> wrote:
>
> On 11.01.2013, at 20:08, Eli Bendersky wrote:
>
>>>> I suppose this tradeoff can be evaluated by looking at the
delta
>>>> between 4.5 and 4.6 which is actually supported by MSVC 2010
and Clang
>>>> 3.1
>>>
>>> Makes perfect sense to me.
>>>
>>> -Chris
>>
>> According to http://gcc.gnu.org/projects/cxx0x.html, these features
>> are available from 4.6 (language features only):
>>
>> - Null pointer constant
>
> This is the only one fully supported by VS 2010.
>
>> - Forward declarations for enums
>
> This is partially supported. I don't know the exact extent.
>
>> - Generalized constant expressions
>> - Unrestricted unions
>> - Range-based for
>> - Defining move special member functions
>> - Allowing move constructors to throw
>
> These are all unsupported.
>
> So the question is, is nullptr worth requiring 4.6.
>
> Sebastian
nullptr fixes a bug with 2010's implementation of std::pair.

std::pair<int*, int*> a = std::make_pair(0, 0);

That doesn't work in 2010 :( (It was actually a bug in the standard
draft at the time 2010 came out)

- Michael Spencer

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.

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.

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

"Matthieu M." <matthieu.monrocq at gmail.com> writes:
> Using the Apache Wiki [1] I summed up what can be used simultaneously
> by gcc, MSVC and clang.
Thanks, that's quite helpful. Just a clarification for the benefit of
those not familiarized with Visual Studio:
> gcc 4.7, MSVC 11 nov' 12, clang 3.1
> => main additions: initializer lists, variadic templates v1.0 [4].
"MSVC 11 nov' 12" is a technology preview not ready for use on
production environments and without a release date. It is good to see it
in the table just to know what Microsoft is working on, but otherwise
irrelevant.

On Sun, Jan 13, 2013 at 01:18:11PM +0000, Matthieu M.
wrote:
> Hello all,
> 
> Using the Apache Wiki [1] I summed up what can be used simultaneously by
gcc,
> MSVC and clang.
>
 ... 
> 
> gcc 4.5, MSVC 11, clang 3.1
> => main additions: atomic, lambda v1.1, r-value v2.1 [3], strongly typed
enum.
> 
 ...
> 
> [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.
IIRC, this refers to the problems with g++ 4.5 moving lvalues when the author
did not intend this to happen. Then r-value v3.0 (n3053) fixed that, requiring
explicit use of std::move() to move lvalues.

Karen
-- 
Karen Shaeffer
Neuralscape, Mountain View, CA 94040