Rico Mariani is a performance guru at Microsoft and a wonderful person. After a number of years on the Visual C++ team since 1.0, he went to MSN and then to CLR land where he now beats the "measure! don’t ship bad performance! measure!" drum to much good effect. It’s a pleasure to work with him. Interestingly, Rico is one of the handful of people I polled for "what should I cover" in the new Machine Architecture talk I’m currently writing for the seminar Bjarne and I are doing next month. In the current draft of that talk, I have two slides titled "Mariani’s Methodology (or, Rico’s Rules)" — I’m sure he’ll be mortified at the capitals.

Rico has just been interviewed on Channel 9. Recommended viewing. It’s sprinkled throughout with everything from useful career advice (whether you’re just starting out or looking for a next project), to interesting insights into early Visual C++ and Web product development, to how to ship at high performance and high quality in any language. Rico’s blog is also a great resource — and don’t get hung up when he talks mostly about .NET managed code, because the principles generalize to performance in any language and on any system.

How do friends congratulate the man? The pictures tell the story. Good on you, Rico!

On a sad note: One of the five people previously interviewed on the Behind the Code series is Technical Fellow and Turing Award winner Jim Gray. Jim is still missing after disappearing in the Pacific on January 28. Widely known and loved, he is greatly missed. Our thoughts are with Jim’s family.

You might say that it looks like "x might not be hex."

I’m happy to report that work on "C++0x", the much-anticipated Version 2.0 of the ISO C++ standard, has dramatically picked up steam over the past few months. The ISO C++ committee has now published the first partial draft of C++0x (for what "partial" means and what’s still missing, see below), and plans to publish a complete public draft before the end of 2007.

In this article I’ll give a quick history of the C++ standard and the current expected timeline. I’ll also summarize (drum roll please) which major features the committee decided to put in C++0x and the features that didn’t make the cut. In the coming months, I’ll go into more detail about these major features as they gel.

From C++98 until now: The story so far

It’s hard to believe it’s been nearly a decade since my first "C++ State of the Union" article appeared in C++ Report. That article, which I wrote on the way home from the July 1997 C++ standards meeting, anticipated correctly that the committee would manage to work through their large bug backlog and vote out a final Draft International Standard at the November 1997 meeting. That they did, to much cheering and fanfare and even a press conference from the main committee room, despite some last-minute excitement involving auto_ptr. ISO took its usual 6-12 months to process red tape, and the first edition of ISO Standard C++ was published in 1998 (aka C++98).

After 1997, the committee deliberately slowed down so as to give the compilers time to catch up to the many innovations in the standard. We’ve been meeting only two (not three) times a year, and from 1998-2003 we limited ourselves to just processing defect reports (bug fixes and requests for clarification) and no new features, to keep the standard stable. In 2002, we finally produced "service pack 1" of the C++ standard, which was published in 2003 (aka C++03).

Then the gates reopened and "C++0x" got underway. New features have been under serious development since 2003-4, and the committee has long had a target of publishing the next C++ standard by the end of the decade; that’s why it has been called "C++0x". (If that schedule fails, we can always make the awkward joke that it’s still C++0x, only x is a hexadecimal number, ha ha. But we’d rather finish on time.)

About C++0x

C++0x target timeline

At the most recent ISO C++ meeting, in October 2006, we considered two main timeline options. They are pictured at right, in a copy of a slide I showed during that meeting to spur discussion. In the first option, we actually publish in 2009 and legitimately get to be called "C++09". In the second, we finish the document in 2009, but because ISO takes most of a year to approve and publish a standard, it would end up as "C++10" (or, one could uncomfortably imagine, "C++0a").

The committee wrung its collective hands, and decided to put in overtime to make the first path happen. Working backward, the dates that need to be hit are:

• 2009: Publish "ISO/IEC 14883(2009): Programming Language C++"
• October 2008 ISO C++ meeting: Complete the final text of C++0x and vote it out for balloting, having crossed all the t’s and dotted all the i’s, and in particular having addressed all public comments received during the public review period.
• October 2007 ISO C++ meeting: Complete the first complete draft of C++0x and vote it out for public review and comments.

