Herb Sutter

@Matthew: True and new in C++11 (and C11 and Java), but nothing to worry about because you'll likely never encounter a processor that can't do single-byte loads and stores.

@Matthias: The memory model says that compilers/processors/caches can't transform potentially infinite loops into non-infinite loops.

@Stephan, quick responses:

• The stop=true; can't be relaxed because otherwise it could float up across the launch (annoying but mostly benign, just causing workers to always immediately stop) or down across the join (oops, program will never terminate).
• The exchange_explicit can't be relaxed because for example part of "new widget" could float up speculatively out of the if.
• Yes, VS 2012 atomic code gen is very pessimized for x86/x64; we're fixing it. ARMv7 code gen is already pretty good, modulo ARMv7's own limitations described in the talk.

@bcosta wrote: "Is it strictly necessary that acquire/release "come in a pairs"? I have heard this a few times. As an example, a single thread that uses a store/release to publish some data where multiple other threads that use a load/acquire to read that data. This is permitted right? I.e. One release can be "viewed" by many acquires or does it need to be strictly one-to-one?"

That's fine, it's just many loads pairing with the same store... by "they have to come in pairs" we mean you get the ordering guarantees only when a specific load-acquire sees a specific store-release, and is guaranteed to see everything else the storing thread did before the store-release. That's one "pair." The same store-release could be observed by multiple load-acquires, pairing with each one.

@KMNY_a_ha: Thanks for being reasonable, I appreciate it.

Off-topic: BTW, I've wondered for a while -- is your handle intended to be KMKY_a_ha (K instead of N)? But I agree N makes it more pronounceable and still gives the Abba reference.

@KMNY_a_ha: I'm sorry you're upset that we're behind on C++11. We don't like being behind either, and we know where gcc and Clang are (I use them regularly).

I also know we have constraints gcc and Clang don't -- such as supporting several first-party OS platforms (which means a once-in-a-decade event like Windows 8 taking over a big chunk of the VC++ product team capacity for two years), several first-party app products like Office and SQL Server (that would be among the world's largest ISVs if they were separate companies), and making sure C++ supports many extra features in one of the world's richest and most complex IDEs (which some will view as 'a waste' if they don't use Intellisense, debugger expression evaluation, static analysis, etc., and some people don't, but the reality is we have to support all that reasonably well and people still want things we don't do like basic refactoring). Besides those obvious taxes, there are many technical constraints that aren't appropriate to talk about publicly, but I'll note they're not the ones people keep guessing at.

Gcc and Clang are great compilers, and I personally made sure we gave Clang in particular airtime at GoingNative (thanks again Chandler for the great talk!). They also have smaller ecosystems they have to support directly and thus fewer constraints, or at least different constraints. I may wish I worked on a project without constraints, but I don't have that luxury. So I can either quit the team and gripe about their constraints, or be part of the solution and try to help improve issues ranging from engineering to organizational. I prefer the latter as more productive.

Re message and renaissance:

I don't think I've changed what I've said: C++ has indeed had, and is having, a major renaissance at Microsoft and across the industry.

Inside Microsoft, for starters all the new stuff in Windows 8 is based on a C++ COM-based API, not .NET code as Longhorn (pre-Vista) tried to do. At Build, which you mention, we had far more C++ content than at any PDC (the conference Build replaced) for over a decade, to the point where we had to bend over backwards to ensure .NET developers didn't think they were being abandoned (they weren't). In Visual C++, we probably shipped more feature work in this release than in any previous release I can remember, including ARM targeting, auto-parallelizing and -vectorizing, C++ AMP, C++/CX, a full C++11 stdlib, and other things.

Outside Microsoft, we have C++11 (first new standard features in 13 years), the Standard C++ Foundation (first ever), isocpp.org (first ever), the huge investment by the industry's biggest players in a brand new C++ compiler (Clang, first reusable OSS C++ compiler ever -- gcc is deliberately nonreusable), more C++ conferences and conference content than we've seen in years, all the C++ consultants I know booked out like they haven't been for years, and more.

So I see the renaissance ongoing everywhere. That's what I see, anyway, so I say it.

Re education and bio:

You should be able to find it, the academic and job summary are posted on isocpp.org and probably other places. BMath CS Hon Co-op, UWaterloo, 1989 -- CS/Info is an honors CS degree (a 4-year degree that actually takes 5 because of co-op interleaving, and I strongly recommend co-op for real-world experience) with heavy math and business -- a credit or two shy in each of the latter two from being a CS-math-bus triple major, nearly no electives. BTW, it looks like I'll be back at my alma mater in February to give an invited talk, anyone who's in the area and interested should check out the UW announcements.

But really the paper/lettering doesn't matter much after getting your first job or two -- that's when it matters to give prospective employers an idea of what you might be able to do. But after the first job or two, too many people sit on their academic credentials when what really matters then is the design and engineering quality they produced in the real world, and the people they worked with who know their skills and can say so.

FWIW, some of the world's best C++ compiler implementers I know and whose programming skills put me to shame, who work at multiple top companies you'd recognize, never formally went past high school. (It's rare, but it happens -- it just means more of the responsibility is on the person to be a self-starter and proactive about ongoing learning, with less help to discover the things they need to learn.) That includes at least one highly respected 20-year veteran of the ISO C++ standards committee, still very active and prominent in a room filled with a fair number of PhD's, and we're glad we have him.

Just noticed Fernando posted the same question here as on my blog... pasting the answer here too:

@Fernando: You asked why not just write w.then(x+y+z) instead of w.then(x).then(y).then(z). Two reasons: 1. Writing w.then(x+y+z) burns/occupies a thread while waiting for y and z, while w.then(x).then(y).then(z) does not. 2. An important key is composability: The different .then() calls may be in different code, such as one function doing w.then(x) and returning the future, the separately authored caller tacking on .then(y) and storing it on the heap for multiple threads to observe, and then a helper thread authored by still someone else tacking on .then(z).

See http://isocpp.org/get-started for some links, including to the Elements of Modern C++ Style "highlights" page on my blog.

@KMNY_a_ha: Usually I just disagree with your points, but this one's a little much:

The point is that he talks all the time about C++, yet he does nothing or almost nothing (at least the effects suggest it) to put C++ into leading position - see the state of VS's C++ compiler. And that's the whole gripe I have with Mr Sutter. Lots of talk, zero action or worse, lots of actions suggesting that Mr Sutter plays on the .NET side.

You should check out the November 2012 CTP. It added a bunch of additional C++11 features, two months after shipping VC++ 2012.

I think the .NET team would find the last line pretty funny.

Re task and data parallelism: We announce the "preliminary" talk descriptions months before the actual C&B event, and we make changes as we firm up the content. For C&B 2012 I had too much material for other talks and so the parallelism part got cut. Charles grabbed the original draft description and I've asked him to update the description -- basically remove the 'parallelism' bullet.

That said, there's a lot of interesting stuff to be said about C++ parallelism too, so I may well cover that parallelism topic at C&B 2013 (unless it gets preempted by something even more current and cool). The dates for that event have been announced for December 8-11, and the location will likely be announced soon -- just follow cppandbeyond.com if you're interested.