Announcing the Visual C++ Compiler November 2013 CTP

Last year in November, we released an out-of-band customer technology preview (CTP) of the Visual C++ compiler. It contained preview versions of C++11 features which we subsequently fully released in Visual Studio 2012. At that time, and at GoingNative 2013 this year, we promised to keep releasing these CTPs to show our progress towards full C++11 and C++14 standards conformance. Today, we are happy to update the map:

Stephan T. Lavavej has created helpful and informative videos about these language features in part 10 of his Core C++ series of videos on Channel 9.

Installation and Usage

After downloading and running the installer, you should be able to use the new compiler in Visual Studio 2013. We recommend that you first create a separate project configuration and modify that configuration to use the new compiler. To do so:

Open the “Build” menu and then select the “Configuration Manager” option.

In the Configuration Manager, duplicate your existing configuration.

Open the project’s Property Pages by pressing F7 or right clicking the project in Solution Explorer and selecting “Properties”.

Important Notes

This is a Customer Technology Preview and does not come with a “Go Live” license.

Visual Studio 2013 is a prerequisite for using this compiler. If you don’t have Visual Studio 2013 installed, we recommend that you download the free Desktop Express edition here.

This package contains only the compiler and does not yet come with an updated standard library.

This version of the compiler is only compatible with CRT 12.0.

This version of the compiler can only be used as an alternative to the Visual C++ 2013 RTM compiler.

While a new Platform Toolset is provided for convenience of integrating the compiler as part of the Visual Studio 2013 build environment, the Visual Studio 2013 IDE, IntelliSense functionality, debugger, static analyzer, and other tools remain essentially unchanged and do not yet provide support for these new language features.

For a list of limitations and breaking changes introduced by this CTP compiler, consult the documentation provided on the download site. It will always include the most up-to-date information.

We Want Your Feedback!

One of the main reasons for this release is the gathering of community opinions and bug reports so that we can improve the quality of the compiler. If you find any bugs, and there are certainly many, please submit a report for Visual Studio via Microsoft Connect and use “[Torino]” as a prefix in the bug title. You can also leave comments below and submit suggestions via Visual Studio UserVoice or the integrated Send-a-Smile feature.

We are thankful for your support, and we hope that you have fun in using all these shiny new features in your code. Remember, you can grab the CTP here. Learn more about the features in the CTP from STL on in Core C++ 10 on Channel 9.

Hopefully all the work on implicit move has squashed the annoying ICEs I've seen mixing move with brace init.

Is the Windows 8.1 restriction for __await (mentioned in the "breaking changes") a CTP thing? STL mentioned it sits on ConcRT, which I thought was Vista+…. Not really a huge problem while it's a preview feature, but I would like to use it sometime within the next 10 years :P (Enterprise IT is a… unfun client).

In any case, it will be neat to play around with this, implicit move especially should save a bunch of stupid boiler-plate!

Sadly, C++14 doesn't look like it does enough to make the language more productive to work in or broaden its appeal. Not Microsoft's fault, I realize, and I know I'm supposed to be excited about this, but god, after 2 straight years of nothing but C++ projects, I'm just plain tired of this kind of news. The more the standard evolves the more fatigued I get, and these posts like this just serve to remind me of how much of a mess this language is. [Can't wait to get back to C#. Or maybe it's time to learn Go.]

…

"Whenever the C++ language designers had two competing ideas as to how they should solve some problem, they said, 'OK, we’ll do them both'. So the language is too baroque for my taste." — Donald E Knuth

"Within C++, there is a much smaller and cleaner language struggling to get out." — Bjarne Stroustrup

"C++ has shown that if you slowly bloat up a language over a period of years, people don't seem to mind as much." — James Hague

"I believe C++ instills fear in programmers, fear that the interaction of some details causes unpredictable results. Its unmanageable complexity has spawned more fear-preventing tools than any other language, but the solution should have been to create and use a language that does not overload the whole goddamn human." — Erik Naggum

