The Future of C++

Play The Future of C++

The Discussion

  • User profile image

    Definitly one of the most important sessions at build 2013, please make it a live webcast!

    Im really curious if Herb and the C++ Team can prevent an ISO-CPP-Conformance-shitstorm for Microsoft Wink. If you read the forums, blog comments and reddit on VS2012 cpp11 and so on, there will be no mercy^^.

    What's it worth to have "rapid release cycle" for highlevel tools if your fundamental building blocks are "years" behind. 


  • User profile image

    Just waiting!!
    Rock our world, Herb! Big Smile

  • User profile image

    @Eul3r: The "out of band compiler update"-debacle surely deserves a shitstorm…

  • User profile image

    I think the major Problem is Microsofts commitment to C++:

    1. This talk on the last day of build and the second last session on webcast.
    What does this mean: C++ is a 3rd class citizen, Management doesn't care.
    Microsoft is gonna be the next Yahoo, which are proud of their new weather app - thats harsh, but it has to hurt.
    .Net announced to improve on performance, first signs as Herb foretold, the industry has to change to meet the needs.
    The train is leaving with or without microsoft.

    2. Look at the small C++ Team, i mean the whole Standard Library - and it's growing fast - Management has this on the shoulders of a single dude STL(Stephan),
     he is doing an amazing job (in the comments, videos, STL, etc.).
    And where is his talk?!
    Where is a compiler dude to explain newest features and complier intrinsics?
    Where is a dude from the PPL and AMP libraries to announce,show examples and point to the right directions?

    I thought build is a Developer Event.
    The Information need and wants of an C/C++ Developer are totally different from .Net or what ever.
    C/C++ Developers think about stuff that their programmer friends don't even know exists.
    This is why Herb, STL,going native speakers, and all the others behind the scences are so much appreciated, stuff is getting watched over the web, too!
    If the c++ team is the foundation on which MS is built on, where are the Investments?!
    Which brings us to 3.

    3. Corporate vice president of the Developer Division at Microsoft on c++/c++11:
    "(this is also an area in which we plan to continue investing beyond this release)"

    And check out his channel9 interview with charles, there is a question on c++11 conformance - outch, you can feel the pain through the web.
    Management is totally not getting it. If they plan to invest,when will this investment actually happen,
     when will you experience the returns of investment? ...this will take years. Lets see... the next standard is
    around the corner, VS is then fully cpp11 complient in 2014, then next cpp14 standard is in vs in 2017,
     cpp17 then in VS 2020?! Stop throwing away Devices for free, INVEST in the C++ TEAM.

    4. This C++ talk should be day 2 keynote!!! Thats a appropriate setting for a first class citizen and the c++ renaissance at Microsoft. Well and look at the actual Day 2 Keynote - they show off a programm with OpenCV Lib, the dude has no clue. He is talking about showing of C Code, and well, what jumps first in the eye on the Code Screen, a std::vector<cv::Point2f>...haven't seen those in C for years^^ they must have templates now, too.
    You can do this in front of Web devs, .net dudes, marketing +management dudes and journalists but, please give the serious devs the appropriate room

  • User profile image

    You couldn't have said better! C9 should have a question rating capability! (y)
    I'm a C++ developer with 3 years of VC++ compiler use! In this small time, I  have come to the same conclusions, just by looking at, for instance, the C++11 conformance on VC++!
    The fact that Microsoft is a company that sells the compiler, exposes even more the problem with the delay in shipping a feature like C++11, and how much Microsoft cares about the C++!
    But I understand! The big guys on the company probably say things like these:
    "Forget about native C++! It's Herb business ( meaning, the Standards Committee )! Let's focus on Xbox, C# .Net and Windows 8!"
    Herb is doing an amazing job in the WG21, which is awesome, and it is what brings us to an inevitable question: What would be of native C++ on VC++ compiler if he wasn't at Microsoft? :O
    Makes me sad think about all of this!

  • User profile image

    @Herb: You mentioned that VC++ never had a AST - what did you use instead up to now?

  • User profile image


    That is easy to tell.

    When COM was being introduced on Windows back in the day, improving C++ extensions for COM support was more important than standards compliance.

    Then came .NET, improving Managed C++ and its sucessor C++/CLI were again more important than standards compliance.

    Eventually we got this C++ Renaissance discourse, but in the end improving C++ AMP extensions and C++/CX take precedence over standards compliance.

    From the outside, one gets the impression work on standards compliance is only done when tickets for extension related bugs are closed.

  • User profile image

    @Moondevil:Theres a fair amount of travel time between the COM, .NET and 'AMP' (not sure I'd really include that one) stations, during which Microsoft has done oodles of Standards work (not to mentioning ponying up cash and support for etc). The thing is Microsoft tends to release C++ features based on strategic platform direction and then customer priority, and sometimes in the latter case said priorities which are often horribly pragmatic and based in maintaining mature and valuable codebases, don't align with our desire for '100% Standards conformance now'. 

  • User profile image

    @Eul3r: exactly that's what makes me sad about them Sad

  • User profile image


    All compiler vendors provide language extensions, so I am not criticizing Microsoft doing language extensions.

    However, all the C and C++ compiler vendors with exception of Microsoft tend to follow standard first and then do whatever else fulfills their goals. At Microsoft the priorities are inverted, because standard code means it is easy to move the code to other platforms.

    I use Microsoft products since the MS-DOS 3.3 days, among many other vendors as well, so I am not just criticizing without experience.

  • User profile image
    Bryan St Amour

    Is GoingNative 2013 going to be live-streamed for those of us who cannot make in person, like GoingNative 2012 was?

  • User profile image

    It's a nice approach of Microsoft. Standardization transition such as this will definitely help students like me.

  • User profile image

    A road map is nice and fine but what else will you do to ensure quality, delivery cycles and the roadmap. There is nothing about your commitment toward c++ for customers to ensure your plans.

    - STL will stay the only one on microsofts side to ensure quality of the stl library, i mean wtf, thats gonna be a real mess soon.

    - Team will stay small ?! what to expect....customers gonna be disappointed again...

    + going native to show commitment

    According to the published road map i think it's safe to say that the Microsoft C++ Compiler is approximately 2-3 years, which equals 2-3 Visual Studio releases, behind the c++ Standard.
    If you don't need/want the new featueres yesterday, then you can save your money/efforts to convince your boss/finance dude to buy it. Maybe you need ppl/amp or great vectorization/performance support then the world looks differently. For educational purposes i would recommand gcc/mingw + clang.
    According to the comments on Herb's blog, they are hireing compiler devs. So they will improve slowly, i will place my bets on them for c++17 as a early adopter.
    So see you after the c++17 standard passed. And hello Mingw + Qt Creator.

    My feelings go with the people which bought vs2012, and thought they get full conformance via updates. I think this was a life time experience for everyone to check first via a test version like visual c++ express.

  • User profile image

    @MFH: The "out of band compiler update" was misunderstood. At GoingNative 2012 (Feb 2012), we announced that we were going to ship more conformance, and at that point the usual cadence was always every 2-3 years, and we wanted to make sure people knew this did not mean they'd have to wait 2-3 years to see more progress. So we emphasized that we were going to find ways to get conformance features out sooner, not waiting for 2-3 years to pass before shipping anything more, via out-of-band CTP and RTM releases. For OOB CTPs, we followed through on that by shipping an out-of-band CTP in Nov 2012 with variadic templates and other things. For OOB RTMs, it turn turned out that all of VS moved to a faster cycle and turned the crank in just one year, not stay with the old release band, so we didn't need to ship a separate VC++ RTM to escape the old band, but just snapped to VS. What I think happened was that people took the "out-of-band" comment in the GN Feb 2012 talk and then connected the dots to think it meant the VS Updates, which we didn't even know about at that time. The main thing is that we are serious about delivering conformance, weren't going to wait 2-3 years to do so no matter what the rest of VS was scheduled to do, and happily all of VS released faster so we snapped to that train for RTM while also additionally shipping a CTP as promised last November, and as announced yesterday we'll ship VS 2013 with more conformance this year, followed by another CTP with still more conformance soon after RTM.

    @Eul3r: Re 1: My talk was actually scheduled for first thing after keynotes on Wednesday, and was moved to Friday to get a slot in the live broadcast room – so it was moved to Friday because it was important, not because it was unimportant. Remember, the online live audience is even larger than the ~1000 people in the room, and the on-demand audience is far larger still but isn't available until a couple of days later. So the Build organizers felt that this would help the message reach the most people quickly. Re 2: Actually we've grown quite a bit. Several of the things you asked for are available in Channel 9 talks, Build talks (including Build 2012), and VC Blog posts by the folks who build the compiler and optimizer and libraries. Checkout Jim Radigan's talk from last Build (available online) for cool compiler back-end information; he's a wizard. Re 3: See Soma's followup post after the one you mentioned, which was entirely about VC++ conformance. Soma gets it, he's great. Re 4: Thanks! But remember Build is about Windows and Windows Phone – the OS platform – so I don't think one language should have a plenary session (not just keynote). Still, C++ got a key live broadcast slot and I hope you noticed a lot of C++ and native code mentioned throughout.

    @Bryan: Yes, the current plan is for GoingNative 2013 to be livestreamed, and for the sessions to be recorded and made available for free online, just like last year's. It's possible something may change, but that's the plan as of now.

    @Moondevil: One thing that's not visible externally is the feature "pipeline" and lead time. The features you mentioned were worked on 1-3 years before being released. The features you see announced yesterday have likewise been in the pipeline for a while. We try to keep it in mind, but sometimes we forget we're living in your future when we're talking about what we're enthusiastically working hard on right now and then you don't see it for a while until it becomes a shipping product.

    @weierstrass: (Aside: I love your handle! It reminds me of Statistics 333 at school -- the M-Test.) Actually STL and James McNellis are both working on the standard libraries, and we have added compiler devs so as to be able to do more implementation work in parallel. When you extrapolate, note that features on the right hand side of the roadmap are 'generally' smaller... however I agree that one thing this roadmap is going to let you do going forward is track our velocity as we deliver against the roadmap. I hope to have more data and details known and shareable at GoingNative in September.

  • User profile image

    From a technical standpoint I do not care much how a new version of VC++ is called, if it's shipped separately from VS or the way MS ships it. What counts is if I can actually use it. VS2010's support of C++11 was way behind, VS2012 was only a tiny little bit better and a huge disappointment; it was accompanied with "we will bring updates faster". So CTP came... which according to MS means Alpha quality and does not come with a go-live license. In one word: unusable. 3 "real" (but tiny) Updates that changed nothing (for C++11). Now we have VS 2013 Preview. This comes with a go-live license, so why is it a Preview? Is it ready or not? Why not call the Preview RTM and the RTM "Update 1"? If even MS doesn't think it's Release-quality, should I really bet my company on it? And the promised updates after RTM are again only CTP, those are not updates that any serious developer can use.

    MS' view: VS2012 -> Nov CTP -> VS2013Preview -> VS2013RTM -> VS2013CTP, that's awesomely fast.

    Developer's view: VS 2012 -> ... -> ... -> VS2013 -> ... Uh, no it's not. It's faster than before, but it's still not fast enough, it will be at least another year for full usable C++11-conformance, more likely 2 years.

    Alpha-Releases (CTP) and Beta-Releases (Preview) do not count, you should stop using them to fill out the roadmap.

  • User profile image

    We bought VS2012 because we were aware of the CTP and we thought it will be finalized soon. There was no other real value in upgrade for our company - in fact some things like UI got even worse. If we knew CTP will go to VS2013 we would skip VS2012 completely.

    What is the point of CTPs which get never finalized and you have to buy new version of the product? I know there is a value for MS because MS gets lot of testers for free. But to me it looks like a scam. I cannot recommend to invest in VS for any new project. I am seriously looking at clang + QtCreator environment.

  • User profile image


    Thanks for your reply - accepted. Nice talk, and can't wait for going native and c++14! Just awesome. I wonder if Bjarne is already preparing his next Editon of TCPL Wink.For the future, i hope you won't have to spend so much talk time on conformance again^^.

    PS: Where can i get the Visual C++ Team T-Shirts ("My compiler, compiles your compiler" or so), hehe.



  • User profile image

    I'm really glad we did not make the same mistake as Tomas. We might have bought 30+ licenses of VS Pro 2012 just to find out later that the CTP was not going to evolve into an update of VS 2012. Instead, we just bought one to have more time for evaluation. We knew by then that VS 2012 is worse than 2010 for us as it does not bring any real benefits for our C++/MFC development, but would incur license and transition costs.

    Generally, our biggest problems with Visual Studio are not missing standards compliance, though we would benefit greatly from features now scheduled at the end, e.g. user defined literals. In the past, we have struggled more with bugs not being fixed in the version of Visual Studio we were actually using. Instead, we needed to buy new licenses, adapt our code to make it compile with the new version, recompile all third party libs we are using, verify that everything works as before, etc. We have 10 million logical lines of code, so introduction of a new Visual Studio is a major undertaking. Therefore, we have used one, skipped the next one, used one and so on in the past.

    Let me give an example. Before VS 2012 was released, I reported a bug for VS 2010 where the debugger was unable to display stl container's contents under certain circumstances, sometimes displaying just question marks, in some cases crashing Visual Studio. The answer was that this particular bug has been fixed in VS 2012 and I was invited to verify this in the 2012 CTP available then. When I tried, I found the bug to be fixed, but instead of displaying question marks or crashing, the debugger would then hog one CPU for 2 or 3 minutes before displaying the container's content. I immediately reported this. i later verified with VS 2012 RTM and found the performance problem still existed. So instead of getting a bug fix for the VS version we are actually using, we were given an unusable fix in the next version. Luckily, as I can tell from my tests with Visual Studio 2013 Preview, the performance issue seems to be fixed now - so our proven pattern of taking only every other version of Visual Studio in production is confirmed.

    That said, new exciting C++1x stuff is always appreciated, but getting bugs fixed in the version of Visual Studio we are currently using and are forced to be using for some time until we are ready to upgrade are even more important.

  • User profile image

    Concerning the GoingNative 2013 conference, I really don't understand why someone from Apple is not invited to talk about Clang. Clang is Apple creation and one of the original architect of clang (Chris Lattner) or the present main owner of Clang code (Doug Gregor) should instead be invited to talk about Clang at GoingNative 2013. I am quite tired to see Chandler Carruth and somehow Google taking the credits that they don't deserve, it's just a matter of fairness.

    And by the way, you don't need Chandler Carruth to hear about some Clang news. You should better turn your attention to WWDC 2013 where everything in much details was announced.

  • User profile image

    Is it true that I would like to see some faster complience too, but I think they are doing a great job. As we all know changing something that builds all of your programs is very risky thing. And at least for my part I've tried other IDEs and more or less in a short time I come back to VS.

  • User profile image

    @Hakime: I agree, and we did -- I first invited Apple to talk about Clang for GN12, but they declined (my impression is that they have various policies about appearing at conferences that they have to follow) and they strongly recommended we invite Chandler instead. That's how I heard about Chandler, and how he came to give the Clang talk. I think he did a great job -- informative and entertaining.

  • User profile image

    @Debugini: I have also raised the Connect bug feedback issue internally and we are trying to improve the consistency of our responsiveness and communication there too. Thanks for reporting the bugs, we do appreciate it -- we have resolved many Connect bugs in this release (including some listed on VCblog in Stephan's post on Friday) and we'll continue trying to improve here. Sometimes the issue is as simple as a bug being marked unfixed meaning in a specific previous release when it actually has already been fixed subsequently; but we also want to keep improving the number of bugs actually fixed too.

  • User profile image

    C#'s await/async is compiler feature which rewrites method into special class-finite_state_machine. All method's local variables are automatically moved into fields of that class, and code of method is moved into special class method which depending on current state just jumps by switch into right await position ( ) . That is similar in something to stackless coroutines.

    In C++ stackless coroutines can be implemented just within 100 code lines, for example look to Boost.Asio. Of course syntax sugar is less sweet - local variables must be moved into class field by hands, but everything else is similar in shape and content. For instance state machine is generated automatically (with similar switch inside), by macros. (See talk by Christopher M. Kohlhoff , code example - ).

    Boost.Coroutine library provides stackful coroutines for C++ on wide range of platforms.
    Stackful coroutines are much more powerfull than stackless ones:

    Major advantage #1:

    Stackful coroutine allows to encapsulate all asynchronous logic inside components - in a such way, that client code would look EXACTLY SAME to SYNCHRONOUS code.
    For example, Python's gevent library does monkey patching of stadard sockets which automaticly turns all code that use them into "asyncronous", without any changes ( ).

    Another demo can be found at Boost.Coroutine: it has example of simple server which asynchronously reads data from tcp port and prints it on screen, and all this happens in one thread. Reading loop looks exactly same as "normal" blocking code:

    Result foo(TcpStream &client_stream)
        string msg;
            std::getline(client_stream, msg); // happens asynchronously
            cout << msg << endl;
        } while(msg != "exit");
        // ...
        return result;

    ALL asynchronous logic is hidden inside TcpStream. Inside of it, after calling asynchronous read, coroutine yields, and going to "sleep". When data would be available - coroutine would be awaken by appropriate completion handler.

    It is not possible to achieve same level (the highest, in fact) of encapsulation using stackless coroutine (or await/async) - asynchronous guts will stick out from the client code: foo would have to be "async" and getline will be called as "await":

    async Task<Result> foo(TcpStream client_stream)
        string msg;
            msg = await client_stream.getline();
        } while(msg != "exit");
        // ...
        return result;

    Well, that doesn't look like a big deal, but often there is not just one async method, but rather full chain of async methods.
    When your "foo" is called by "bar", which need result, then "bar" in general has two choices: convert itself to async and do await, or do blocking wait on Task's result.
    Moreover, when you have chain of method calls, like this:


    "async"-choice transitively infects all upper levels (until one of them decides to do blocking wait, or not need the result).

    While in case of stackful coroutines, any asynchronous specific code is only at the ends of chain: at the begin, where coroutine is started, and at the very bottom - at yield place.

    Advantage #2, Performance:

    When you have chained levels of awaits - special code is executed at each of them - one level awaits another, and so on. It is O(N).

    But in case of stackful coroutines, no matter how long chain you have - each level "implicitly" awaits the bottom one, that is O(1). Among other things this is extremely fast:

    Advantage #3, the Killer:

    Exactly same syntax of await can be emulated with help of Stackful Coroutines.
    I have made small proof-of-concept: :

    int bar(int i)
        // await is not limited by "one level" as in C#
        auto result = await async([i]{ return reschedule(), i*100; });
        return result + i*10;
    int foo(int i)
        cout << i << ":\tbegin" << endl;
        cout << await async([i]{ return reschedule(), i*10; }) << ":\tbody" << endl;
        cout << bar(i) << ":\tend" << endl;
        return i*1000;
    void async_user_handler()
        vector<future<int>> fs;
        // instead of `async` at function signature, `asynchronous` should be
        // used at the call place:
        for(auto i=0; i!=5; ++i)
            fs.push_back( asynchronous([i]{ return foo(i+1); }) );
        for(auto &&f : fs)
            cout << await f << ":\tafter end" << endl;

    await here takes std::future-like object with support of continuation attachment (e.g. .then), and "returns result" of future.
    At this example boost::async is used. But that approach can be extended to work with other futures, like PPL's task::then, etc.
    Output example:

    1:      begin
    2:      begin
    3:      begin
    4:      begin
    5:      begin
    20:     body
    10:     body
    30:     body
    110:    end
    1000:   after end
    50:     body
    220:    end
    2000:   after end
    550:    end
    40:     body
    330:    end
    3000:   after end
    440:    end
    4000:   after end
    5000:   after end

  • User profile image

    I do not understand the reason for async and await.
    If they are blocking or take a long time than good programmer practices say they should be in a (background) thread. That is, do not call it from a ui thread.

    So why is this async/await feature needed?
    Your code examples do not help.

    Can you explain it in some other way?

    Do you only want this feature so you can port more easily c# code to c++ without a rewrite?

    If the read function is used in a ui thread it will sooner or later need to block anyway.
    ui thread:
    1. call read
    2. do other stuff
    3. now i need the result of read (blocking/waiting)

    If you use .then in your code it is a sign that you are doing it wrong. Eg calling the function in the ui thread.

    Using .then is over-complicating simple code.
    What is this obsession about blocking? You cannot avoid it.
    What is wrong with writing the read function without async/await and ppl? Just put it in a background thread. Then it can block however much it wants. When work is done in the background thread it can be sent somehow (or notify the caller that the data is ready for use) to the part that needs the result. If the ui needs it, if not it can be done seamlessly in the same background thread, no waste of slow os resources like locks, waits, and so on.

    executed in thread 1:
    file_sizes( string file1, string file2 ) __async {
    task<file> f1 = open(file1), <thread 2>
    f2 = open(file2); <thread 3>
    return (__await f1).size() + <waiting wasting thread 1>
    (__await f2).size(); <waiting wasting thread 1>
    Overuse of slow memory wasting threads, cpu time (including scheduling of the operating system AND ppl or whatever library/technique used to control threads)
    Resulting in double scheduling (by the OS and the library).

    Compared to:
    executed in a <worker> thread 1:
    file_sizes( string file1, string file2 ) {
    file f1 = open(file1),
    f2 = open(file2);
    return f1.size() +
    Result of file_sizes is used by the calling function in the worker thread.
    No mess, no wasted cpu time for double scheduling, no fuzz, no painful debugging sessions if the code is buggy.

  • User profile image


    1. Regarding your first example "executed in thread 1:":    asynchronous file operations does not have to be executed in new threads, refer "overlapped I/O".

    2. Regarding your second example "executed in a <worker> thread":    it opens files sequentially, doubling latency.

    3. Imagine that you need to write tcp proxy server, that should handle many connections (let say 10k) simultaneously. How logic loop which reads data from one socket and sends it to another would look in your code?
    Using some approach based on coroutine-like stuff (async+await, etc) - code would look very clear, structurally similar to simple synchronous versions.


Add Your 2 Cents