Visual C++ vNext features from C++11

 

 

The final branding for the new version hasn’t been announced yet; for now, I’m supposed to say "Visual C++ in Visual Studio 11 Developer Preview". its _MSC_VER macro is 1700.  (That macro is of interest to people who want to target different major versions of VC and emit different code for them.)  I say VC10 and VC11 because they’re nice and simple – the 11 in VC11 does not refer to a year.  (VS 2010 == VC10 was a confusing coincidence.)

If you read C++0x Core Language Features In VC10: The Table last year, the following table will look familiar to you.  This time, I started with GCC’s table again, but I reorganized it more extensively for increased accuracy and clarity (as many features went through significant revisions):

C++11 Core Language Features

VC10

VC11

Rvalue references v0.1, v1.0, v2.0, v2.1, v3.0

v2.0

v2.1*

ref-qualifiers

No

No

Non-static data member initializers

No

No

Variadic templates v0.9, v1.0

No

No

Initializer lists

No

No

static_assert

Yes

Yes

auto v0.9, v1.0

v1.0

v1.0

Trailing return types

Yes

Yes

Lambdas v0.9, v1.0, v1.1

v1.0

v1.1

decltype v1.0, v1.1

v1.0

v1.1**

Right angle brackets

Yes

Yes

Default template arguments for function templates

No

No

Expression SFINAE

No

No

Alias templates

No

No

Extern templates

Yes

Yes

nullptr

Yes

Yes

Strongly typed enums

Partial

Yes

Forward declared enums

No

Yes

Attributes

No

No

constexpr

No

No

Alignment

TR1

Partial

Delegating constructors

No

No

Inheriting constructors

No

No

Explicit conversion operators

No

No

char16_t and char32_t

No

No

Unicode string literals

No

No

Raw string literals

No

No

Universal character names in literals

No

No

User-defined literals

No

No

Standard-layout and trivial types

No

Yes

Defaulted and deleted functions

No

No

Extended friend declarations

Yes

Yes

Extended sizeof

No

No

Inline namespaces

No

No

Unrestricted unions

No

No

Local and unnamed types as template arguments

Yes

Yes

Range-based for-loop

No

No

override and final v0.8, v0.9, v1.0

Partial

Partial

Minimal GC support

Yes

Yes

noexcept

No

No

C++11 Core Language Features: Concurrency

VC10

VC11

Reworded sequence points

N/A

N/A

Atomics

No

Yes

Strong compare and exchange

No

Yes

Bidirectional fences

No

Yes

Memory model

N/A

N/A

Data-dependency ordering

No

Yes

Data-dependency ordering: function annotation

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

No

C++11 Core Language Features: C99

VC10

VC11

__func__

Partial

Partial

C99 preprocessor

Partial

Partial

long long

Yes

Yes

Extended integer types

N/A

N/A

Here’s a quick guide to this table, but note that I can’t explain everything from scratch without writing a whole book, so this assumes moderate familiarity with what’s in C++11:

Rvalue references: N1610 "Clarification of Initialization of Class Objects by rvalues" was an early attempt to enable move semantics without rvalue references.  I’m calling it "rvalue references v0.1", as it’s of historical interest only.  It was superseded by rvalue references v1.0, the original wording.  Rvalue references v2.0, which is what we shipped in VC10 RTM/SP1, prohibits rvalue references from binding to lvalues, fixing a major safety problem.  Rvalue references v2.1 refines this rule.  Consider vector<string>::push_back(), which has the overloadspush_back(const string&) and push_back(string&&), and the call v.push_back("meow").  The expression "meow" is a string literal, and it is an lvalue.  (All other literals like 1729 are rvalues, but string literals are special because they’re arrays.)  The rvalue references v2.0 rules looked at this and said, string&& can’t bind to "meow" because "meow" is an lvalue, so push_back(const string&) is the only viable overload.  This would create a temporary std::string, copy it into the vector, then destroy the temporary std::string.  Yuck!  The rvalue references v2.1 rules recognize that binding string&& to "meow" would create a temporary std::string, and that temporary is an rvalue.  Therefore, both push_back(const string&) and push_back(string&&) are viable, and push_back(string&&) is preferred. 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s