UPDATE - March 2, 2012: the range-based for-loop and override/final v1.0 have been implemented in VC11 Beta.
There's a new C++ Standard and a new version of Visual C++, and it's time to reveal what features from the former we're implementing in the latter!
Terminology notes: During its development, the new C++ Standard was (optimistically) referred to as C++0x. It's finally being published in 2011, and it's now referred to as C++11. (Even International Standards slip their release dates.) The Final Draft International Standard is no longer publicly available. It was immediately preceded by Working Paper N3242, which is fairly close in content. (Most of the people who care about the differences are compiler/Standard Library devs who already have access to the FDIS.) Eventually, I expect that the C++11 Standard will be available from ANSI, like C++03 is.
As for Visual C++, it has three different version numbers, for maximum fun. There's the branded version (printed on the box), the internal version (displayed in Help About), and the compiler version (displayed by cl.exe and the _MSC_VER macro - this one is different because our C++ compiler predates the "Visual" in Visual C++). For example:
VS 2005 == VC8 == _MSC_VER 1400VS 2008 == VC9 == _MSC_VER 1500VS 2010 == VC10 == _MSC_VER 1600
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". Internally, it's just VC11, and 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):
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 overloads push_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. A temporary std::string is constructed, then moved into the vector. This is more efficient, which is good! (Yes, I'm ignoring the Small String Optimization here.)
The table says "v2.1*" because these new rules haven't been completely implemented in the VC11 Developer Preview. This is being tracked by an active bug. (Indeed, this is a Standard bugfix.)
Rvalue references v3.0 adds new rules to automatically generate move constructors and move assignment operators under certain conditions. This will not be implemented in VC11, which will continue to follow VC10's behavior of never automatically generating move constructors/move assignment operators. (As with all of the not-yet-implemented features here, this is due to time and resource constraints, and not due to dislike of the features themselves!)
(By the way, all of this v0.1, v1.0, v2.0, v2.1, v3.0 stuff is my own terminology, which I think adds clarity to C++11's evolution.)
Lambdas: After lambdas were voted into the Working Paper (v0.9) and mutable lambdas were added (v1.0), the Standardization Committee overhauled the wording, producing lambdas v1.1. This happened too late for us to implement in VC10, but we've already implemented it in VC11. The lambdas v1.1 wording clarifies what should happen in corner cases like referring to static members, or nested lambdas. This fixes a bunch of bugs triggered by complicated lambdas. Additionally, stateless lambdas are now convertible to function pointers in VC11. This isn't in N2927's wording, but I count it as part of lambdas v1.1 anyways. It's FDIS 5.1.2 [expr.prim.lambda]/6: "The closure type for a lambda-expression with no lambda-capture has a public non-virtual non-explicit const conversion function to pointer to function having the same parameter and return types as the closure type’s function call operator. The value returned by this conversion function shall be the address of a function that, when invoked, has the same effect as invoking the closure type’s function call operator." (It's even better than that, since we've made stateless lambdas convertible to function pointers with arbitrary calling conventions. This is important when dealing with APIs that expect __stdcall function pointers and so forth.)
decltype: After decltype was voted into the Working Paper (v1.0), it received a small but important bugfix at the very last minute (v1.1). This isn't interesting to most programmers, but it's of great interest to programmers who work on the STL and Boost. The table says "v1.1**" because this isn't implemented in the VC11 Developer Preview, but the changes to implement it have already been checked in.
Strongly typed/forward declared enums: Strongly typed enums were partially supported in VC10 (specifically, the part about explicitly specified underlying types), and C++11's semantics for forward declared enums weren't supported at all in VC10. Both have been completely implemented in VC11.
Alignment: Neither VC10 nor VC11 implement the Core Language keywords alignas/alignof from the alignment proposal that was voted into the Working Paper. VC10 had aligned_storage from TR1. VC11 adds aligned_union and std::align() to the Standard Library.
Standard-layout and trivial types: As far as I can tell, the user-visible changes from N2342 "POD's Revisited; Resolving Core Issue 568 (Revision 5)" are the addition of is_trivial and is_standard_layout to <type_traits>. (N2342 performed a lot of surgery to Core Language wording, but it just makes stuff well-defined that users could have gotten away with anyways, hence no compiler changes are necessary.) We had these type traits in VC10, but they just duplicated is_pod, so I'm calling that "No" support. In VC11, they're powered by compiler hooks that should give accurate answers.
Extended friend declarations: Last year, I said that VC10 partially supported this. Upon closer inspection of N1791, I've determined that VC's support for this is essentially complete (it doesn't even emit "non-Standard extension" warnings, unlike some of the other Ascended Extensions in this table). So I've marked both VC10 and VC11 as "Yes".
override and final: This went through a short but complicated evolution. Originally (v0.8) there were [[override]], [[hiding]], and [[base_check]] attributes. Then (v0.9) the attributes were eliminated and replaced with contextual keywords. Finally (v1.0), they were reduced to "final" on classes, and "override" and "final" on functions. This makes it an Ascended Extension, as VC already supports this "override" syntax on functions, with semantics reasonably close to C++11's. "final" is also supported, but under the different spelling "sealed". This qualifies for "Partial" support in my table.
Minimal GC support: As it turns out, N2670's only user-visible changes are a bunch of no-op Standard Library functions, which we already picked up in VC10.
Reworded sequence points: After staring at N2239's changes, replacing C++98/03's "sequence point" wording with C++11's "sequenced before" wording (which is more useful, and more friendly to multithreading), there appears to be nothing for a compiler or Standard Library implementation to do. So I've marked this as N/A.
Atomics, etc.: Atomics, strong compare and exchange, bidirectional fences, and data-dependency ordering specify Standard Library machinery, which we're implementing in VC11.
Memory model: N2429 made the Core Language recognize the existence of multithreading, but there appears to be nothing for a compiler implementation to do (at least, one that already supported multithreading). So it's N/A in the table.
Extended integer types: N1988 itself says: "A final point on implementation cost: this extension will probably cause no changes in most compilers. Any compiler that has no integer types other than those mandated by the standard (and some version of long long, which is mandated by the N1811 change) will likely conform already." Another N/A feature!
That covers the Core Language. As for the Standard Library, I don't have a pretty table of features, but I do have good news:
In VC11, we intend to completely support the C++11 Standard Library, modulo not-yet-implemented compiler features. (Additionally, VC11 won't completely implement the C99 Standard Library, which has been incorporated by reference into the C++11 Standard Library. Note that VC10 and VC11 already have <stdint.h>.) Here's a non-exhaustive list of the changes we're making:
New headers: <atomic>, <chrono>, <condition_variable>, <future>, <mutex>, <ratio>, <scoped_allocator>, and <thread>. (And I've removed the broken <initializer_list> header that I accidentally left in VC10.)
Emplacement: As required by C++11, we've implemented emplace()/emplace_front()/emplace_back()/emplace_hint()/emplace_after() in all containers for "arbitrary" numbers of arguments (see below). For example, vector<T> has "template <typename... Args> void emplace_back(Args&&... args)" which directly constructs an element of type T at the back of the vector from an arbitrary number of arbitrary arguments, perfectly forwarded. This can be more efficient than push_back(T&&), which would involve an extra move construction and destruction. (VC10 supported emplacement from 1 argument, which was not especially useful.)
Faux variadics: We've developed a new scheme for simulating variadic templates. Previously in VC9 SP1 and VC10, we repeatedly included subheaders with macros defined differently each time, in order to stamp out overloads for 0, 1, 2, 3, etc. arguments. (For example, <memory> included the internal subheader <xxshared> repeatedly, in order to stamp out make_shared<T>(args, args, args).) In VC11, the subheaders are gone. Now we define variadic templates themselves as macros (with lots of backslash-continuations), then expand them with master macros. This internal implementation change has some user-visible effects. First, the code is more maintainable, easier to use (adding subheaders was a fair amount of work), and slightly less hideously unreadable. This is what allowed us to easily implement variadic emplacement, and should make it easier to squash bugs in the future. Second, it's harder to step into with the debugger (sorry!). Third, pair's pair(piecewise_construct_t, tuple<Args1...>, tuple<Args2...>) constructor had "interesting" effects. This requires N^2 overloads (if we support up to 10-tuples, that means 121 overloads, since empty tuples count here too). We initially observed that this (spamming out so many pair-tuple overloads, plus all of the emplacement overloads) consumed a massive amount of memory during compilation, so as a workaround we reduced infinity. In VC9 SP1 and VC10, infinity was 10 (i.e. "variadic" templates supported 0 to 10 arguments inclusive). In the VC11 Developer Preview, infinity is 5 by default. This got our compiler memory consumption back to what it was in VC10. If you need more arguments (e.g. you had code compiling with VC9 SP1 or VC10 that used 6-tuples), there's an escape hatch. You can define _VARIADIC_MAX project-wide between 5 and 10 inclusive (it defaults to 5). Increasing it will make the compiler consume more memory, and may require you to use the /Zm option to reserve more space for PCHes.
This story has a happy ending, though! Jonathan Caves, our compiler front-end lord, investigated this and found that something our tuple implementation was doing (specifically, lots of default template arguments), multiplied by pair's N^2 overloads, multiplied by how much pair tends to get used by STL programs (e.g. every map), was responsible for the increased memory consumption. He fixed that, and the fix is making its way over to our STL branch. At that point, we'll see if we can raise the _VARIADIC_MAX default to 10 again (as I would prefer not to break existing code unnecessarily).
Randomness: uniform_int_distribution is now perfectly unbiased, and we've implemented shuffle() in <algorithm>, which directly accepts Uniform Random Number Generators like mersenne_twister.
Resistance to overloaded address-of operators: C++98/03 prohibited elements of STL containers from overloading their address-of operator. This is what classes like CComPtr do, so helper classes like CAdapt were required to shield the STL from such overloads. During VC10's development, while massively rewriting the STL (for rvalue references, among other things), our changes made the STL hate overloaded address-of operators even more in some situations. (You might remember one of my VCBlog posts about this.) Then C++11 changed its requirements, making overloaded address-of operators acceptable. (C++11, and VC10, provide the helper function std::addressof(), which is capable of getting the true address of an object regardless of operator overloading.) Before VC10 shipped, we attempted to audit all STL containers for occurrences of "&elem", replacing them with "std::addressof(elem)" which is appropriately resistant. In VC11, we've gone further. Now we've audited all containers and all iterators, so classes that overload their address-of operator should be usable throughout the STL. Any remaining problems are bugs that should be reported to us through Microsoft Connect. (As you might imagine, grepping for "&elem" is rather difficult!) I haven't audited the algorithms yet, but a casual glance indicated to me that they aren't especially fond of taking the addresses of elements.
We're also going beyond C++11 in a couple of ways:
SCARY iterators: As permitted but not required by the C++11 Standard, SCARY iterators have been implemented, as described by N2911 "Minimizing Dependencies within Generic Classes for Faster and Smaller Programs" and N2980 "SCARY Iterator Assignment and Initialization, Revision 1".
Filesystem: We've added the <filesystem> header from the TR2 proposal, featuring super-cool machinery like recursive_directory_iterator. Note that the 2006 proposal (before work on TR2 was frozen due to C++0x running extremely late and turning into C++11) was derived from Boost.Filesystem V2. It later evolved into Boost.Filesystem V3, but that will not be implemented in VC11.
Finally, in addition to numerous bugfixes, we've performed a major optimization! All of our containers (loosely speaking) are now optimally small given their current representations. This is referring to the container objects themselves, not their pointed-to guts. For example, vector contains three raw pointers. In VC10, x86 release mode, vector was 16 bytes. In VC11, it's 12 bytes, which is optimally small. This is a big deal if you have 100,000 vectors in your program - VC11 will save you 400,000 bytes. Decreased memory usage saves both space and time.
This was achieved by avoiding the storage of empty allocators and comparators, as std::allocator and std::less are stateless. (We'll activate these optimizations for custom allocators/comparators too, as long as they're stateless. Obviously, we can't avoid storing stateful allocators/comparators, but those are quite rare.)
Here are all of the sizes for x86 and x64. (32-bit ARM is equivalent to x86 for these purposes). Naturally, these tables cover release mode, as debug mode contains checking machinery that consumes space and time. I have separate columns for VC9 SP1, where _SECURE_SCL defaulted to 1, and for VC9 SP1 with _SECURE_SCL manually set to 0 for maximum speed. VC10 and VC11 default _SECURE_SCL to 0 (now known as _ITERATOR_DEBUG_LEVEL).
Stephan T. Lavavej Visual C++ Libraries Developer
@steve just to be really controversial regarding terse, look a this white elephant:
shared_ptr<vector<pair<shared_ptr<platformstring>, shared_ptr<myobject>>> refvec;
Oh the joy!
@Glen but IT IS NOT C++ hence no joy! I don't care how much terser other languages are - as long as it's not C++ they (MS and dudes like you who fall for this crap) can stuff themself with it. And MS, stop calling this pug ugly creature C++, will you? It is another example when you're trying to make money out of someone else's hard work. Just to clarify - if it isn't in the standard it is not C++ - capisci?
"@Glen but IT IS NOT C++ hence no joy!"
But some grown-ups tend to use programing laguages as tools, not toys, you know. I think I'm not the only one tired of this childish crusade. Please, stop.
@beef I also use C++ as a tool - I just do not want MS to mess with this tool and how it operates because I want my work to be acceptable on other platforms not just on Windows. And it is MS who is on a crusade, and this crusade is about becoming an formal owner of C++. I simply refuse to allow them to do so and express my dissatisfaction with their actions. I have full right to do so. So could you please stop. And I do not get joy if someone barefaced changes/mutates/claims ownership on something which doesn't belong to them and yet they have the cheek to call it C++. IT IS NOT C++. Handicapped creature which will be used by dudes like Glen but not by respecting C++ programmers who care about portability of their soft. So could you please stop.
Herb Sutter does some explaining about the missing features in this talk: channel9.msdn.com/.../TOOL-835T
@Glen that's missing the point. Yes, your code is shorter because you can avoid a few shared_ptrs. But so what? I could make the code shorter with macros too.
How about this?
Just define a few macros, and you can write your code *that* tersely.
Heck, I could define the entire line of code like this:
Extremely terse. But it has nothing to do with what people are complaining about.
C++11 makes it possible to write more terse C++ code out of the box. Thus, C++11 is a good thing for those who like terse code. And that is one reason why lacking C++11 support is a bad thing.
VC11 lacks C++11 support. Thus, a lot of people are upset.
And that's all there is to that particular complaint. WinRT and the "special" C++ used to interface with it has nothing to do with this.
Now, there is a completely different series of complaints running in parallel, which goes like this:
So far, WinRT seems to rely heavily on a proprietary nonportable dialect of C++. This hurts for a number of reasons:
- most people remember the last several proprietary C++ dialects Microsoft invented, and, quite reasonably, are worried that we're going to see history repeat itself, and that Microsoft is going to try to move people away from ISO C++. Again.
- Many people use other compilers than VC11, and they seem to be left out in the cold as far as WinRT goes. this is true for GCC/MingW or Clang, but also for Microsoft's own compilers. So far, it seems unlikely that VC10 will be able to compile this "Microsoft-C++ MK3". Sure, there is a hypothetical COM API, but (1) zero effort seems to have gone into making viable ISO C++ wrappers that might work with other compilers, and (2) zero effort seems (so far) to have gone into *documenting* the COM API or how it can be used.
So a lot of people are upset about that. Note that C++11 doesn't figure in *this* complaint, which is simply about WinRT and the language into which it is being projected, and the confusion Microsoft is causing by consistently calling it "C++".
They are two separate issues, and saying that WinRT's C++ dialect is terser has *nothing* to do with the point that C++11 enables terser code than C++03 did.
@beef: and an extra note, just for you: some grown-ups tend to use programming languages as tools, yes, and that is why we require them to work as expected. A kid might be amused by a chocolate hammer, but someone expecting his hammer to work *as a tool* will not be happy.
YOU may use C++ as a toy, where you don't care what it does, as long as it entertains you. But to someone maintaining a code base for an application that is required to compile and run on three different platforms, compilers which fail to implement your programming language are *broken* tools.
When you sell a product as a "C++ compiler", people should be able to reasonably expect that it will compile (most) C++ code. That has nothing to do with grown-ups, and it has nothing to do with toys, or with "childish crusades".
If you have a problem with that? You can put it where the sun doesn't shine. And you can take your condescending attitude and your "I'm more grown-up than you, and anyone who has different needs than me is just a child" garbage, and put it in the same place. Because it sounds like *you* only use C++ for some small single-compiler, single-platform *toy* application, which can be effortlessly migrated to VC11, and where portability is no concern whatsoever. And that's great and fine, and I'm very happy for you, but if you don't even realize that some people sue C++ on a slightly larger scale, then you have no business calling others childish.
I noticed a couple of informative blog entries on the topic of interfacing with WinRT using native C++:
It would appear to be a rather cumbersome process, and moreover, required hacking the project file in ways not permitted by the UI.
std::cout << (
sizeof(deque<int>) > sizeof(queue<int>)?
"Really? How is that possible?"
"That's what I thought.");
Benjamin Lindley: Good catch, the x86 table was damaged when it was pasted into the blog. (Also, the type column said "forward_list<int> N/A".) I've fixed it, and I've verified that the blog's tables (both x86 and x64) match my original tables.
Both deque<int> and queue<int> were 24 bytes in VC10 x86.
@moderators, hmmm my last reply to Jalf seems to have vanished - it was really short and not even remotely inappopropriate and i swear i watched it appear already so surely it can't have been deleted or lost by the timeout issue? is there other known bugs with this blog?
anyway, I'll type it as verbatim as I can again
@Jalf / KMNY, I think you may have taken my comment to steve above about vector<pair<platformstring^,myobject^>> ^refvec the wrong way. It was meant to be sarcastic!
I appreciate it might not have been clear though :)
The "white elephant" remark was meant to be read as:
"hey steve, this ^ code is short too!! Just try to ignore the white elephant in the room which is that it's not even C++ but C++/CX!"
If you've read any of my other lengthy comments on the other Build blogs (that I wrote well before the comment that you appear to have taken literally), you'll see that I am totally on the same page as you already, regarding most if not all of your comments to me in your last message.
So it seems like an innocent mix up, sorry for not being clearer. teach me to be sarcastic lol. :)
@jalf, If you haven't read my comments though, check them out and you should see what I mean. They're all over the build blogs, The Why C++ has a few to start with if you missed them.
@Glen fair enough. It seems like I've misjudged you. Sorry for this but the sarcasm wasn't clear so I hope you understand. Anyway, regards.
Pathetic. Really sad, GCC is miles ahead, with c++11 really late(and without concepts or nonminimal(aka nonpathetic ) unicode support) I have a really bad feeling about c++ future esp. on Win platform.
Just to make it clear STL is awesome, I blame MS managment that doesnt care enough about c++ not even to match FREE g++.Ironically IDE improvements look nice, to bad that people will be migrating to Linux.
> to bad that people will be migrating to Linux
Kids, maybe :)
Too bad C++11 is far beyond D and will never get close without drastic changes to its development process.
> And you know why the loud and clear voice did not come through earlier?
> Because everybody assumed that your "C++ rennaisance" includes significant
> advances in support for C++11 already.
As a Visual C++ MVP, I emphatically agree with this statement. Even with the few vNext tidbits we MVPs got to see early under NDA, it is still a shock to see what little (apparent) effort went into vNext's C++11 language support, and most definitely a disappointment.
Sign me up for the "I didn't loudly and clearly call for more C++11 support because I got the impression you were doing it already"-wagon.
Really, for all the talk about a C++ renaissance, and given that VC10 actually came with a relatively competitive C++0x feature-set when it was released (even if it has been left to rot since then), I think most of us assumed that you were actually working on C++11 support, and that we didn't need to kick down your door and throw you against the wall and scream our demands for C++11 support into your faces. We thought you were working on bringing your C++ compiler up to date already. Now you're telling us that this is basically what we should have done if we wanted more C++11 support.
Lately it seems user feedback has become far more important to the VS team, but there's an important piece missing for it to work: information has to flow both ways. You need to be at least a little bit honest and forthcoming in telling us what you're working on, if you want us to provide useful feedback on it.
Being quiet for the first 18 months, and then telling us "by the way, we didn't hear a clear demand for C++11, so we decided to put that on the back burner" just means you've failed. If you needed our opinion on C++11 support, why didn't you ask us the day you started work on VC11? Why wait 18 months before giving us anything to provide feedback on?
About not having to wait a full release cycle, that honestly sounds great. If the VS team has decided to actually support, update and improve the product after it ships, if VS is going to be developed and maintained the way everyone else develops and maintains software in 2011, that's the single greatest improvement to VS that I can imagine.
But right now, in VS10 we see is a compiler which, apart from a few critical bugfixes delivered in SP1, and one or two security holes plugged, is exactly the same as it was the day it was released. That makes it a bit hard to believe that VS11 should be different. Are we really going to see Microsoft *update* a shipping product? And when are you going to start?