I don't consider STL to be part of the actual language, seeing as how it is a library based on and for the purpose of expanding the language. To that end, I have known of the existence of regex, but I had no idea exactly what it was until last week. It isn't something that I have ever used or needed. Now that I know what it is, I can find uses for it when gcc implements it, but it will not be missed in the interim. My only gripe with VS' STL implementation is that it doesn't properly implement emplace (emplace_back, et. al). All emplace does in VS is call push_back. I can do that myself!

"STL" doesn't exist.

The standard library is part of the language in any non-standalone implementation of the language. As per the language standard.

The lists that Matt-D posted highlights some of the things that I cannot do and want to do in VS. Initializer lists, variadic templates, defaulted and deleted functions (cannot properly do move constructors without 'em) and user-defined literals to name a few. These are not part of STL and I cannot even try to use them in VS 2012.

As I noted previously, there are some things that are missing from VS that are useful (variadic templates is pretty high on my list), however its not actually something I find myself needing or even wanting to use in a large number of cases. You can handle move constructors perfectly fine without the use of default or deleted functions. Might not be as simple as just tacking on a default or deleted, but you can do it quite fine and easily.

It would be nice if there was some real effort to get Clang on Windows. I'd be real tempted to switch to it from GCC considering what I've seen with error messages and C++11/14 support.

Yeah I've used clang on non-Windows platforms and it's really great. I know one guy was maintaining a pre-compiled version of clang for Windows along with a VS add-in that could switch out MSVC++ for clang, but I don't know if he's still actively working on it. For the VS add-in to actually workable someone would have to figure out how to generate .PDB's so that the VS debugger would work with it, and that's probably a difficult task.

OP, have you tried the VS2013 preview? It supports more of C++11 -- indeed all, or nearly all, of the stuff you'd actually care to use. Again, its just a preview, but the real-deal is just around the corner.

Far from it. Implicit move generation is pretty important, and ref qualifiers are very helpful for correctness. And no proper constexpr. And no user defined literals. All delayed to post VC2013 CTPs (so not for production code). The saddest part? On the far right (lowest priority/farthest in the future) there are still two C++98 bullet points. Admittedly not that important but that standard is now 15 years old, and Visual Studio still isn't there yet, and I suspect that C++11/14 will take just as long.

Visual Studio is lagging behind extremely.

About Mingw, I usually get my MinGW from http://sourceforge.net/projects/mingwbuilds/ those are very up to date.

I don't disagree that its behind, and I've perhaps made the mistake of overstating what it supports -- it does lack features both important and not-so-important. The point I was pushing at is that C++11 adds a lot of stuff, and VS2013 will contain the majority of it by numbers, and those numbers are made up of the most-important, most-game-changing additions -- things like auto, lambdas, r-value references, move semantics, perfect forwarding, variadic templates, etc -- that actually change the way we build software, rather than just making things nicer. Certainly there are still things to add that are critical for a set of people and also nice-to-haves for even a majority, but for a lot of what remains there are reasonable work-arounds or just making due with what we have now is not so terrible. Perhaps qualifying that as "nearly all of the stuff you'd actually care to use" was worded poorly -- if your goal is to use one of those unsupported features, or to have a play with all of C++11, then VS2013 won't deliver for you -- Its far from perfect, I'm just saying they have most things, and that those things they have provide the most value to the most people in their work.

You also have to keep in mind that Microsoft's compiler has a very different market in mind than open-source solutions like GCC or Clang -- The bulk of Microsoft's customers are corporations building and maintaining in-house tools. These corporations change at a glacial pace, and are entirely entrenched in the Microsoft Platform. Microsoft could have a markedly different dialect of C++ (as some have argued in the past, say VC++ 6,) and while that would not be a good thing, it would matter little to the majority their core customers. In fact, the change of new standards or changing behaviors in small ways is often more painful for those customers than the benefit they might provide -- especially if they have critical code that's on life-support where they haven't the budget or interest to update it wholesale, but it needs to compile when they fix a bug. That's why MS maintains a number of switches that restore some of that non-standard behavior (like for-loop index variable scoping from VC6).

People who rely on open-source compilers typically (or, moreso than the customers I describe above) keep their code moving along to current standards (sometimes as a re-write, sometimes as a consequence of the software being open-source), and when its not kept-up-to-date, they have the option of going back to whatever branch of GCC or Clang last worked for them, and they get the benefit of whatever bug-fixes have been made to that branch even long-after mainline development has moved on to the next point (or even whole-number) version. For Microsoft's compiler, you only get critical bug-fixes until the support lifetime is up.

There's also the fact that many of the challenges implementing new features in Microsoft's compiler is because the compiler's legacy goes back to pre-standard C++ (C++96), which is certainly not true of Clang. Its true of GCC also, but GCC has had the benefit of essentially rolling releases. Everyone who uses GCC upgrades because doing so only costs you time, and its typically very incremental, MS's releases are more spaced-out, and often more drastic, so updating code for the new release is a huge deal in a corporate environment, and code may languish in old features and ways of doing things for a very long time as a result.

Its absolutely reasonable to criticize Microsoft for being behind, but such criticism should be tempered by understanding the realities the product faces. They're doing what best-serves their customers, most of whom are not standards-wonks. There's a lot of work ahead to be sure, but I doubt it will be so long before C++11 and 14 will fully conformant. Probably late 2015 at the earliest would be my guess, but not languishing for 5, 10, 15 years like a couple parts of C99 have.

The saddest part? On the far right (lowest priority/farthest in the future) there are still two C++98 bullet points

I don't know which list you are looking at, but I'll give even odds that one of those C++98 features is template export.

Nobody (with the partial exception of Comeau) ever implemented template export - it's widely regarded as a feature that should never have been added to the standard in the first place.

I'd hardly call it fair to ding Microsoft for that one, since both GCC and Clang also fail that test...