In this column, I want to deliver a trip report on the April 2003 C++ Standards meeting. Whereas the big news in the October 2002 meeting was that the first two extensions (tuple [1] and function [2], see also [3]) were adopted for the standard library extensions technical report, in April no fewer than 10 more were added. What were they, and which ones might you particularly care about? That's this month's topic.
The C++ Standards meeting (ISO WG21, ANSI J16) was hosted by ACCU in Oxford, UK, from April 6-11, 2003. The C++ committee meets twice a year, in the spring and fall, and has been working on four major work items:
Note the division of work between the Library TR and the Evolution WG: The former deals with library-only extensions that do not require additional language support, and the latter with proposals that require language extensions to do well. Some items are being accepted in the Library TR as "hackaround" extensions that work around today's C++ language limitations. If and when the EWG closes those holes with better language extensions, the library hackarounds can be refined or abandoned.
The above list does not mention the first Technical Corrigendum (TC1), the first "service pack" to the existing standard, because the technical work on that set of corrections was completed two years ago and since then has just been winding its way through the ISO red tape.
For more details more about the history and future of the C++ Standards process and how these pieces interact, see [4].
Here's what happened in Oxford, in roughly chronological order.
First, Technical Corrigendum 1 (TC1) was approved by ISO earlier this
year. It will be published as an updated edition of the Standard, with all changes
applied. (The list of diffs from C++98 will also be available, possibly freely.)
The amended standard with the TC1 corrections applied to it will be known informally
as "C++03" (not to be confused with the next-generation C++0x work
going on right now for the next major revision of the standard), and formally
as ISO 14882:2003(E).
The Performance TR is complete and ready for ISO balloting. As a result
of the Oxford meeting, the final text of the Performance TR was approved and
will soon be transmitted to ISO for balloting. Publication will be delayed a
little because ISO administrative rules require two more ballots, each of which
takes at least several months to prepare and conduct, but the technical work
on the document is done.
The export feature was reaffirmed and continues to be a required part of ISO C++. At this meeting, I and Tom Plum brought a paper presenting reasons why in the future the committee might consider removing the export as a required part of the language. This was discussed in depth, and the committee decided to retain export. In particular, it is hoped that over the next few years we will be able to see more real-world experience with export-enabled compilers based on EDG's front end to evaluate the true usefulness of the feature for templates in production code. [6]
The biggest news is that the Library TR was expanded from 2 to 12 approved proposals. At the previous meeting (October 2002), the first two library extensions were approved for the Library TR. At this meeting, 10 new library extensions were approved. You can get at them via the C++ committee web site (for this and other useful standards-related links, see [7]). In order by paper number, they are:
N1422, "A Proposal to Add Mathematical Special Functions to the C++ Standard
Library"
N1424, "A Proposal to add Type Traits to the Standard Library"
N1429, "A Proposal to add Regular Expression to the Standard Library"
N1432, "A Proposal to Add an Enhanced Member Pointer Adaptor to the Library
Technical Report"
N1450, "A Proposal to Add General Purpose Smart Pointers to the Library
Technical Report"
N1452, "A Proposal to Add an Extensible Random Number Facility to the Standard
Library"
N1453, "A proposal to add a reference wrapper to the standard library"
N1454, "A uniform method for computing function object return types"
N1455, "A Proposal to Add an Enhanced Binder to the Library Technical Report"
N1456, "A Proposal to Add Hash Tables to the Standard Library (revision
4)"
These proposals have been approved for inclusion in the Library TR draft working document, but of course that document itself is still in an early draft form and everyone understands that it's subject to further refinement and adjustment. Most of the facilities were accepted with a short list of known "tweaks" or changes that need to be made before they're in final form ready for official publication.
These proposals, together with the two already accepted, form the bulk of the first library technical report. Now, this doesn't mean that you should hold back from submitting new proposals! New library proposals are still welcome and will continue to be considered, either for a second library technical report or for the C++0x standard itself.
Finally, one question that arose again at the April meeting was the simple but profound: "Which namespace will the Library TR extensions live in?" The sentiment at the meeting was that they will likely be declared in a nested namespace named std::tr1.
So here we are in 2003 making changes to Standard C++. We have a Library TR as a vehicle to formalize new standard library additions (relatively) quickly, and the main C++0x work as the primary vehicle to create Version 2.0 of the C++ Standard and able to handle both language and library extensions.
Fine and dandy. The question is, what's the right balance between stability and growth? Consider:
The C++ committee is trying to address both of those needs. For one thing, you can see above the emphasis on aggressive extension to the standard library, rather than to the core language. Library extensions don't add complexity to an admittedly already complex language, and they don't add intellectual overhead either because people who don't care about the new library extensions can pretty much just blissfully ignore them (unless they're maintaining someone else's code that uses them, of course).
Even in the core language, however, changes and extensions are not being considered willy-nilly in a mad rush to see what cool new thing can be grafted on next. Although at times it may seem like there is a long list of potential changes on the Evolution WG's list, only a handful are serious front-running candidates for standardization while many others are nice-to-haves that are less likely to be considered appropriate for widespread standardized use. And every proposal has to be explicit about what impact, if any, it would have on the existing language, and on how it interacts with existing language features.
Only time will tell where the committee really draws the line for C++0x extensions, but an appropriately conservative approach still holds the day as of this writing. Next time: A closer look at one of the new Library TR proposals. Stay tuned.
[1] H. Sutter. "Tuples"
(C/C++ Users Journal, 21(6), June 2003).
[2] H. Sutter. "Generalized Function
Pointers" (C/C++ Users Journal, 21(8), August 2003).
[3] H. Sutter. "Generalizing Observer"
(C/C++ Users Journal, 21(9), September 2003).
[4] H. Sutter. "The New C++"
(C/C++ Users Journal, 20(2), February 2002).
[5] http://www.boost.org
[6] http://www.edg.com
[7] http://www.gotw.ca/iso