@sttldev: C++14 is to patch up missing parts of C++11 that should have been there: make_unique<T>(), actually using user-defined literals, etc..; If you mean C++11 doesn't provide enough over C++98 I'm not sure exactly how much you want out of your languages: it is, without exaggeration, the biggest language improvement I've ever seen! However, the next big "feature jump" will be C++17, in particular concepts-lite and modules alone together look to make it an easy enough to pick up language, and there is a lot of work on getting useful libraries (networking! xml! 2d graphics!?) into the standard.

An interesting set of quotes in order to back your point: the latest quote (by earliest dated reference I could google) was 2007. If you want to complain about C++98, go ahead, it's a terrible language from a design point of view, used because all the alternatives suck at what it's good at: abstraction without cost.

Sorry, that was more of a late night gripe session after a rough day of development, and C++ wasn't making my life any easier, so maybe this wasn't the right place to vent. The features in the new standards are great and useful, but the overall outcome is that the language is getting bigger and bigger and its cognitive load is increasing, even with the really simple stuff: How many ways are there to initialize a int? How many ways are there to zero out a struct? Which of these three smart pointers do I use? With each new feature I need to know exactly what is going on behind the scenes to make the best decision.

So I find myself writing in C++ when I have to, when there's no other choice (legacy code, availability of APIs, etc.), not because I want to. My management has a similar distaste on more pragmatic grounds: They've watched new devs struggle for months before they're good enough to write production code… try explaining std::bind, the rule of three, piecewise_construct, variadic templates, etc. to a kid fresh out of school and watch his eyes glaze over (the names alone scare them). And there's an interesting phenomenon I've seen: as these kids become more skilled in C++, the less they like it. This reaction is the complete opposite from every other language that we work with. People love C# and Python as they learn more. Why do you think this is?

Alex> Will these features be available with "Go Live" license in one of VIsual Studio 2013 updates?

As I explained in my video, you should not expect these features to appear in a "Go Live" Update to VS 2013 RTM.

Nicolas Silvagni: I'll ask if they're tracked by active bugs.

MFH> What is the new value of _MSC_VER or _MSC_FULL_VER?

_MSC_VER will be 1800, as we haven't incremented the major version number yet (same thing happened with the Nov 2012 CTP's timing). I'll ask about _MSC_FULL_VER – I've been running my own builds so I haven't installed the final CTP in a VM yet.

sttldev> How many ways are there to initialize a int?

C++11 provides uniform initialization so programmers can just use it everywhere. It has subtleties, but they're significantly less obnoxious than old-style initialization.

> Which of these three smart pointers do I use?

These correspond to significantly different powers – that's like choosing between vector and map. It's a decision, but not a very hard one.

> try explaining std::bind

bind() has been 99% superseded by C++11 lambdas, and 100% by C++14 generic lambdas. It was useful at the time, but we have better and simpler technology now.

> to a kid fresh out of school and watch his eyes glaze over (the names alone scare them).

How does anybody learn neurosurgery, or complex analysis, or any one of a zillion technical fields?

> as these kids become more skilled in C++, the less they like it.

I guess I'm 30 now, but I learned C++ when I was 19, and the more I learned, the more I liked it. I switched from C to C++ after realizing that C's "simplicity" was a weakness, and I loved C++ because I actually understood what it was doing, unlike Java.

In the grand scheme of things it doesn't make things simpler, or easier, it only – maybe, sometimes – makes things a little less difficult. Best of times is when you can just hire somebody else to do it (right)(the first time).

Will the blog system work better because of anything done any time recenty?

"If you mean C++11 doesn't provide enough over C++98 I'm not sure exactly how much you want out of your languages: it is, without exaggeration, the biggest language improvement I've ever seen! "

Yes, but quality in programming languages is typically not related to size.

I like many of the new features, but I think C++ has become a mess – look at the videos by Scott Meyers examining the strangeness of universal references, odd rules relating to const-ness and type guarantees, etc., etc.

I suspect its beyond any newcomer to really understand the language fully now. That's a very sorry state of affairs. Calling it baroque is an insult to baroque which was a style of ornamenting something functional. C++ is more Palinesque now – lipstick on a ….

You're wrong there, I'm the kind of programmer who deperately needs variadic templates, but that's a dog of a complex feature – maybe I just haven't seen its use well explained, but the first real world application I attempted made my brain ache, and I've been using C++ for around 20 years now.

