Anthony Williams has posted an excellent summary of the two major language design questions going into next month’s ISO C++ meeting in Batavia, IL, USA.
As we wind down C++0x, we are still working on an ever-decreasing set of open issues. Unsurprisingly, they’re in the newest features, as we bake them and see how they integrate with the rest of the standard.
At C++ and Beyond next week (and in December) I’ll also be giving a brand-new half-day talk on Elements of Design.
I’m passionate about design, in part because it requires specific skills and taste, but most off all because it’s so important for every programmer — whether building a new library or extending one, building a new class or maintaining one, and that covers pretty much all of us.
In recent years, I’ve been spending a lot of my time leading design work in diverse areas ranging from general- and special-purpose library design, to systems software architecture, to programming language design and evolution, including participating in the crafting of various C++0x language and library features.
Although those areas are pretty diverse, they also have a lot of commonalities, and the insights and learnings apply directly to mainstream classes-and-libraries production software design. I’ve organized the topics to cover proven design practices at three levels:
We’ll build these areas from the bottom up — first key elements as the foundation, then the principles that unify the elements, and finally the process that enables staying true to the principles. Each process, principle, and practice is illustrated using real-world examples drawn from personal experience in many different design areas, but always targets “how you can use this today”: concrete skills and techniques for the development of well-designed production software and applications.
I’m looking forward very much to this topic in particular, not only in this talk itself but also in the informal and unstructured fireside time built into the C++ and Beyond schedule. Together with my other new talk on Lambdas, Lambdas Everywhere, my part of C++ and Beyond will be 100% new material never seen in public before — 270 minutes’ worth (whew). I look forward to seeing many of you there next week, or at the December “Encore” event where registration opened two weeks ago.
Herb
We’ll be posting abstracts (summaries) of the C++ and Beyond 2010 sessions over the coming days over at the C&B site. Below is the first, for my talk on “Lambdas, Lambdas Everywhere.”
This is a brand new talk. I delivered a ‘sneak peek’ preview of a subset of this material in conjunction with the ISO C++ standards meeting in Switzerland two months ago, but the full talk will be given publicly for the first time at C++ and Beyond.
Historical trivia: This talk exists because Bjarne Stroustrup asked for it. Bjarne knew that I felt lambda functions were a game-changing feature that would have a pervasive impact on C++ coding style across many domains, and he asked me to write up the examples demonstrating why. This talk is the result.
Here’s the abstract:
Why care about C++0x lambda functions? Syntactically, they are nothing but sugar for function objects. However, they are an essential and enabling sugar that will change the way we will write C++ code more often than most people realize.
This talk will cover what lambda functions are and how to use them effectively, including how lambdas touch many wide-ranging kinds of code — from their convenience when writing concurrent and scalably parallel code, to how they stand to revolutionize STL usability and programming, to how they enable such small conveniences as local functions and local variable initialization.
Note that lambda functions, although futuristic, are not a far-future feature. They are available today in several shipping C++ compilers, including Intel C++ 11, Microsoft Visual Studio 2010, and gcc 4.5. The future is now. Come find out how this powerful feature affects you and your code.
About the speaker: Herb Sutter is an architect on the Windows C++ team at Microsoft and the chair of the ISO C++ standards committee. He is the main designer of lambda functions in Visual C++ 2010 and their integration with the VC++ Parallel Patterns Library, and is partly responsible for the design of lambda functions in the C++0x standard, notably their final syntax.
Public registration is now open for the overflow “Encore” showing of C++ and Beyond. The deadline for early-bird discount registration is November 14, but if you want to make sure you get a place it would probably be good to register sooner (the first showing sold out during the early-bird period).
If you weren’t able to get into the first one before it sold out, here is a second chance to attend the same event with the same speakers; the same location; and the same solid technical program on C++ and directly related technologies, including many new and up-to-the-minute-current talks that have never before been presented publicly anywhere else. The only thing that’s different is the date: C++ and Beyond Encore runs from December 13 (evening) through 16, 2010.
The talk schedule with titles and speakers is available at the Location and Schedule page. The topics are designed to provide a balance of useful and pragmatic material, ranging from broadly applicable design techniques to hard-core deep dives on specific important language features. The program includes substantial coverage of:
We look forward to seeing many of you in the beautiful Pacific Northwest later this year!
Watch the C++ and Beyond site and RSS feed for further announcements, including detailed talk abstracts to be posted soon.
Updated 10/22 to remove the deferred GotW-0x talk.
Demand for C++ and Beyond has been exceptionally strong, and so Scott, Andrei and I have got together and scheduled a second “encore” event on December 13-16. It will be identical to the October event: same format, same talks, same location, just making the event available to a new set of 60 people who weren’t able to get into the first one.
See the C&B Encore announcement for details. Registration for C&B Encore will go live soon, as will the finalized list of talks each of us will be presenting. Watch the C++ and Beyond site and RSS feed for announcements.
Today, John Gruber wrote about Internet Explorer 9:
The new UI removes most of the junk from the UI. Kind of interesting how web browsers have evolved to expose fewer UI elements. Most apps go the other way over time.
Of course, that’s because the page/site is the real app. And like most apps they are indeed going the other way.
The browser is not really an app; it’s a shell, like the OS shell, just a runtime necessity to run the real app and provide some convenience housekeeping tools. Shells generally try to remove clutter (though admittedly this goes in waves) because they know they’re not the main attraction.
You can download the just-released Internet Explorer 9 beta here.
The summer 2010 ISO C++ meeting was held on August 2-7 in Rapperswil, Switzerland. The post-meeting mailing is now live, including meeting minutes and other information.
In March (trip report), we voted the last set of feature changes into a Final Committee Draft (FCD) and, after two weeks of scurrying to apply the changes, the result was balloted among ISO national bodies from Mar 27 through Jul 27. That means we received the ballot results and ~250 pages of comments just in time for the start of this meeting, and have busied ourselves with starting to process them.
For this and the next couple of meetings (Batavia IL in November, and Madrid in March), the committee is doing ballot resolution and dealing with national body comments. Because we issued a Final Committee Draft, ISO C++0x can officially no longer add new features. All that we can do is address national body comments, and make any other bug fixes we find.
The good news is that comment volume and content is considerably lighter than the comments on the CD ballot, and we expect to be able to finish handling all of them in two more meetings and, barring any surprises, vote on the Final Draft International Standard (FDIS) for C++0x standard after the Madrid meeting in March. If that happens and that ballot succeeds, the C++0x standard will be published in 2011 and we can start truthfully calling it C++11 and stop pretending about the ‘0’.
Low probability contingency: If between now and Madrid something unforeseen arises and we feel the standard is not in good enough shape to ship and needs more work, the fallback route would be to instead issue a second Final Committee Draft (FCD), which adds another comment cycle and another year to the overall process. We hope that won’t be necessary.
In Rapperswil, the Core, Library, and Concurrency subgroups spent the week triaging the comments and beginning to resolve the biggest or most potentially controversial questions first.
We accomplished a lot. Here are the key decisions, some of them tentative:
Attributes: alignment, noreturn, and virtual control. My biggest (but not only) beef with C++0x [[attributes]] is that the standard itself was abusing attributes as disguised [[keywords]]. Attributes are acceptable as pure annotations, but they should have no semantic effect on the program. The problem was that some C++0x attributes did have such an effect, notably the virtual control attributes, so I’ll start with those.
My personal hot button for this meeting was that C++0x not look like the following example, which is taken almost verbatim out of the FCD ballot draft. The semantics are excellent and desirable, but the syntax is clearly not what anyone would design in a fresh programming language:
class [[base_check]] Derived : public Base {
public:
virtual void f [[override]] ();
virtual double g [[final]] ( int );
virtual void h [[hiding]] ();
};
The road to the above was paved with good intentions. But it’s a clear example of adding language keywords dressed in attributes’ clothing, and not something I want to be responsible for forcing three million C++ developers to live with until the end of time.
Fortunately, the committee has tentatively agreed and decided to pursue replacing these attributes with keywords. For the next meeting, I and several other experts volunteered to write a concrete change proposal paper on this, and will include a description of two categories of options:
This week’s straw poll sentiment favored fully reserved keywords over contextual keywords, but both had stronger support than attributes.
The other two kinds of attributes that we considered changing to keywords were [[align]] to specify the alignment of a type, and [[noreturn]] to specify that a function never return. We decided to pursue changing [[align]] to a keyword, and leaving [[noreturn]] alone.
noexcept, part 1: Destructors noexcept by default. This is a tentative resolution to be written up and voted on at the next or following meeting. To me, this is an important achievement, because we have always taught people never to throw from destructors (see Exceptional C++ Item 16, subtitled “Destructors That Throw and Why They’re Evil”) and now the language will enforce that at least by default.
Background: Why are throwing destructor bad? Because any type with a destructor that could throw is inherently unsafe to use nearly all the time. Any type whose destructor could throw is already banned from use with the standard library (i.e., can’t be put in a container or passed to an algorithm), cannot be reliably used as a class data member (because if while constructing the containing object another class data member throws an exception, and then as the destructors of the already-constructed members are called this member’s destructor throws an exception, the can’t-have-two-active-exceptions rule kicks in and the program terminates immediately), and cannot even be reliably used as an array (because if while constructing the array one constructor throws an exception, and then as we call the destructors of the already-constructed objects one of those throws an exception, the can’t-have-two-active-exceptions rule kicks in and the program terminates immediately).
We acknowledged that this change will break some code by making it call terminate. We (not quite unanimously) agreed that such code not only deserves to be broken, but in fact is already broken in a less obvious way; for some examples, see GotW #47. Granted, we know that a small but steady trickle of developers have regularly tried to be clever, claiming they have legitimate uses for a throwing destructor. I’ve seen a number of such claims, and they’ve always turned out to be bad, unsafe code. This change will do the world a favor by making such code terminate deterministically at test time the first time you try to execute it.
If someone really truly feels they are an exception, that’s fine, they are allowed to write “noexcept(false)” on their destructor. Personally, though, I’d recommend that companies consider automatically rejecting attempts to check in any C++ source file containing that string.
no except, part 2: noexcept will be applied to the standard library. This also is important. At our previous meeting, we voted noexcept into the language (and deprecated exception specifications) but didn’t yet have time to apply noexcept to the standard library (which was still using exception specifications, and it’s odd for the standard to keep using a deprecated feature). That will now be done.
First, all empty exception specifications (which is all of them), currently spelled “throw()”, will be replaced with “noexcept”.
Second, all standard library functions whose description include “Throws: Nothing” will be changed to “noexcept”. This is an even bigger improvement, because it changes normative documentation/commentary into actual normative code.
Third, an analysis will be done of all move constructors used in the standard library, and we’ll see if all of those can also be changed to “noexcept”. That analysis will be reviewed at a future meeting and a course of action on this decided there.
noexcept, part 3: terminate stays. It was reaffirmed that if you violate a noexcept specification, your program will call std::terminate and not continue execution in what would be a corrupt state. Stack unwinding is not required.
Finally, here are the scheduled dates and locations for the next few ISO C++ standards committee meetings:
Herb
This month’s Effective Concurrency column, “Prefer Using Futures or Callbacks to Communicate Asynchronous Results,” is now live on DDJ’s website.
From the article:
This time, we’ll answer the following questions: How should we express return values and out parameters from an asynchronous function, including an active object method? How should we give back multiple partial results, such as partial computations or even just “percent done” progress information? Which mechanisms are suited to callers that want to “pull” results, as opposed to having the callee “push” the results back proactively? And how can “pull” be converted to “push” when we need it? Let’s dig in…
I hope you enjoy it. Finally, here are links to previous Effective Concurrency columns:
1 The Pillars of Concurrency (Aug 2007)
2 How Much Scalability Do You Have or Need? (Sep 2007)
3 Use Critical Sections (Preferably Locks) to Eliminate Races (Oct 2007)
4 Apply Critical Sections Consistently (Nov 2007)
5 Avoid Calling Unknown Code While Inside a Critical Section (Dec 2007)
6 Use Lock Hierarchies to Avoid Deadlock (Jan 2008)
7 Break Amdahl’s Law! (Feb 2008)
8 Going Superlinear (Mar 2008)
9 Super Linearity and the Bigger Machine (Apr 2008)
10 Interrupt Politely (May 2008)
11 Maximize Locality, Minimize Contention (Jun 2008)
12 Choose Concurrency-Friendly Data Structures (Jul 2008)
13 The Many Faces of Deadlock (Aug 2008)
14 Lock-Free Code: A False Sense of Security (Sep 2008)
15 Writing Lock-Free Code: A Corrected Queue (Oct 2008)
16 Writing a Generalized Concurrent Queue (Nov 2008)
17 Understanding Parallel Performance (Dec 2008)
18 Measuring Parallel Performance: Optimizing a Concurrent Queue(Jan 2009)
19 volatile vs. volatile (Feb 2009)
20 Sharing Is the Root of All Contention (Mar 2009)
21 Use Threads Correctly = Isolation + Asynchronous Messages (Apr 2009)
22 Use Thread Pools Correctly: Keep Tasks Short and Nonblocking(Apr 2009)
23 Eliminate False Sharing (May 2009)
24 Break Up and Interleave Work to Keep Threads Responsive (Jun 2009)
25 The Power of “In Progress” (Jul 2009)
26 Design for Manycore Systems (Aug 2009)
27 Avoid Exposing Concurrency – Hide It Inside Synchronous Methods (Oct 2009)
28 Prefer structured lifetimes – local, nested, bounded, deterministic(Nov 2009)
29 Prefer Futures to Baked-In “Async APIs” (Jan 2010)
30 Associate Mutexes with Data to Prevent Races (May 2010)
31 Prefer Using Active Objects Instead of Naked Threads (June 2010)
32 Prefer Using Futures or Callbacks to Communicate Asynchronous Results (August 2010)
This month’s Effective Concurrency column, “Prefer Using Active Objects Instead of Naked Threads,” is now live on DDJ’s website.
From the article:
… Active objects dramatically improve our ability to reason about our thread’s code and operation by giving us higher-level abstractions and idioms that raise the semantic level of our program and let us express our intent more directly. As with all good patterns, we also get better vocabulary to talk about our design. Note that active objects aren’t a novelty: UML and various libraries have provided support for active classes. Some actor-based languages already have variations of this pattern baked into the language itself; but fortunately, we aren’t limited to using only such languages to get the benefits of active objects.
This article will show how to implement the pattern, including a reusable helper to automate the common parts, in any of the popular mainstream languages and threading environments, including C++, C#/.NET, Java, and C/Pthreads.
I hope you enjoy it. Finally, here are links to previous Effective Concurrency columns:
1 The Pillars of Concurrency (Aug 2007)
2 How Much Scalability Do You Have or Need? (Sep 2007)
3 Use Critical Sections (Preferably Locks) to Eliminate Races (Oct 2007)
4 Apply Critical Sections Consistently (Nov 2007)
5 Avoid Calling Unknown Code While Inside a Critical Section (Dec 2007)
6 Use Lock Hierarchies to Avoid Deadlock (Jan 2008)
7 Break Amdahl’s Law! (Feb 2008)
8 Going Superlinear (Mar 2008)
9 Super Linearity and the Bigger Machine (Apr 2008)
10 Interrupt Politely (May 2008)
11 Maximize Locality, Minimize Contention (Jun 2008)
12 Choose Concurrency-Friendly Data Structures (Jul 2008)
13 The Many Faces of Deadlock (Aug 2008)
14 Lock-Free Code: A False Sense of Security (Sep 2008)
15 Writing Lock-Free Code: A Corrected Queue (Oct 2008)
16 Writing a Generalized Concurrent Queue (Nov 2008)
17 Understanding Parallel Performance (Dec 2008)
18 Measuring Parallel Performance: Optimizing a Concurrent Queue (Jan 2009)
19 volatile vs. volatile (Feb 2009)
20 Sharing Is the Root of All Contention (Mar 2009)
21 Use Threads Correctly = Isolation + Asynchronous Messages (Apr 2009)
22 Use Thread Pools Correctly: Keep Tasks Short and Nonblocking (Apr 2009)
23 Eliminate False Sharing (May 2009)
24 Break Up and Interleave Work to Keep Threads Responsive (Jun 2009)
25 The Power of “In Progress” (Jul 2009)
26 Design for Manycore Systems (Aug 2009)
27 Avoid Exposing Concurrency – Hide It Inside Synchronous Methods (Oct 2009)
28 Prefer structured lifetimes – local, nested, bounded, deterministic (Nov 2009)
29 Prefer Futures to Baked-In “Async APIs” (Jan 2010)
30 Associate Mutexes with Data to Prevent Races (May 2010)
31 Prefer Using Active Objects Instead of Naked Threads (June 2010)
C++ and Beyond 2010 (October 24-27) is filling up quickly. As of this writing, nearly 40 of the 60 places have been taken since registration opened last month.
If you’re thinking of registering, it would probably be good to do it soon. 60 attendees is a hard limit; as I’ve written before, we want to have lots of face time with individual attendees. So once we hit 60, registration will close, although we’ll probably set up a waiting list for those of you that don’t quite make it into the first 60 so that you’ll get dibs if there are any cancellations.
I’m looking forward to seeing many of you in beautiful Snoqualmie, WA, USA this fall.
Sutter’s Mill 