Earlier this month, I announced in my GoingNative talk C++11, VC++11 and Beyond that Visual C++ 11 Beta would be available in February.
Today’s the day: You can download Visual Studio 11 Beta here.
Interestingly, VC++11 is being distributed under a go-live license, which means that Microsoft supports using this compiler to write production code. That’s unusual for a first beta, and it means you can start using its features – notably parallelism and C++11 library and language conformance improvements like range-based for loops – in your production code right away.
We had already announced that VC++11 includes quite a bit of stuff, and here’s what’s new in the beta. Some highlights of the whole product:
- Complete ISO C++11 standard library. As announced in September, we’ve added full support for essentially the entire C++11 standard library, which I think is a first for the industry to ship in-the-box with a C++ compiler product. We already shipped most of the C++11 stdlib in VC++ 2010, and now we’re including threads, mutexes, condition variables, atomics, futures, and async – and not just as checkmark features, but with async and futures built on top of our ConcRT runtime that also powers the Parallel Patterns Library. Oh, and we’re also shipping an implementation of the draft-standard header <filesystem> based on Boost.filesystem for portable access to directories and files. (The ISO C++ committee has just resumed work on filesystem for near-term standardization; more about this soon in my ISO C++ trip report, which I plan to post within a few days.)
- Several more ISO C++11 language features. As mentioned in September, we’ve added support for C++11 stateless lambdas and scoped enumerations. On top of that, we were happy to announce this month that we’re also adding the range-based for loop, override, and final – all of which are available in today’s release, and supported for production code.
- Parallelism galore. As we announced in June, it includes C++ AMP for parallel programming on CPUs and GPUs (with a view to more in the future, including cloud). This month we were also able to add that if the end user’s machine doesn’t have a compute-class GPU and is running Windows 8, we also provide an automatic fallback to multicore + vector SSE instructions, which for now is a fallback but we will continue to improve, so it’s already not just about GPUs. We’ve also expanded the Parallel Patterns Library (PPL) to support Standard C++11 concurrency features, provide more STL-style concurrent containers (e.g., concurrent_unordered_map), more parallel STL-style algorithms (e.g., parallel_sort), and a block-free continuation library for async operations (think “future.then()”, but for now we named it “task.then()” in case ISO C++ wants to surface something like this differently). Almost lost in all the news was another cool nugget: We’re also shipping an automatic vectorizing and parallelizing compiler that takes loops (with optional hints) and automatically generates both multi-core parallel and SSE-style vector code for you.
Windows 8 support, including Metro-style tablet apps on x86 and ARM. A major engineering change like Windows 8 comes along about once a decade, so with C++/CX and WRL we did a huge amount of work to ensure that VC++ gets great compiler and tool support for writing Windows 8 apps, while writing the minimum quantity of non-ISO standard code on the boundaries with the Windows environment (usually just ^ and ref new, similar to C++/CLI; the vast majority of your code should remain portable C++). And we wanted to make sure that VC++ is a first-class language that is visibly clean, safe, and fast – just as clean and safe in side-by-side code examples with Javascript and .NET CLR (e.g., you can write a XAML UI equally easily on top of any of these language projections), and with C++’s traditional power and performance (e.g., VC++ also supports creating tablet DirectX games and other graphics-intensive apps). Oh, and we brought up a whole new processor architecture: ARM.
As I also mentioned in this month’s talk, once VC++11 ships, we’re switching to a faster out-of-band release cadence so that we can deliver features more quickly than waiting for Visual Studio release schedules – especially to continue to roll out C++11 language features in batches, on a path to full conformance as soon as possible. The first thing you’ll see is a Community Tech Preview (CTP) that we intend to ship soon after VC++11 ships, which we expect to take the form of a new command-line compiler (initially not IDE integration and Intellisense) that you an drop into VC++11 to quickly start taking advantage of still more of the new C++11 language features, with a full out-of-band release to follow after that with still more.
If you haven’t already, please take this quick C++11 feature survey where you can vote on what C++11 features are most urgent for you in VC++. We’re going to implement all C++11 features, but we have to do them in some order – we’re users too and talk to customers regularly, so we think we know what’s most urgent, but we want to sanity-check that with you and make sure we’re doing them in the right order to deliver the most benefit to the most people as soon as possible.
Enjoy!
Sutter’s Mill 
@Robert Potter: I am well aware of that. However, the lack of XP support in VS11 is the deciding factor here. We simply cannot ditch a large percentage of our customers and thus will have to stick on VS2010 for the time being (even though I really really really want to use the new C++11 stuff).
@Legace Range-based for is in for this release.
Oh the pain and sorrow of having to wait a few years to use ranged based for loops, atomics, and all the other great C++11 features. XP, why..? Microsoft, why..?!
Hopefully VS11 RTM will support XP targeting. One can dream..
Windows XP support for the CRT and MFC is very important.
This mess could have been avoided if the CRT and MFC had been designed using XP functions from the start. Supporting or not supporting a version of the Windows OS is probably the #1 decision. I believe such decisions should be made based on feedback, not random assumptions.
I took the survey but I believe there is mistake about deleted functions, the “= delete” keyword can be applied to any function not only for special member functions. It is used to delete function signatures from the overload set during overload resolution.
Also it would be a lot more useful if we could conditionally delete overloads instead of using std::enable_if!
XP support should be dropped only when XP is fully phased out (which, if I understand correctly is due in 2014). Until customers aren’t forced to upgrade, they won’t. They see it as unnecessary cost, and frankly, they are right. They will still demand XP support for the applications until they aren’t forced to update.
I agree with phasing out XP, but I don’t agree with the order it is happening: first the OS, then the dev tools, not the other way around.
@Alfonse, after approving your comment:
I understand you’re upset, but hurling intemperate accusations at one of the people who is voluntarily spending time trying to help you doesn’t help your case.
The truth is what I said, or I wouldn’t waste people’s time pointing to the Connect bug. That bug is still open for voting and commenting. It was marked “closed as by design” for the September Developer Preview, not for RTM; I agree that wasn’t clear because it was poorly worded, but that’s what it was intended to say.
VC2011 might or might not ship with XP targeting support, but as of right now that’s an open question and several of us (including me) are actively working on it. Thanks again to those who are giving constructive and actionable feedback. It’s very helpful.
“Re Windows XP support, I can’t comment on XP support for this release beyond what’s been said, but I can point you to where to file Beta feedback on this specifically: http://connect.microsoft.com/VisualStudio/feedback/details/690617. This (or other Connect bugs you may open on this or other topics) will definitely be considered side-by-side with the other Connect bugs and their relative customer rankings as we try to prioritize the ones people vote highest and comment on most with specific data.”
This is a bold-face lie. This bug was closed as “as designed.” It will not “definitely be considered side-by-side” with *anything*. The decision has already been made, and further feedback will be irrelevant. The bug is closed, Microsoft had already decided, end of story.
I really don’t know why you want to lie to us Herb. Just say it: VC2011 will not support XP, no matter how many people it impacts or who complains about it. Say the words. That’s what Microsoft is doing. Stop blowing smoke at people and tell the *truth*.
I have to say that it’s very disappointing that you would lie to the community so brazenly. Bad form, Herb, bad form.
Thumbs up for having a very complete C++11 standard library! However, what is the priority order for MSVC compiler devs? What is taking so long for C++11 language features? (I remember Douglas Gregor mentioning that it took him one week to implement variadic templates in gcc).
I am also impressed :). Beta compiles LLVM and Clang 3.0 like a breeze (except for some portions in the optional toolchain, possibly requiring variadic templates when looking at the error messages; but these are not important for the LLVM/Clang core)… And also quite fast! For me this indicates that even the beta compiler is already quite solid and doesn’t choke himself on advanced code bases. The new look of VS 11 is ok. I maybe even like it more, since it got rid of all the color based distractions. Most importantly for me were the new C++ languages features though. I hope VC++ will have full support within the next one or maybe two years! Maybe you could also think of some “auto update” of the compiler, so that it simply notifies us when new features are available and on command, adds a new toolset to VS? The old toolset should still be selectable, since all those beta compilers will sure break some code… Keep on the good work and don’t listen to all those dumb asses who write “pathetic” or similar things to the new release [on msdn sites and stuff, now here].
“I don’t see an Express edition anymore.” Of course there’s no express edition. It’s a *beta*; everyone can download it. Express is a stripped-down version of Pro; if Pro works, then Express will also work.
I don’t see an Express edition anymore. Very worried about that…
@Herb: > I no longer like Option 3 very well […] because it’s really hard to write correct code. I will update this article to have […] cancellation_token
I understand these concerns, however I am convinced we could do better than providing *no* interruption support in std::thread. Or has it been a strategic decision to not include it, until it becomes clear what the best solution is? The idea with “cancellation_token”, which is essentially a stripped down version of boost::thread interruption, solves only half of the problem. For short-running threads it is okay to poll for cancellation. However for long-running background threads which are in a wait call, waiting on a condition (=for more work), I cannot poll at the same time. What I need here is exactly the boost interruption model which aborts/throws an exception during condition wait.
The fundamental problem with boost::thread interruption comes down to writing exception safe code. I’m not sure whether it’s a good idea to cater for all the non-exception safe code. Maybe if the code isn’t exception safe one shouldn’t mess with threading at all, which is an even more difficult topic.
Nevertheless why not explicitly ask the user what he wants? C++11 lambdas made an excellent choice of not providing any default capture variant, since neither “=” nor “&” is superior in general. Concerning the question whether interruption should be allowed to happen during “condition wait” we have the same situation. How this looks syntactially doesn’t matter that much (be it a new function “condition_variable::wait_interruptible” or a new bool flag “interruptible”). While the user defines the interruption behavior, he thinks actively about the impact of exceptions in the current context. This is in fact cooperation without polling.
Performance is impressive in both build and execution times. Tried C++ Performance Benchmarks http://stlab.adobe.com/performance/ and got:
VC10 build: 14,07 seconds
VC11 build: 4.25 seconds
VC10 exec: 31:29.0 minutes
VC11 exec: 24:31.4 minutes
“before we pull the trigger to do this at the expense of delaying other work, how does item rank compared to, say, getting more C++11 features six months sooner if we didn’t do something about this issue?’”
It doesn’t matter when the new C++11 features get added if we can’t use them in production code because it would mean that a significant number of our customers can’t use it. I have both voted and commented on that report.
As I understand it, the binaries that compiler produces supports the OS, but the MFC and CRT libraries simply use static linking instead of dynamic linking for functions which are specific to Vista and later. Is that an accurate statement, or is there more to it than that?
@ChrisW: Yes, in the beta the range-based for loop works in the compiler but isn’t yet recognized by the IDE. It will be at RTM.
Herb,
I’ve been using VS11 for 24 hours now. Looks good so far, except:
The range-based for loop doesn’t seem to have intellisense support. It does compile though.
vector vec;
vec.push_back( 10 );
vec.push_back( 20 );
for (int i : vec ) {
cout << i;
}
Intellisense reports:
1 IntelliSense: expected a ';' c:\Users\10065035\Documents\Visual Studio 11\Projects\ConsoleApplication1\ConsoleApplication1.cpp 18 15 ConsoleApplication1
2 IntelliSense: expected an expression c:\Users\10065035\Documents\Visual Studio 11\Projects\ConsoleApplication1\ConsoleApplication1.cpp 18 21 ConsoleApplication1
Re Windows XP support, I can’t comment on XP support for this release beyond what’s been said, but I can point you to where to file Beta feedback on this specifically: http://connect.microsoft.com/VisualStudio/feedback/details/690617. This (or other Connect bugs you may open on this or other topics) will definitely be considered side-by-side with the other Connect bugs and their relative customer rankings as we try to prioritize the ones people vote highest and comment on most with specific data.
If you care about this or any other bug/concern, the best thing you can do is upvote the relevant item and add specific comments — note that even brief specific data about how/why a particular issue affects you always helps more with prioritization than a one-line data-free flame. If enough people upvote and comment on any given Connect bug/request, that bug will get considered; we do watch and listen to Connect bugs. Note that if we do maybe spend more time on a given Connect bug/request (such as XP support, or anything else), it’ll always be at the expense of doing other things more slowly, so if this turns out to be a huge issue then one of my follow-up questions later on might be a poll like, ‘okay, but before we pull the trigger to do this at the expense of delaying other work, how does item rank compared to, say, getting more C++11 features six months sooner if we didn’t do something about this issue?’ — there are only so many dev and QA hours so it’s always a question of priority compared to other desirable features.
@zhnmjo123: For interruption, see my article “Interrupt Politely” at http://drdobbs.com/parallel/207100682 .
One update: I no longer like Option 3 very well as described in that article, because it’s really hard to write correct code in practice using Java/.NET style thread interruption because exceptions can be thrown from things like mutex::lock and people just can’t/don’t write correct code in the face of that even when they know about it (example: the .NET Frameworks themselves are not interruption-safe, making the feature essentially unusable in practice). For the book (which I hope to finally write this summer) I will update this article to have Option “3.5” or something refer to the newest best practice (not implemented in Boost’s version) which is cancellation tokens such as cancellation_token in PPL (http://msdn.microsoft.com/en-us/magazine/hh781020.aspx). That’s something people can actually code against because it’s not done “to” them, it’s more co-operative.
And of course Option 4 is a perennial favorite, enables clear and correct code and really isn’t more complex: write the cooperative interruption code yourself (e.g., check an atomic flag).
I feel like it is Christmas morning and I’ve opened my presents and I’m not allowed to play with them. The lack of XP support will prevent me from using this at work. I tried to be a good boy this year…
@Herb: > in VC++ you will now be able to use plain std::thread (and std::atomic, etc.).
I understand that std::thread has no means of interruption like boost::thread::interrupt. What is your suggestion how to deal with this problem in practice?
Currently I see only two solutions:
1. Implement a custom interrupt mechanism in each case. This is quite bad with regards to code redundancy. Also a simple “flag” solution doesn’t perform well if the thread is sleeping, or waiting on a condition.
2. Anthony Williams suggest to build an “interruptable thread” oneself based on std::thread. Although this is annoying to some degree, because this should be in std::thread already, I’m willing to go this route, if necessary.
PS: A remark for one of your next books/articles: Almost all examples on how to use std::thread on the net are not exception safe (as Andrei Alexandrescu also noted), since they reference a local variable somewhere, but are not joined in case of exceptions. If someone can show a shiny ideomatic and correct usage of std::thread, it would be you ;)
Herb,
Any chance of a comment on the situation that executables produced using VS11 wont run on XP? Like many others we have a large number of customers still on XP so I can’t simply choose to not support that OS.
As I see it this decision by Microsoft will mean that adoption of new C++11 features and libraries will be slower than it should be which I think you will agree is a less than ideal situation.
I don’t hold out much hope of a change of policy by Microsoft given this comment by Pat Brenner.
“This behavior is by design in MFC and CRT for Visual Studio vNext. The minimum supported operating systems are Windows Server 2008 SP2 and Windows Vista. Windows XP is not a supported operating system for the release (design-time or run-time).
Pat Brenner
Visual C++ Libraries Development”
All very frustrating…
Looking forward to being able to use more C++11 features.
Shame the UI of VS11 is SO UGLY
http://blogs.msdn.com/b/visualstudio/
The lack of colour, the new toolbar icons and the SHOUTY::::: LABELS::::: are just *wrong*
@Rick: The only thing I know for sure is that the beta will expire after we RTM (ship the release). More specific dates will follow as they firm up…
@zhnmju123: Yes, in VC++ you will now be able to use plain std::thread (and std::atomic, etc.).
All sounds really great apart from one fly in the ointment. You can’t compile an app with VC++11 and have it run on Windows XP! That completely stuffs my company as we’ve lots of customers who are still on XP. Very sad that we’ll have to stick with vs2010.
[quote]VC++11 Beta […] write production code. [/quote]
Does this mean it’s safe to replace boost::thread with std::thread, finally? Looking at boost::thread’s bug tracker makes me shiver, but “Beta” still sounds uncanny…
> range-based for loops
OMFG…a dream came true
Very excited about this! Component runtimes come and go, native code is forever :-)
It almost seems too good to be true!
Great job! Can’t wait…
Any idea if we have to worry about the beta expiring before the Express edition is available?
Can’t wait, sounds great!