Args is a "template parameter pack" and args is a "function parameter pack". One of the fundamental things about variadic templates is that the ellipsis means "zero or more". Therefore, this make_unique<T>() is callable with zero or more arguments. (If we want something to be callable for one or more arguments, we need to provide one ordinary argument followed by a parameter pack.)

Just as you can think of an ordinary template <typename T> void meow(const T& t) as stamping out an infinite family of overloads void meow(const TypeA& ta), void meow(const TypeB& tb), etc. (this is not strictly correct, but it's much closer to the truth than thinking of templates as macros which they are decidedly not), you can think of a variadic template as stamping out an infinite family of ordinary templates. So you can imagine this as stamping out make_unique<T>(), make_unique<T>(Arg0&& arg0), make_unique<T>(Arg0&& arg0, Arg1&& arg1), and so forth. Note how the rvalue reference is replicated. You can do the same thing with Args&… for lvalue references, or const Args&… for const lvalue references, and so forth. (Args… would be the simplest, taking parameters by value.)

Then in the body, the ellipsis is used to expand the parameter packs. The idea here is that you can build an arbitrary expression referring to template parameter packs like Args and function parameter packs like args. Then when you say the ellipsis, that expression is replicated once for each thing in the pack, and comma-separated. For empty parameter packs, it disappears. So this stamps out new T(), or new T(std::forward<Arg0>(arg0)), or new T(std::forward<Arg0>(arg0), std::forward<Arg1>(arg1)), etc. This is actually a somewhat advanced example of simultaneously expanding a template parameter pack and a function parameter pack. If you took const Stuff&… stuff, you'd just say call_something(stuff…) without having to mention the Stuff types. Note that the placement of the ellipsis is critical, as it determines what is being expanded. Saying std::forward<Args>(args…) wouldn't work.

(Variadic templates are actually smarter than I've described here; there's a bit of Standardese saying that pack expansions are well-formed for empty packs, even if the handwritten code wouldn't be; the simplest example would be template <typename… Bases> struct Derived : Bases… { }; where you want Derived : Base0, Base1, Base2, etc. If Bases is empty, then Derived has no base classes, even though saying "struct Derived : { };" would be bogus syntax.)

There are more rules for what happens when you overload variadic templates (these typically act naturally, if you're used to how overloading ordinary templates works), and other stuff, but that's the basic idea. Setting up "recursive" variadic template function calls isn't difficult, once you understand a non-recursive example like make_unique. Ellipsis placement can be used in a variety of patterns, but you just need to start by asking what sort of ordinary signature you want, then figuring out how to declare it. For example, taking (const tuple<Types…>&) is different from taking (const tuple<Types>&…). The former takes a single const tuple<T0, T1, T2>&. The latter takes multiple (const tuple<T0>&, const tuple<T1>&, const tuple<T2>&).

McCoy: There are two issues there: a GCC bug and a VC bug. The GCC bug is that it's faster than VC (yes, really!) because they're still implementing std::string with the Copy-On-Write optimization. COW was permitted by C++03 but is forbidden by C++11 (as COW is hostile to multithreading). VC hasn't used COW for ages (2005 and later for sure); we use the Small String Optimization which is permitted by both C++03 and C++11. The VC bug is in std::vector, where C++11 says that reallocation should sense whether moves are noexcept. If they are, reallocation can move and still achieve the strong guarantee. If they aren't, reallocation should instead perform copies – these are slower, but they're the only way to achieve the strong guarantee. The VC bug is that we don't have this logic – we always attempt to move, even with move constructors that can throw exceptions. As a result, we are fast – faster than we're supposed to be (this is a performance anti-nightmare) – and we are achieving only the basic guarantee.

VC 2013 RTM's C++11 Standard Library support is complete modulo missing compiler features, library bugs, a small amount of C99 machinery, and a very small number of missing library features (I am aware that <exception> is missing nested_exception, throw_with_nested(), and rethrow_if_nested()).

Is there anything I can do as the implementor of the move-only type to get it to compile (it's not unique_ptr in real life)? Beyond "if _MSC_FULL_VER == 180021114, create a default copy constructor", which isn't too terrible, I suppose.

Also, STL, is it knowable if the move operations of the various STL collections going to be as noexcept'y as possible (assuming _IDL==0) by the time vector becomes move_if_noexcept aware?

My only problem with the new features is that Microsoft and other vendors implement them before the standard is finalized, and then get changed.

I thoroughly read Stephan's posts about rvalue references, lambdas etc from back in 2010 in this forum, but they became obsolete just a year or two later because the features changed drastically. Consider that these were like 50-screen-page posts, and now all that knowledge is useless.

I understand that the features are complex because their purpose is complex, but you can't subject programmers to re-learn them over and over, they'll just get tired and not even bother anymore with them.

For extended sizeof, should this example compile? GCC and Clang compile it without warnings (well, Clang gives a "this isn't compatible with C++98" warning with -Weverything, but that's to be expected). The CTP doesn't like the last three sizeof usages, but is fine with the first one. The second one is almost directly from 5.1.1.13 in n3797, the last two are internal cases encountered when switching our emulation of extended sizeof to the proper behavior.

"My only problem with the new features is that Microsoft and other vendors implement them before the standard is finalized, and then get changed. … I understand that the features are complex because their purpose is complex, but you can't subject programmers to re-learn them over and over, they'll just get tired and not even bother anymore with them."

The standards committee prefers that there be real-life experience with the functionality before it is standardized. If you want to know why, see "export template" for what can happen when what is standardized has never been implemented.

I strongly suspect that this is a duplicate of the compiler bug DevDiv#813397 in our internal database. I've attached your repro to that bug.

> Is there anything I can do as the implementor of the move-only type to get it to compile (it's not unique_ptr in real life)?

Not to my knowledge.

> Also, STL, is it knowable if the move operations of the various STL collections going to be as noexcept'y as possible (assuming _IDL==0) by the time vector becomes move_if_noexcept aware?

I'll make those changes simultaneously. I can't promise anything, but I hope to be able to do this for the next major version.

ciel> My only problem with the new features is that Microsoft and other vendors implement them before the standard is finalized, and then get changed.

In addition to the Committee preferring implementation experience, many Standardese changes are made *because of* implementation experience.

> Consider that these were like 50-screen-page posts, and now all that knowledge is useless.

It's not useless, but it does have to be modified and extended.

> you can't subject programmers to re-learn them over and over, they'll just get tired and not even bother anymore with them.

Some programmers will keep up with technology changes, and some won't. Some programmers will find employment, and some won't.

Seriously though, it's not clear to me whether you're wishing for anyone to be doing anything differently. Do you want MS and other vendors to implement proposed features less aggressively? Everyone else is asking us to move faster, not slower. Do you want the Committee to avoid making major changes to features after they've been voted into the Working Paper but before the Standard is finalized? That would prevent mistakes like rvalue references v1 (so dangerous!) and lambdas v1.0 and decltype v1.0 from being corrected. Do you just want the Committee and its constituent vendors to get everything right the first time, completely avoiding Working Paper churn (which is a bigger headache for implementers than users, believe me)? Sorry, but most of us are human, and mistakes are inevitable.

Michael> For extended sizeof, should this example compile?

It should. We've filed DevDiv#834581 for this, thanks.

LM> This CTP introduces more bugs than fixes and improvements. Sigh.

It would be useful if you could provide bug repros, so we could fix them. That's why we've released this alpha build.

You encountered this one: "<filesystem>'s directory_iterator was returning paths that were too short (DevDiv#411531). (Note that recursive_directory_iterator worked correctly.) We fixed directory_iterator to follow N1975, the Filesystem V2 draft. (Filesystem V3 is on our radar, but it won't be implemented in 2013 RTM.)"

IMO the code generation quality is much better than VS2012's. I've noticed about several code generation relevent bugs reported at Connect, but those are unlike any of VS2012's. I don't like/attempt to complaints about others but i still think (and IMO too) if i was them i wouldn't write the code in the ways shown on the reports and i don't even recommend someone to write their code in those way either.

Did some quick testing with this new release and we get a little bit further with the compilation of our TAOX11 product but still several problems, including several internal compiler errors, reported some of our basic problems through connect, added just [Torino] to all subjects.