C++11/14 Core Language Features in VS 2013 and the Nov 2013 CTP

C++11/14 Core Language Features in VS 2013 and the Nov 2013 CTP

Rate This
  • Comments 20

Although we've listed the C++11 Core Language features available in VS 2013 and the C++11/14 Core Language features available in the Nov 2013 CTP, I haven't published a table on VCBlog. (Previous tables: VS 2008 and VS 2010, VS 2012.) MSDN updated their table for VS 2013, but it doesn't cover the CTP.

 

So, for your convenience, here's a table. As I stressed in Core C++, Part 10, the CTP is an alpha build. You should expect its features to be available (and significantly improved) in the next major version of VS, barring catastrophe (like the features being voted out of the C++14 Working Paper). However, you should not expect these features to be released in an Update for VS 2013 RTM.

 

C++11 Core Language Features

VS 2013

Nov 2013 CTP

Rvalue references

Partial

Yes

ref-qualifiers

No

Yes

Non-static data member initializers

Yes

Yes

Variadic templates

Yes

Yes

Initializer lists

Yes

Yes

static_assert

Yes

Yes

auto

Yes

Yes

Trailing return types

Yes

Yes

Lambdas

Yes

Yes

decltype

Yes

Yes

Right angle brackets

Yes

Yes

Default template args for function templates

Yes

Yes

Expression SFINAE

No

No

Alias templates

Yes

Yes

Extern templates

Yes

Yes

nullptr

Yes

Yes

Strongly typed enums

Yes

Yes

Forward declared enums

Yes

Yes

Attributes

No

No

constexpr

No

Partial

Alignment

Partial

Yes

Delegating constructors

Yes

Yes

Inheriting constructors

No

Yes

Explicit conversion operators

Yes

Yes

char16_t and char32_t

No

No

Unicode string literals

No

No

Raw string literals

Yes

Yes

Universal character names in literals

No

No

User-defined literals

No

No

Standard-layout and trivial types

Yes

Yes

Defaulted and deleted functions

Partial

Yes

Extended friend declarations

Yes

Yes

Extended sizeof

No

Yes

Inline namespaces

No

No

Unrestricted unions

No

No

Local and unnamed types as template args

Yes

Yes

Range-based for-loop

Yes

Yes

override and final

Yes

Yes

Minimal GC support

Yes

Yes

noexcept

No

Partial

C++11 Core Language Features: Concurrency

VS 2013

Nov 2013 CTP

Reworded sequence points

N/A

N/A

Atomics

Yes

Yes

Strong compare and exchange

Yes

Yes

Bidirectional fences

Yes

Yes

Memory model

N/A

N/A

Data-dependency ordering

Yes

Yes

Data-dependency ordering: attributes

No

No

exception_ptr

Yes

Yes

quick_exit and at_quick_exit

No

No

Atomics in signal handlers

No

No

Thread-local storage

Partial

Partial

Magic statics

No

Yes

C++11 Core Language Features: C99

VS 2013

Nov 2013 CTP

__func__

Partial

Yes

C99 preprocessor

Partial

Partial

long long

Yes

Yes

Extended integer types

N/A

N/A

C++14 Core Language Features

VS 2013

Nov 2013 CTP

Tweaked wording for contextual conversions

No

No

Binary literals

No

No

auto and decltype(auto) return types

No

Yes

init-captures

No

No

Generic lambdas

No

Partial

Variable templates

No

No

Extended constexpr

No

No

NSDMIs for aggregates

No

No

Avoiding/fusing allocations

No

No

[[deprecated]] attributes

No

No

Sized deallocation

No

No

Digit separators

No

No

 

Notes for the "Partial" entries:

 

VS 2013 supported rvalue references, except for automatically generated move ctors/assigns. Similarly, VS 2013 supported defaulted and deleted functions, except for defaulted move ctors/assigns. This has been completed in the CTP.

 

The CTP supports C++11 constexpr, except for member functions. (Another limitation is that arrays aren't supported.) Also, it doesn't support C++14's extended constexpr rules.

 

I listed VS 2013's support for N2341 Alignment as "Partial" because that paper contained both Core Language and Standard Library features, and VS 2013's STL supported the latter. The CTP has completed this by adding alignof/alignas to the compiler.

 

The CTP supports noexcept's unconditional form. (Additionally, while noexcept's terminate() semantics have been implemented, they require library support, and the CTP was intentionally shipped without updated libraries.)

 

