Trip Report: April 2005

News and views from the Spring 2005 C and C++ Standards meetings. The big news: The C++ evolution working group has set this fall as the deadline for new proposals, after which we'll be heads-down trying to finish most of the technical work next ISO C++ Standard by 2007 so that the new Standard can be published in 2009.

Herb Sutter (http://www.gotw.ca/) chairs the ISO C++ Standard committee and is a software architect in Microsoft's Developer Division. His most recent books are Exceptional C++ Style and C++ Coding Standards.

The Spring 2005 ISO C and C++ Standards meetings were held in Lillehammer, Norway from April 17-22, 2005; the minutes are available at [1]. Both committees continue to meet twice a year; the next meetings will be in sunny Mont Tremblant, Quebec, Canada on September 26 through October 8, 2005. (See my previous trip report [2] for details about the previous meeting, held in fall 2004 in not-as-sunny-at-the-time Redmond, WA, USA.)

The ISO C [3] meeting focused primarily on completing most of the technical work on the Safe C++ Technical Report (TR) [4], which is a document that provides safer replacements for unsafe C standard library functions (for example, strcpy_s instead of strcpy). C and C++ are continuing to coordinate parts of their work, most recently on preprocessor (macro) extensions and on decimal floating-point types.

For the rest of this article, I go into more detail about the ISO C++ [5] meeting, where we focused on completing the first round of Standard Library extensions, and set a date for the new C++0x Standard itself. I'll start with the latter.

Big News in C++: assert( "C++0x" && x == 9 );

The big news at this ISO C++ meeting is that "C++0x" intends to be "C++09," meaning that we do intend to ship a new standard this decade.

That may seem a long way off, but it's really pretty aggressive. Because of ISO balloting procedures, that means that the work needs to be pretty much technically complete by the end of 2007. This aggressive schedule leaves only five meetings to complete the bulk of the technical work. If we make that target, then 2008 will be spent on the first round of international balloting and review, and the committee will spend its two meetings that year doing the resulting cleanup and refinement work to produce the (hopefully) final text of the Standard by the end of 2008. Assuming that the result is acceptable to all of the national bodies and addresses any comments they sent, then we can spend 2009 on the second round of international balloting to approve the text and publish the Standard.

If we keep to this schedule, then by the end of 2007, you'll know what features will be in the next Standard and have a good idea of the details of how they'll work, and by the end of 2008 even the details will be fully nailed down. (Caveat: The C++ committee has slipped its schedule before. On the bright side, if we miss that date and publish the Standard in 2010 or 2011, we can always claim it's still "C++0x" but that "x" just turned out to be a hex digit.)

One consequence is that this year, the C++ committee is going to close the door on new suggestions for this revision of the Standard. Now that we've been actively soliciting submissions for three years, and we've received and reviewed in detail at least scores (and possibly hundreds) of proposals, we've set the deadline for new proposals for the fall 2005 C++ meeting to be held on October 2-8. Note that the premeeting mailing deadline is usually set for six weeks before the meeting, so if you're sitting on a secret proposal you've never shown the outside world but that you think is thoroughly baked and you want to see in C++0x, know that that's when papers are due (and you'd be best of getting feedback on the comp.std.c++ newsgroup first, because a fair number of proposals turn out to be repeats of things that have already been considered in depth and rejected, often numerous times). After the fall 2005 meeting, the committee will, of course, still be generating and considering new papers that refine and progress existing work that is already in the pipeline, but the chances are slim that a brand-new proposal will get traction. You never know, but coming in with anything after that isn't an advisable bet.

C++ Library Evolution

While working on the next Standard, we've also been doing off-to-the-side work on a new batch of Standard Library extensions that we'll be delivering before the next Standard. In fact, we're delivering them now: At this meeting, we completed all technical work on this first set of Standard Library extensions (also known as "Library Extensions Technical Report 1," or "Library TR1," or just "TR1"). See [6] for the latest draft as of this writing, which was the draft going into the Lillehammer meeting; at the meeting we voted in some tweaks and will soon produce the document to go out for final ISO balloting (which might be in progress already when you read this).

If you're interested in details about TR1, definitely check out Pete Becker's column in the June and July 2005 issues of CUJ. He's several installments into a column about TR1, and he's also writing a whole book about it. It's sure to be recommended reading. This batch of extensions includes support for new smart pointers (shared_ptr), hash-based containers (for example, unordered_set), type traits, random-number generators, regular expressions, tuple types, a generalized function wrapper, and other stuff including a slew of mathematical functions. I've already written about many of these (see [7], including articles like the one on Generalized Observer), and Pete will write about more.

But just because TR1 is done doesn't mean there won't be further library extensions. Far from it. And, to encourage people, we have issued a call for further library extension proposals [8]. The introduction says it so well that I'll quote it directly:

The C++ standardization committee is now soliciting proposals for a second technical report on standard library extensions, "TR2." The committee will consider both proposals that address entirely new domains, and proposals to modify the existing standard library.
The committee especially welcomes proposals in the following areas:

• Unicode
• XML and HTML
• Networking
• Usability for novices and occasional programmers

Although each proposal will be evaluated on its own merits, the committee is more interested in high-level libraries that solve day-to-day problems of application programmers than in low-level infrastructure.

Again, these library TRs are batches of extensions being done "off to the side," not (yet) in the next draft standard. So what do TR1 and TR2 mean for C++0x? Clearly they're extensions that people are serious about, and particularly for TR1 they're extensions that are likely to be on a path to get into the next Standard, but nothing is a slam dunk and some parts might not go in and some might be changed based on feedback from the field (one of the advantages of doing a TR). Here is the current provisional schedule for the library working group, showing the plan for making decisions about adopting TR1 components into the next Standard as well as for TR2 work:

• October 2005: Cutoff date for new proposals to C++0x.
• October 2006: Decision on the adoption of components from TR1 for C++0x.
• October 2006: Cutoff date for initial proposals to TR2.
• April 2007: Cutoff date for clean-up papers for C++0x.

We can fairly confidently expect at least large parts of TR1 to become standard. As for TR2, depending on how quickly its proposals progress and how quickly C++0x itself is going, it might be possible to adopt part of TR2 into C++0x, or even roll TR2 into C++0x. For now, we're keeping the TR2 library work in a separate bucket to better manage the scope of C++0x and enable us to easily ship C++0x on time and ship TR2 out-of-band as a separate deliverable if it turns out that that's more convenient.

C++ Language Evolution and C++0x: What a Concept!

If you haven't yet read Stroustrup's article "The Design of C++0x" in the June 2005 issue of this magazine, please run—don't walk—and read it [9].

Concretely, in Lillehammer we adopted the first two major additions to the C++ language; this marks the first time since 1997 that the core (draft) Standard language itself has changed. The two items we voted in were C99's long long and the static_assert facility. Modest additions, to be sure, but they're just the start.

C99 long long is just what it appears to be: long long is now (draft) Standard C++. I could (and did) make the usual jokes, such as that we talked about this issue for a long long time (which happens to actually be true; it's been discussed during at least the past three C++ meetings).

static_assert is described in [10]. The basic idea is to have compile-time assertions without today's hacking around the lack of language support in current ISO C++.

There's a lot of other, and much bigger, work underway. A notable example is concepts [11, 12], which are completely complementary to static_assert. The idea of concepts is to be able to declare flexible and powerful constraints on templates that will vastly improve the quality of template error messages and overall template usability and type safety. For example, type in this program and compile it under your favorite compiler:

#include <algorithm>
int main() {
  int i = 0, j = 2;
  std::sort( i, j );
}

Of course this program shouldn't work, and it won't because std::sort expects two iterators, and i and j are integers, not iterators. Here the idea of an "iterator" is an example of a concept: It's a type that you can do certain things with, including dereference using unary * and get a certain type as the result. Clearly, an int isn't something you can dereference, but the best of today's compilers won't say so and instead give you an unduly hard time about it.

For the aforementioned program, some compilers spew back only a half-screen of error messages; others give you multiple screens. Today's templates are only fully checked at the point where they are actually used, or instantiated. Clearly, we'd prefer to get a single message that tells us exactly what the problem is and how to fix it, something like, "Hey, stupid, i and j aren't iterators," but today's compilers don't give warnings like that. (Even better, we'd like to easily provide overloads of the same algorithm that each apply only to a given category of iterators.)

This is where concepts come in. Instead of the standard definition:

template<class RandomAccessIterator>
void sort(RandomAccessIterator first, RandomAccessIterator last);

we'd like to make a concept called RandomAccessIterator, for example (this is speculative syntax):

concept RandomAccessIterator<class T> {
  ... definition of what a RandomAccessIterator<T> should be able to do,
  such as increment, dereference, etc. ...
};

and then define sort as:

template<class T>
void sort(RandomAccessIterator<T> first,
         RandomAccessIterator<T> last);

This would enable us to write mistakes like:

int i = 0, j = 2;
std::sort( i, j );	// line 7

and get decent errors like:

error (line 7): hey, stupid, i and j aren't
                   RandomAccessIterators

instead of screenfuls of errors. It would also enable authors of templates like sort to easily overload based on iterator category, without bending over backwards through idiomatic tagging machinery like we do today:

// overload on the iterator category

template<class T>
void sort(RandomAccessIterator<T> first, 
         RandomAccessIterator<T> last);

template<class T>
void sort(BidirectionalIterator<T> first, 	BidirectionalIterator<T> last);

Even just considering iterators, you can quickly see the benefits of having first-class support for expressing declarative constraints on template parameters. The alternative is what we do today for iterator categories: They are currently specified, not in the language, but in documentation in the form of tables of "should work like this" in the standard. Compilers have a hard time enforcing English documentation. They have a much better time enforcing abstractions with nailed-down definitions supported right in the language.

That's just a quick sketch of concepts. Expect many more articles on this in the coming year as the concept proposals get baked and refined.

Summary

C++ is vibrant and alive. ISO C++ v2 is well underway and could be done in as soon as two years. There's a lot to be happy about, and to write and learn about, in these and other pages as the world gets further glimpses into the first 21st-century Standard C++.

References

1. [1] R. Klarer. "Minutes of J16 Meeting No. 40/WG21 Meeting No. 34, April 11-15, 2005" (ISO C++ committee paper ISO/IEC JTC1/SC22/WG21/N1789, April 2005). This document is available online at http://www.open-std.org/jtc1/sc22/wg21/docs/ papers/2005/n1789.html.
2. [2] H. Sutter. "Trip Report: October 2004" (C/C++ Users Journal, 23(1), January 2005).
3. [3] The official web site for the ISO C committee is http://www.open-std.org/jtc1/sc22/wg14/.
4. [4] R. Meyers, ed. "Working Draft of Security Technical Report" (ISO C committee working document ISO/IEC JTC1/SC22/WG14/N1078, September 2004). This document is available online at http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1078.pdf.
5. [5] The official web site for the ISO C++ committee is http://www.open-std.org/jtc1/sc22/wg21/.
6. [6] M. Austern, ed. "Proposed Draft Technical Report on Standard Library Extensions" (ISO C++ committee working document ISO/IEC JTC1/SC22/WG21/N1745, January 2005). This document is available online at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1745.pdf.
7. [7] http://www.gotw.ca/publications
8. [8] H. Hinnant, B. Dawes, and M. Austern. "Library Extension TR2 Call for Proposals" (ISO C++ committee paper ISO/IEC JTC1/SC22/WG21/N1810, April 2005). This document is available online at http://www.open-std.org/jtc1/sc22/wg21/docs/ papers/2005/n1810.html.
9. [9] B. Stroustrup. "The Design of C++0x" (C/C++ Users Journal, 23(6), June 2005).
10. [10] R. Klarer, J. Maddock, B. Dawes, and H. Hinnant. "Proposal to Add Static Assertions to the Core Language (Revision 3)" (ISO C++ committee paper ISO/IEC JTC1/SC22/WG21/N1720, October 2004). This document is available online at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1720.html.
11. [11] B. Stroustrup and G. Dos Reis. "A concept design (rev. 1)" (ISO C++ committee paper ISO/IEC JTC1/SC22/WG21/N1782, April 2005). This document is available online at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1782.pdf.
12. [12] J. Siek, D. Gregor, R. Garcia, J. Willcock, J. Jdrvi, and A. Lumsdaine. "Concepts for C++0x" (ISO C++ committee paper ISO/IEC JTC1/SC22/WG21/N1758, January 2005). This document is available online at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1758.pdf.