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.

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

  • STL:

    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.

    #include <iostream>

    struct A {

       int x;

    };

    struct B {

       double d;

       A a;

    };

    struct C {

       B b[10];

    };

    int main() {

       std::cout << sizeof(A::x) << '\n';

       std::cout << sizeof(A::x + 43) << '\n';

       std::cout << sizeof(B::a.x) << '\n';

       std::cout << sizeof(C::b[0]) << '\n';

    }

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

  • This CTP introduces more bugs than fixes and improvements. Sigh.

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

    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.

  • @STL Am I right in thinking the following should compile?

    struct A

    {

       int a1;

       int a2;

    };

    struct B

    {

       B(void) :a{ 0, 1 }{}

       A a;

    };

    int main()

    {

       B b;

       return 0;

    }

    Clang (on Windows) and GCC (on http://ideone.com/) seem to think it's ok. VS2013 and VS2013 CTP error on

    error C2661: 'A::A' : no overloaded function takes 2 arguments

  • Alastair: Yeah, that's tracked by an active bug, DevDiv#728401/Connect#792161: connect.microsoft.com/.../792161

  • @STL

    1) Could you please providing a hotfix for this(and only this), It has already been fixed for VS2015 but it realy needs to be done for VS2013:

    connect.microsoft.com/.../initializer-list-calls-object-destructor-twice

    2)There are questions about the constexpr in Nov CTP, i've posted at there for avoiding duplicated posts:

    blogs.msdn.com/.../c-11-14-core-language-features-in-vs-2013-and-the-nov-2013-ctp.aspx

  • I was hoping for a fuller implementation of thread_local this time around to help with porting of a legacy application.  Any news on when this will be complete?

  • @STL

    Has the <filesystem> behaviour changed from VS2012 to VS2013/2013CTP?

    It appears that where VS2012 std::tr2::sys::directory_iterator path().string() would return the filename only. The version in VS2013 returns the full path.

    I suspect the latter is more correct but as this has broken my code on porting to VS2013 I wanted to check.

    Is there a list of bug fixes for VS2013 and VS2013CTP online somewhere?

  • Simon Dan> Could you please providing a hotfix for this(and only this)

    I've already asked the compiler team to fix this in an Update, as it's silent bad codegen in a popular feature. I'll ping them again.

    > There are questions about the constexpr in Nov CTP, i've posted at there for avoiding duplicated posts:

    I've replied there.

    sjb> thread_local [...] Any news on when this will be complete?

    It's on the list, but other things are higher priority.

    Alastair> The version in VS2013 returns the full path.

    Yep, that was a bug fix.

    > Is there a list of bug fixes for VS2013 and VS2013CTP online somewhere?

    See blogs.msdn.com/.../c-11-14-stl-features-fixes-and-breaking-changes-in-vs-2013.aspx for a 99% exhaustive list of the STL fixes in 2013 RTM. I don't have a list of compiler fixes, sorry.

    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.

  • I mean that the code itself isn't good enough already, and triggering bugs are just another side effects. Even if there are never a bug waiting for any i still won't write my code in those ways.

  • I realise chances of this being read by anyone are slim... but are unicode string literals / char32_t CRT support, etc coming anytime soon?  Been waiting on these for almost 2 years now...

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

Page 3 of 4 (46 items) 1234