Given the work that remains, this means meeting more frequently than we’ve been doing for the past decade. For 2007, the committee agreed to let me put it back on a three-full-meetings schedule, and so for the first time since 1997 we’re having a July meeting. On top of that, subgroups have been organizing additional smaller meetings in between on specific topics, such as concepts. I’ll summarize the meeting schedule at the end of this article.

What’s in C++0x

You can get a very good feel for the contents of C++0x by looking at the first partial draft mentioned above. That draft contains the bulk of the extensions the committee pulled in from the first C++ Standard Library Extensions Technical Report (TR1). It does not, however, contain text for all major features yet, and has placeholders for the major features that I’ll summarize in this section.

Barring a disaster, here are the following additional major features not yet in the above partial draft that will be in C++0x. Every bullet heading links to a good "read this first" paper about the feature, and for some I’ve included additional links.

Concepts [N2081]

From that paper:

"Concepts introduce a type system for templates that makes templates easier to use and easier to write. By checking the requirements that templates place on their parameters prior to template instantiation, concepts can eliminate the spectacularly poor error messages produced by today’s template libraries, making them easier to use. … At the core of concepts is the idea of separate type checking for templates. Template declarations are augmented with a set of constraints (requirements): if the definition of the template typechecks against these requirements, and a use of a template meets these requirements, then the template should not fail to instantiate."

Imagine, if you will, an error message like ‘sorry, YourType isn’t a BidirectionalIterator’ instead of three pages of arcane messages about what templates couldn’t be instantiated. Among other things, concepts will let us write the standard’s own container and iterator requirements in code, rather than as English "cookbooks" of programming conventions.

The concepts proposal is coauthored by Bjarne Stroustrup and Doug Gregor. You can already start trying them out: There is a ConceptGCC proof-of-concept implementation that covers most of the proposal. For more details about how concepts can be applied to the C++ standard library, see also papers N2082, N2083, N2084, and N2085.

Garbage collection [N2129]

A C++0x compiler must provide garbage collection, which the programmer can use on request; "don’t GC this region of code" is still the default. This "opt-in" model leaves existing programs’ semantics unchanged, while providing real GC support for
programs that want it. It is also intended to enable garbage collection for objects allocated and manipulated by most legacy libraries, which both makes it much easier to convert existing code to a garbage-collected environment and helps "repair" legacy code with deficient memory management. Of course, any C++98/03/0x compiler is already free to garbage-collect the whole C++ heap, and a number of current implementations do that; but they aren’t required to do so, and this change would require GC to be available in a way that programmers can use and rely on. This work has been primarily driven by Hans Boehm and Mike Spertus. You can find a detailed paper here: N2128.

Memory model for concurrency [N2138]

As I wrote in "The Free Lunch Is Over", chip designers and compiler writers "are under so much pressure to deliver ever-faster CPUs that they’ll risk changing the meaning of your program, and possibly break it, in order to make it run faster." This only gets worse in the presence of multiple cores and processors.

A memory model is probably of the lowest-level treaty between programmers and would-be optimizers, and fundamental for any higher-level concurrency work. Quoting from my memory model paper: "A memory model describes (a) how memory reads and writes may be executed by a processor relative to their program order, and (b) how writes by one processor may become visible to other processors. Both aspects affect the valid optimizations that can be performed by compilers, physical processors, and caches, and therefore a key role of the memory model is to define the tradeoff between programmability (stronger guarantees for programmers) and performance (greater flexibility for reordering program memory operations)." This work is being driven primary by Hans Boehm, Clark Nelson, and myself.

Concurrency libraries [N2094]

The committee will likely release the concurrency libraries in two parts, both of which are likely to be released at about the same time.

• In C++0x itself: Support at the level of basic threads and locks, as well as atomic operations for lock-free coding, and related features like thread local storage.
• In the second C++ Standard Library Extensions Technical Report (aka Library TR2): More advanced extensions including futures and upgradable locks, so that we can gain experience with them before considering them for the standard itself post-C++0x. This follows the same path the committee took with the first set of library extensions, including shard_ptr and the hash-based containers: Those were first put into a separate TR (TR1), completed in 2004, and then based on experience most TR1 features were voted into the standard itself in April 2006 so that they are now part of the current partial draft of C++0x. The TR2 features are planned to be on a similar path, but for now are being released as a separate specification and not part of C++0x.

