Announcing the Visual C++ Compiler November 2013 CTP

Announcing the Visual C++ Compiler November 2013 CTP

Rate This
  • Comments 46

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:

Today, we deliver on that promise.

Download the November 2013 CTP of the Visual C++ Compiler now. Breaking changes can be found here.

It contains the following C++11, C++14, and C++/CX features:

  • Implicit move special member function generation (thus also completing =default)
  • Reference qualifiers on member functions (a.k.a. "& and && for *this")
  • Thread-safe function local static initialization (a.k.a. "magic statics")
  • Inheriting constructors
  • alignof/alignas
  • __func__
  • Extended sizeof
  • constexpr (except for member functions)
  • noexcept (unconditional)
  • C++14 decltype(auto)
  • C++14 auto function return type deduction
  • C++14 generic lambdas (with explicit lambda capture list)
  • (Proposed for C++17) Resumable functions and await

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:

  1. Open the "Build" menu and then select the "Configuration Manager" option.
  2. In the Configuration Manager, duplicate your existing configuration.
  3. Open the project's Property Pages by pressing F7 or right clicking the project in Solution Explorer and selecting "Properties".
  4. In the "General" tab, change "Platform Toolset" from "Visual Studio 2013 (v120)" to "Visual C++ Compiler Nov 2013 CTP (CTP_Nov2013)".
  5. Rebuild your project.

Important Notes

Before downloading, note the following:

  • 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.

  • If anybody else needs the value of _MSC_FULL_VER it's: 180021114

    On you C++ discussion: I've now been programming C++ since about the age of 13/14 (seems I'm starting my second decade next year :D) and the more I use it the more I like it!

  • About aggregate initializer list bug there are some active feedbacks, for example:

    Active from 7/1/2013 (VS2013 Preview), without any comment or workaround from MS.

  • Nicolas Silvagni: Yeah, we've got active bugs tracking those problems - DevDiv#728401 (which is Connect#792161, linked by Yuri Kravchenko) and DevDiv#747250 in our internal database.

    MFH> If anybody else needs the value of _MSC_FULL_VER it's: 180021114


    > I've now been programming C++ since about the age of 13/14 (seems I'm starting my second decade next year :D) and the more I use it the more I like it!

    Cool! It's an exciting time to be a C++ programmer.

  • 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?



  • Would really like to see unrestricted unions

  • @simon buchan

    "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 ....

  • @STL

    "The kind of person who needs variadic templates desperately needs and loves them. Programmers who don't need to write templates especially don't need to understand variadic templates - for them, stuff like make_shared<T>(args, args, args) just works."

    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.

  • [2-part comment incoming; VCBlog has a 3072-character limitation.]

    Rob G: Basic variadic templates are surprisingly simple. I can show you an example.

    The simple one is make_unique<T>(args, args, args) from . The implementation, ignoring unrelated trickery, is:

    template <typename T, typename... Args> unique_ptr<T> make_unique(Args&&... args) {

       return unique_ptr<T>(new T(std::forward<Args>(args)...));


    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>&).

  • @STL, is the performance nightmare with Copy from 37:00-45:00 with VS2013?

  • I ran the code from the Meyers' slide 18, looped through it for 50 time:


    Output with VS2013 latest CTP installed:

    Time taken: 1628.00ms

    Time taken: 2253.00ms

    Time taken: 2159.00ms

    Time taken: 448.00ms

    Time taken: 3010.00ms

    Time taken: 775.00ms

    Time taken: 4211.00ms

    Time taken: 898.00ms

    Time taken: 45.00ms

    Time taken: 6084.00ms

    Time taken: 901.00ms

    Time taken: 371.00ms

    Time taken: 46.00ms

    Time taken: 8576.00ms

    Time taken: 955.00ms

    Time taken: 110.00ms

    Time taken: 46.00ms

    Time taken: 47.00ms

    Time taken: 48.00ms

    Time taken: 48.00ms

    Time taken: 13387.00ms

    Time taken: 776.00ms

    Time taken: 1214.00ms

    Time taken: 910.00ms

    Time taken: 50.00ms

    Time taken: 54.00ms

    Time taken: 65.00ms

    Time taken: 53.00ms

    Time taken: 47.00ms

    Time taken: 46.00ms

    Time taken: 53.00ms

    Time taken: 20659.00ms

    Time taken: 1188.00ms

    Time taken: 1004.00ms

    Time taken: 45.00ms

    Time taken: 45.00ms

    Time taken: 52.00ms

    Time taken: 52.00ms

    Time taken: 49.00ms

    Time taken: 49.00ms

    Time taken: 43.00ms

    Time taken: 52.00ms

    Time taken: 43.00ms

    Time taken: 47.00ms

    Time taken: 52.00ms

    Time taken: 49.00ms

    Time taken: 30480.00ms

    Time taken: 974.00ms

    Time taken: 1164.00ms

    Time taken: 1222.00ms

    Press any key to continue . . .

    @STL, is it faster than GCC implementation? Are all the related issues you mentioned in GoingNative resolved?

  • @STL, from feature-set point of view, whats lets of C++11 in VC world to be implemented? I am seeing most C++14's new features. Is 11 fully supported now (perhaps with the exception of few bugs)?a

  • 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.

    This is still an active bug assigned to me.

    Nathan: The Nov 2013 CTP lacks the following C++11 Core Language features: expression SFINAE, attributes (including those for data-dependency ordering), constexpr on member functions, char16_t/char32_t, Unicode string literals, universal character names in literals, user-defined literals, inline namespaces, unrestricted unions, conditional noexcept, thread_local, a C99-conformant preprocessor, and a partridge in a pear tree.

    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()).

  • m.högdahl> warning C4592: 'isqrt_helper': 'constexpr' call evaluation failed; function will be called at run-time

    The compiler team has confirmed that this warning is spurious - constexpr evaluation will succeed anyways. They're filing a bug to track this, thanks!

  • This (newly) fails to compile:

    #include <map>

    #include <vector>

    #include <memory>

    int main()


       std::map<int, std::vector<std::unique_ptr<int>>> blahs;


    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?

Page 2 of 4 (46 items) 1234