Thread-local storage is listed as "Partial" because VC has provided the non-Standard extension __declspec(thread) for many years. (Notably, C++11 thread_local supports non-PODs, but __declspec(thread) doesn't.)

 

__func__ was added in the CTP. I listed it as "Partial" for VS 2013, which provided the non-Standard extensions __FUNCDNAME__, __FUNCSIG__, and __FUNCTION__ (which continue to be provided in the CTP).

 

The C99 preprocessor rules are listed as "Partial" because VC has supported variadic macros for many years. (Note that the compiler team is aware of their preprocessor's long-standing conformance issues, and that overhauling this is on their list of work items.)

 

Finally, I've listed the CTP's support for C++14 generic lambdas as "Partial" because only stateless lambdas (beginning with []) and lambdas with explicit captures (e.g. [x, &y]) are supported. Implicit captures (e.g. [=] and [&]) are not yet supported for generic lambdas.

 

Stephan T. Lavavej

Senior Developer - Visual C++ Libraries

stl@microsoft.com

  • Will MSVC Support OpenMP 4.0?

  • @KHeresy: This CTP does not support OpenMP 4.0 (only version 2.0 is supported). At the moment we have no plans to add 4.0 support in the next release of Visual Studio.

  • This is great news! Keep up the hard work.

  • @STL, what is the difference between No and N/A in the conformance table in this blog post? Does it mean you are never going to make those with N/A available ever?

  • I am especially asking for C99's Extended Integer types.. Please confirm.

    I don't know how you guys feel about it, but I for one would literally celebrate the day VC support C99 and C11 standards ! :D

    Love C, love C++ love standard library !!

  • @Jack: The extended types feature doesn't add any new types, it adds conformance rules to those compilers that add new types beyond the standard types so in that case I assume N/A simply means that the compiler was unaffected by the change in the spec.

  • N/A means "Not Applicable", i.e. there is nothing for us to do. (These rows exist because I followed GCC's C++0x/11 tables back in 2010 and 2012.)

    Reworded Sequence Points is N/A because I am unaware of major differences between the C++03 "sequence point" wording and C++11's "sequenced before" wording for single-threaded code.

    Memory Model is N/A because I am unaware of any impact on compilers that already supported (non-Standard) multithreading. It is possible that C++11's memory model strictly bans some optimizations that compilers previously attempted to get away with, but I am not aware of any for VC, and such things would really have been bugs in the olden days too.

    Extended Integer Types is definitely N/A - it permits but does not require types longer than long long to exist. VC doesn't support such types, so there's nothing for us to do. (Stuff like __m128 is totally different.)

  • Why you don't have a plan to support "Unicode string literals"?

  • This is a status report, not a planning document. All of the features marked No or Partial are on the compiler team's list of stuff to implement.

  • I tested the constexpr roughly, it doesn't work?

    It seems that the current release only target for letting the code with this keyword be capable of being compiled and nothing more.

    If I haven't misunderstood about the constexpr(and plz point out and correct me if it does):

    1) Should this have been compiled?

    int a = 1;

    constexpr int n1 = 0;

    switch(a)

    {

    case n1:

       break;

    default:

    }

    2) Should this have been compiled?

    template < int arg > struct Tag1 {};

    template < typename _Ty, _Ty arg > struct Tag2 {};

    ...

    constexpr int n1 = 0;

    Tag1<n1> a1;

    Tag2<decltype(n1), n1> a2;

    3) Should this have been compiled?

    template < int arg > struct Tag1 {};

    template < typename _Ty, _Ty arg > struct Tag2 {};

    ...

    constexpr int fTest(void) { return(1); };

    ...

    switch(a)

    {

    case fTest():

       break;

    default:

    }

    ...

    int arr[fTest()] = {};

    ...

    Tag1<fTest()> a1;

    Tag2<decltype(fTest()), fTest()> a2;

    4) I'm not sure about this if it is legal, but i do realy hope so:

    constexpr char fTest(size_t index)

    { return(*("0123456789" + index)); };

    template < int a > Tag { enum nRes { result }; };

    template <> Tag< (4 + '0') > { enum nRes { result = 1 }; };

    ...

    int i = Tag<fTest(1)>::result;

    i = Tag<fTest(4)>::result;

  • Can you please clarify about the 'Rvalue references' supporting in VS2013? Why it has been marked as 'partial'? What exactly the CTP can do and it can't?

  • I tested the constexpr roughly, it doesn't work?

    It seems that the current release only target for letting the code with this keyword be capable of being compiled and nothing more.

    If I haven't misunderstood about the constexpr(and plz point out and correct me if it does):

    1) Should this have been compiled?

    int a = 1;

    constexpr const int n1 = 0;

    switch(a)

    {

    case n1:

      break;

    default:

    }

    2) Should this have been compiled?

    template < int arg > struct Tag1 {};

    template < typename _Ty, _Ty arg > struct Tag2 {};

    ...

    constexpr const int n1 = 0;

    Tag1<n1> a1;

    Tag2<decltype(n1), n1> a2;

    3) Should this have been compiled?

    template < int arg > struct Tag1 {};

    template < typename _Ty, _Ty arg > struct Tag2 {};

    ...

    constexpr const int fTest(void) { return(1); };

    ...

    switch(a)

    {

    case fTest():

      break;

    default:

    }

    ...

    int arr[fTest()] = {};

    ...

    Tag1<fTest()> a1;

    Tag2<decltype(fTest()), fTest()> a2;

    4) I'm not sure about this if it is legal, but i do realy hope so:

    constexpr const char fTest(const size_t index)

    { return(*("0123456789" + index)); };

    template < int a > Tag { enum nRes { result }; };

    template <> Tag< (4 + '0') > { enum nRes { result = 1 }; };

    ...

    int i = Tag<fTest(1)>::result;

    i = Tag<fTest(4)>::result;

  • Simon Dan> Can you please clarify about the 'Rvalue references' supporting in VS2013? Why it has been marked as 'partial'? What exactly the CTP can do and it can't?

    Read my post: "VS 2013 supported rvalue references, except for automatically generated move ctors/assigns. Similarly, VS 2013 supported defaulted and deleted functions, except for defaulted move ctors/assigns. This has been completed in the CTP."

    #1: Labels actually need to be followed by statements, but your "default:" isn't followed by a statement. This works for me (note that I'm using a newer build than the CTP, although this should work in the CTP too):

    C:\Temp>type meow.cpp

    #include <stdio.h>

    int main(int argc, char **) {

       constexpr int n = 4;

       switch (argc) {

       case n: puts("Meow!"); break;

       default: puts("Hiss!"); break;

       }

    }

    C:\Temp>cl /EHsc /nologo /W4 /MTd meow.cpp

    meow.cpp

    C:\Temp>meow a b c

    Meow!

    C:\Temp>meow w x y z

    Hiss!

    #2: Please note that _Leading_underscore_capital identifiers like _Ty are reserved exclusively for use by the compiler and Standard Library.

    Otherwise, your example compiles for me.

    #3: Again, you need a statement after "default:". Even a "break;" will do.

    After adding that, main(), and a definition for "a", I'm getting an Internal Compiler Error. I'll file a bug report, thanks!

    #4: You need to say "struct Tag" in your definitions. Otherwise, I suspect that this is not yet supported (you're accessing a string literal in a constexpr function - that's an array, and I know arrays aren't yet supported), but since you're triggering another ICE, I'll file a bug for this too. Thanks!

  • Filed as DevDiv#838079 and 838081 in our internal database. Your #3 was triggered by "fTest(void)". If you say "fTest()", it'll work.

  • @STL

    1) Thanks for your patient explanation. You may have just reminded me to notice about the comments below that list but still filled the full text for it. sorry for my bothering about it.

    2) As i've written at the section 4), I'm not sure if it's even legal for a valid constexpr function(I know everything included must be constants, but how about a static constant array? as the old std can tell an address among an array isn't). Until it's clarified it isn't certain to be a bug...

Page 1 of 2 (20 items) 12