A nice talk by Mads Torgersen just went live on Channel 9 about C#’s non-blocking Task<T>.ContinueWith() library feature and await language feature, which are a big hit in C# (and Visual Basic) for writing highly concurrent code that looks pretty much just like sequential code. Mads is one of the designers of await.
If you’re a C++ programmer, you may be interested in this because I’ve worked to have these very features be offered as proposals for ISO C++, just with a few naming tweaks like renaming Task<T>.ContinueWith() to std::future<T>::then(). They were initially presented at the recent Kona meeting in February, and we’ll dig deeper next month at the special ISO C++ study group meeting on concurrency and parallelism.
Here’s the talk link and abstract:
Language Support for Asynchronous Programming
Mads Torgersen
Asynchronous programming is what the doctor usually orders for unresponsive client apps and for services with thread-scaling issues. This usually means a bleak departure from the imperative programming constructs we know and love into a spaghetti hell of callbacks and signups. C# and VB are putting an end to that, reinstating all your tried-and-true control structures on top of a future-based model of asynchrony.
While we were chatting after the talk, I managed to gently twist Mads’ arm and he has graciously agreed to come to the May 7-9 ISO C++ parallelism study group special meeting to present this to the committee members in detail and answer questions about await’s design and C# users’ experience with it in production code, which will help the committee decide whether or not this is something they want to pursue for ISO C++.
I hope you enjoy the talk. While at Lang.NEXT, I also participated in a panel and gave a C++ talk but those sessions aren’t live yet; I’ll post links once they are.
Trivia: If you noticed the Romanian accent in the first question from the audience, it’s because it came from Andrei Alexandrescu, who was sitting beside Walter Bright, both of whom were two of the other speakers at the conference. It was fun to be in a room full of language designers and implementers sharing notes about each other’s languages and experience.
Sutter’s Mill 
@MichaelTK The next C++ is not in expected in eight years but in five. C++17. Before that we will get library changes as TR’s whenever they are ready.
@Jon It’s non-standard of course, but boost::any provides a variant type, and type inference is supported in C++11 through the new semantics of the ‘auto’ keyword.
> C++ a dead-declared language? By self-appointed gurus, I assume.
Well if you don’t think C++03 is a dead declared language, then you will probably standing there alone with a small fraction of developers… A language is not kept alive by existing codebases. Just because people use it, this doesn’t necessarily mean a language is alive, unless you declare it to be ;). C++11 was a great step forward, but I think it was way too late… And the outlooks for the next iteration of the standard do not seem to be anywhere near that revolutionary. If you now take into account that a new standard needs at least 5 years to spread around… The iteration cycle is too long and except for C++11 far too conservative, period. I know the committee is voluntary but unfortunately this cannot be taken into account when judging about the language itself. The next iterations must be at least as impressive as C++11 and hopefully with a shorter cycle than 8 years. 8 years, common, this is like a life-time in todays pace of the digital evolution (which is only getting exponentially faster). I even doubt that the voluntary standard committee will be able to act fast enough to accompany for the fast growing nature of software development. Some companies like Google/Apple/Microsoft who each work on good compilers, should work together and actually invest money in the standard and not only in compilers…
> The GoingNative conference was great and the talks were all fantastic. C++11 is similarly great and full of great features.
Yes it is… Would have been better if we could call it C++06…
@MichealTK
XP is old. XP is crap. I wish XP were dead. But it isn’t. That’s the unfortunate truth.
What it comes down to is the blatant fact that Microsoft has yet to convince us that removing XP support was purely a technical decision. As seen from the workarounds available at http://tedwvc.wordpress.com, VS11 binaries *can* run on XP, albeit in a rather hacky/ugly manner. From the looks of it, it feels as if the entire decision was made by folks high up in the food chain just for the sake of dumping XP.
On one hand, Microsoft is actively pushing the C++. The GoingNative conference was great and the talks were all fantastic. C++11 is similarly great and full of great features.
On the other hand, Microsoft is pushing C++11 far into the future for many of us developers. We would love to use the ranged based for loop, atomics, improved lambdas, and all that, but we can’t dump 30% of our customers. It is just not realistic.
In addition, it is simply wrong for Microsoft to put such a burden on 3rd party developers. Had Microsoft started with Office, Windows Live, etc. (yes, I’m aware that IE9 doesn’t run on XP), we wouldn’t need to be having this discussion at all.
Microsoft, do the Right Thing.
@ MichaelTK: C++ a dead-declared language? By self-appointed gurus, I assume.
Personally, I care more about portability that standard this or that. Boost or OpenMP works on many platforms, as do OpenGL.
As a result, I’ve always stayed away from DirectX, but it’s interoperability with C++ AMP makes it very interesting. I’m eagerly considering rewriting the graphics part to take advantage of that combination.
What is all this Windows XP begging for? XP is dead. If your customers still use XP, so be it. Then they can’t upgrade to your latest software or you can’t upgrade to latest VS. So what, you were fine all the years before without VS11 what would you need it for just now? Obviously it can’t be new features since they are mostly not XP compatible as well. It can’t be C++11 support, since Intel Compiler 12.1 already does support a lot of it in Visual Studio 2010 (more than even VS11 supports as it is now). See it the other way. If Everyone endlessly supports XP, they it will never die. Backwards compat. is one of the biggest problems in software development and continually holding innovation back; without any obvious reason, all except some lazy people who think that using an 11 year old OS makes them cool ;)… Whenever I tried to use XP (in a Virtual Machine of course), it felt like medieval ages.
Herb, I will love you until the day I die if VS11 RTM will support XP :-)
“he has graciously agreed to come to the May 7-9 ISO C++ parallelism study group special meeting to present this to the committee members in detail and answer questions about await’s design and C# users’ experience with it in production code”
C# async has yet to ship, of course. If you want experience reports about production code you might look at F#, which is where C# is getting the feature from and shipped with it in VS2010. Before that, apps with 100k users used the same feature in OCaml (which is where F# got the feature from).
“There are several powerful ideas in other languages that could transfer well to C++, would improve rather than bloat the language, and aren’t in tension with “don’t pay for what you don’t use” performance, just like auto and lambdas and other features.”
You might also consider variant types, pattern matching and type inference.
PS: C++.AMP is a step in the right direction regarding parallel patterns, but unfortunately not in the ISO standard. If I were at the committee I would rather see to get a decent evolution of C++.AMP into the next C++ ISO standard… Herb was also talking about C++.AMP and distribution across clusters and heterogeneous computation environments. This is definitely nice to have but again, it must be done fast to be ahead of other languages and especially it needs to be in the standard.
> It would seem many major features that are now being zealously laid out in formal papers are feasible for C++2x at best?
This would be a hazard. I doubt that C++11 can cover for that long, since actually it has been due for 10 years already! C++11 is nothing new, it was the revival of a otherwise dead-declared language…
What about taking complexity out of the language for making advancements easier while still allowing interaction with existing code. This could be implemented by a “safe” and “unsafe” modifier respectively for methods and classes. If the compiler defaults to “safe” then only “unsafe” is recognized and vice versa. In “safe” function one could only use the shiny new syntax which could also break backwards compatibility and in unsafe code, all C++11 features are available.
The only reason why people would use C++11 as it is in 10 years is because of existing code bases. So C++ itself is in a good position to die how it has begun. That is, by introducing a new C++ derivative on top of C++, call it “c++#” or whatever, which allows full backward compatibility on demand but by default brings ALL the fancies, that are urgently needed, to the C++ world.
The current C++ focused cluster and high performance revival will fade out rather sooner than later. Embedded devices evolve at incredible pace, and thus I hardly see use for C++ in this segment in the mid/long-term. For clusters, other languages and frameworks like Stanfords PPL or things like “Satin”, already provide great performance while still hiding all the low level complexity behind a compiler.
So please, don’t bother us with C++2x thoughts. As much as I like C++, if I see all the shiny new languages with their great ideas and concepts, and the complexity parallelism brings on the table, C++ must not evolve, C++ must revolutionize if it wants to survive!
Raw sequential performance doesn’t cut it, if it is too complicated to efficiently work in a heterogeneous parallel environment (20% more sequential performance but 50% less grid utilization won’t get you that far). What we need is efficient parallel patterns one can apply in a productive way. Only this paired with C++ sequential performance is a benefit in contrast to other languages.
Going over to look at N3327 and N3228, and also seeing the long list of formal proposals (already) for the next standard, I’m reminded of your earlier comment, Herb, that we could only expect one major new feature in the next standard. I would think “await” and related functionality would qualify as a major new feature. You’re pretty gung-ho about it, and with good cause. It would seem many major features that are now being zealously laid out in formal papers are feasible for C++2x at best? It is an arduous, grinding task you are engaged in on the Committee. :-)
After my last comment, I realized there was a higher resolution video available, besides the illegible default resolution. The higher resolution is legible, although not comfortable to read. Still, legible is legible, meaning the information can be had if one selects the highest resolution and sits close to the screen. I still think the rest of my comment applies and suggests desirable improvements.
The subject of the channel 9 video is interesting, but, unfortunately, the text on the screen is almost completely illegible. All you get from that almost-big-enough-to-read overhead screen is a general “sense” of what the speaker is doing. Everything else has to be gotten through carefully listening to every word the speaker says. Little content would be lost if it was a mere audio broadcast. Unfortunately, he isn’t speaking like he’s on radio, but as though he expects the viewer can see everything he sees, which means crucial information is *lost* in transmission.
It would be a good idea if these broadcasts had two simultaneous views the viewer could toggle between — or even watch side-by-side — one a broad view of the speaker, the other a direct transmission of the computer screen he is projecting to his audience. That wouldn’t be significantly any more difficult than what you’re already doing — it just needs to be set up that way.
Several years ago, I used to watch Sun Microsystems (the late) presentations that were much more sophisticated, having all sorts of related “resources” that could be accessed simultaneously while watching the central presentation. Having something like that would be even better than having two screen views. But, as it is, not even being able to read code that is in plain view — but not legible — is frustrating. Instinctively, I find myself squinting, like I need glasses, even though I know it isn’t going to help a bit. :-)
What we really want is XP SP3 support in Visual Studio 11. I think it is far more important than await. We can live without await. We (or at least many of us) can’t live without our XP customers.
It is unacceptable that no comment has been made on this so far. And hiding the XP support idea from the UserVoice “Hot” list is just plain sad.
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2287078-allow-mfc-11-to-run-in-xp-sp3
The sounds good. I wish we could get “then” on some fast track so we don’t have to wait years for it. I could use it now.
@Herb: If we are talking about pulling from other languages… What about the following:
1) Mixin templates from D
2) Transitive const & immutability for data and functions
3) “Pure” modifier for functions
4) GC classes from C++.CLI (that is, a new modifier for struct/class which restricts pointer manipulation without! introducing a new pointer/allocation syntax and in turn allows for safe&generational GC. I know your other post about GCs here but I don’t think shared_ptr is the way to go. Its is very hard to get right&efficient and inherently error prone. So a real safe, reliable GC would do the job for most of the time…)
5) Named parameters
6) Anonymous types like “new { x = ‘Hello World!’, y = 23 }”
7) Reflection, possibly based on compiler AST like the ones coming with Roslyn
8) Infix methods from Scala
9) Infinitely more ;)
Yes, it’s N3327 and N3228.
BTW, C# isn’t the only language I’m personally actively trying to get ISO C++ to pull from — I also solicited a proposal from Andrei and Walter proposing D “static if” for C++ and they too graciously agreed to write it up. There are several powerful ideas in other languages that could transfer well to C++, would improve rather than bloat the language, and aren’t in tension with “don’t pay for what you don’t use” performance, just like auto and lambdas and other features.
Tom: take a look at N3327 and N3328 from http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/ – I’ve only skimmed through those two papers but they both contain .then() on std::future.
Maybe something like this ?
http://research.microsoft.com/apps/pubs/default.aspx?id=158164
Interesting post Herb, would it be possible to read the actual text of the proposal you made to add ‘then’ to ‘future’ ?
Kind regards,
Tom