For more information and snapshots of current draft proposals still under discussion and development, see: N1907, N1966, N2047, and N2090.

What’s not in C++0x

The following major features were cut from C++0x because they require more work and would delay the next standard. Once C++0x is done, the committee may pick them up again.

Modules [N2073]

It’s definitely desirable to have a module system for C++ to package libraries and their implementations, and to provide an alternative to C++’s current build model based on textual source file inclusion. Reliance the current source file inclusion model poses technical difficulties for large C++ programs, notably: (a) long build times for large projects; and (b) difficulty of managing dependencies between interfaces and implementations. The current work has been spearheaded primarily by Daveed Vandevoorde (of EDG fame). The committee still intends to do work on this, but it’s now planned as a separate Technical Report on Modules after C++0x is complete rather than as part of the C++ standard.

Dynamic libraries [N1496]

Although C++ programmers routinely use shared libraries in C++ today, the C++ standard doesn’t specify their semantics in a portable way. Indeed, there are some fundamental semantic differences between some popular approaches, such as between Windows static and dynamic libraries and Linux shared libraries. Note that C++’s broad cross-platform support, and the existence of many existing approaches on those different platforms, makes it more difficult to specify portable library semantics than in languages like Java that started fresh with their own (then-new) run-time environment. Several committee members, notably Pete Becker, have done work to try to reconcile the existing approaches in a standard way that implementers could broadly support, but this effort will not be ready in time for C++0x.

Next Steps

Here’s the current list of 2007 meetings, with the "extra" meetings and milestones bolded:

• Jan 22-24, Batavia, IL, USA: Ad-hoc subgroup meeting on library working group issue cleanup.
• Feb 22-23, Mountain View, CA, USA: Ad-hoc subgroup meeting on concepts.
• Apr 15-20, Oxford, UK: Full WG21/J16 spring meeting.
• Jul 15-20, Toronto, Canada: Full WG21/J16 extra meeting.
• Sep 29 – Oct 6, Kona, HI, USA: Full WG21/J16 fall meeting. (Extended to Saturday.)
  Goal: Vote out the first complete public review draft of C++0x on Oct 6.

The extra meetings exist specifically to reach the goal of having that full draft before the end of this year. We’ll know as we get closer how well the working paper is coming together.

Regardless of when the first public review draft is published, don’t expect it to be the final text: The draft is to get a round of public comments, and we know there will be issues to refine and tweak over the following year. But that first complete public draft will contain standardese for all major C++0x features in near-final form, which is quite a milestone (and quite a mouthful). It will give us the first real and concrete look at the shape of C++0x.

Over the coming months I’ll be posting additional articles about specific features in the new standard, including some of the cool new features mentioned above. Stay tuned.

Here’s a wonderful interview with The Other Steve (Wozniak) on the start of Apple. It’s part of a new book called Founders At Work, full of similar interviews with all sorts of well-known founders of companies/products from Adobe and Lotus to TiVo and Ruby on Rails. (I don’t have any commercial interest in the book; I just heard about it via the blogosphere.)

Fair warning: It’s a long interview. But it’s fascinating. Here’s a small excerpt that resonates strongly with me in our highly complexified world of deeply layered and arbitrarily composed software, where programmers are all too often insulated from knowing the true cost of something as simple as a library call:

Livingston: What is the key to excellence for an engineer?

Wozniak: You have to be very diligent. You have to check every little detail. You have to be so careful that you haven’t left something out. You have to think harder and deeper than you normally would. It’s hard with today’s large, huge programs.

I was partly hardware and partly software, but, I’ll tell you, I wrote an awful lot of software by hand (I still have the copies that are handwritten) and all of that went into the Apple II. Every byte that went into the Apple II, it had so many different mathematical routines, graphics routines, computer languages, emulators of other machines, ways to slip your code in and out of an emulation mode. It had all these kinds of things and not one bug ever found. Not one bug in the hardware, not one bug in the software. And you just can’t find a product like that nowadays. But, you see, I had it so intense in my head, and the reason for that was largely because it was part of me. Everything in there had to be so important to me. This computer was me. And everything had to be as perfect as could be made. And I had a lot going against me because I didn’t have a computer to compile my code, my software.