ISO C++0x: Complete Public Review Draft In October 2007?

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

ISO C++ timeline proposals, October 2006

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, N1966N2047, 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.

8 thoughts on “ISO C++0x: Complete Public Review Draft In October 2007?

  1. We need a better way to specialise individual member functions in class templates without having to copy all the other member functions just to specialise the few that are needed.

    An extension of this is that we need a way to specialise a code block within a template member function so that it is either included or excluded depending on the template type parameter.

    switch
    {

    }

    Inclusion of both of these would eliminate the need for coding separate class specialises keeping specialiser coding to a minimum

  2. It is very unfortunate to see modules and dynamic libraries being left out. I defenitelly need tham more than GC.
  3. Good to see that the GC and concurrency are making their way into the standard. I’m also very interested in reflection (but I understand that I’ll have to wait the next standard again, considering important big the change is). DL drop-out is also quite important – I’d like to see how the comitee will solve the major problem of the ABI. Too bad I have to wait.

    Anyway, you guys just rock ;)

  4. n

    But what about template parameter lists? I’ve been waiting for this for ages, seems like I’m going to wait a lot longer still.

  5. Ok so I haven’t exactly looked in detail at the gc proposal (this is actually the first I’ve heard of it!), but… seriously, is this necessary??? I am very, very afraid that something like this would give half-assed programmers a license to kill.

    Honestly, I hope gc doesn’t make it in and is relegated to a implementation-specific featureset.

  6. humm. Why no work is done towards persistent capabilities, at least serialization (implying some reflexivity)? GC, i have it easily, concept checking, nice but given compilation time I tend to limit usage of generic programming which I see more and more as a toy for language implementors. Eiffel would have had a bigger success if not. Are there survey about why algorithm are not much used? Are the error messages,  really the reason ? Concurrency and dynamic library really need unification. Maybe the same way STL did for collection: if I’m not using the standard library implementation, I will still use the API principles.

    n

Comments are closed.

In comments, use [code] [/code] for code blocks, and the same with angle brackets for code inside text paragraphs. I appreciate and try to acknowledge feedback on GotW articles; if you're suggesting an improvement for a GotW Solution post, please post under your real name (or include it in the comment text) if you would like to be acknowledged here and when the material is updated and expanded in future Exceptional C++ books.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s