Trip Report: March 2004

The C++ Standards committee continues to meet twice a year. This time, I want to report on the Spring 2004 meeting which was held in Sydney, Australia, on March 21-26, 2004.

Highlights

Here are the highlights of this meeting:

• Library innovation continues and solidifies. We now think we're one meeting away from finishing up the first round of library extensions, which means they should be technically complete by the end of this year. At this meeting, we also decided to kick off a second round of extensions to continue the flow of new library facilities. See below for more details.
• Language innovation continues. At this meeting, we considered more and better-baked language extension proposals for C++0x than ever before; some of them are detailed below. Many of them are nearly ready to be added to the C++0x draft Standard itself.
• Acceleration. The committee also hopes to accelerate its work by doing more work between meetings. Over the coming months, we'll be experimenting with electronic review processes and other techniques for improving both the quantity and quality of the work of extending and evolving C++.
• C and C++ cooperation and harmonization continue. At the Fall 2003 meeting, C and C++ already decided to adopt large parts of each other's work and to work jointly on some new additions. As expected, at this Spring 2004 meeting, the C++ committee decided to adopt the C99 library extensions that were not already in Standard C++. Interestingly, the C++ committee also explicitly decided to review the remaining C99 language extensions and miscellaneous differences to minimize source-level incompatibilities for programmers who are working in the (liberal) intersection of C and C++. This doesn't mean C++ is going to just airlift in the C99 language extensions wholesale; rather, it means that C++ intends to specifically review C99's extensions, adopting what makes sense, and then possibly in a different form because C++ is often able to add extensions in the form of library facilities that could only be language extensions in C (for example, an existing case in point is complex).

Now let's drill down a little. To make this a self-contained article, I'll recap some of the preexisting status as we go, but focus on the current news and updates from this meeting. For more detailed information about some of the things that I've already covered in the past, see the references that I'll include to those other articles.

What We're Doing, Part 1: Library Extensions Update

Why should you care about the work the Standards committee is doing?

In the short term, you might care because we're working on extensions to the C++ Standard Library, many of which are commercially available today or will be available soon from multiple community and vendor implementations. The first round of these library extensions, known as Library Extensions Technical Report 1 (Library TR1), is expected to be complete later this year. In recent articles, I've already written extensively about several of these new facilities, including:

• Smart pointers (shared_ptr and weak_ptr). [2]
• Tuple types (tuple). [3]
• Generalized function pointers (function). [4,5]

Others that I haven't covered yet, but intend to cover in future columns, include:

• (New) Nearly complete C99 library compatibility. At this meeting, we officially voted to adopt essentially all the C99 Standard Library extensions that are not already part of ISO C++.
• Hash-based containers (unordered_set, unordered_map, unordered_multiset, unordered_multimap) that can offer substantially better performance, particularly better worst-case performance, than the current standard tree-based containers.
• Type traits (alignment_of, has_nothrow_copy, has_virtual_destructor, is_base_of, is_ const, is_convertible, for example) that let you easily query information about the capabilities of a type and about the relationships between types, and make compile-time decisions based on the answers.
• Regular expressions (basic_regex) that offer powerful expression matching (and not just for strings, either).
• Random-number generation (such as random_device and poisson_distribution) suitable for requirements as diverse as cryptography, gaming, and mathematical analysis.

There are a few more facilities in this first batch of Standard Library extensions, including a bountiful bevy of beautifully brilliant mathematical special functions, but the ones I've listed are the ones that are most likely to be of wide interest out of the batch that's due to be technically complete later this year.

But wait, there's more: Although this first set of extensions is nearly done, at this meeting the committee formally decided to embark on a second round of extensions. This means that the aforementioned is the beginning, not the end—the steady flow of such additions to the Standard Library will continue for the foreseeable future, starting with an advanced iterator facility that didn't quite gel in time to be part of the first batch.

What We're Doing, Part 2: Language Extensions Update

Another reason to care about what the committee is doing is that we're also working on the next evolution of the C++ Standard. It's colloquially known as "C++0x" because we plan to complete work on it in this decade.

In my April 2004 column [1], I reported on the goings-on at the Fall 2003 meeting, as well as news from related meetings of the C and C++/CLI committees and how their work is being coordinated with C++. At this year's Spring meeting, we find the Evolution Working Group continuing to make progress sifting through language extension proposals. About two dozen specific proposals had papers, were discussed in detail, and will be further refined; some are very close to ready to vote into the draft Standard. Here are some highlights of concrete proposals that are in pretty solid form and enjoyed particularly strong support, so that they're among the most likely language extensions to be part of C++0x in some form; several of them also bear on collaboration with other Standards bodies (C and C++/CLI).

• C99 harmonization. Besides the general resolution to review C99's language extensions and harmonize where possible, there were two specific proposals in this area: One proposed that we adopt C99's long long type, and another proposed that we adopt C99's preprocessor extensions. Together with these, we also considered a draft paper from Bjarne Stroustrup proposing a #scope/#endscope mechanism that would give programmers a standard way to control macro pollution and protect their code from unwanted macros; Stroustrup's proposal was then also passed along to the C committee, who met the week after C++ in the same location, with C++'s recommendation that they consider something like this for C and that the two groups work together on it to minimize the chance of standardizing something that wasn't quite the same.
• Delegating constructors. Francis Glassborow and I wrote a proposal to allow constructor work to be factored, including the initialization list work. This feature was independently proposed last year by Glassborow in the C++ committee and my C++/CLI work. The committee added a minor but significant tweak, and this proposal is now ready for us to draft some standardese wording and move forward.
• Static (compile-time) assertions. Wouldn't it be nice if you could assert() at compile time, and emit a custom error message straight into the compiler output just like #error does? We think so too, and that's what this proposal is all about.
• Explicit conversion operators. Implicit conversions can be useful, but they can also bite when they get used unexpectedly. Today, we can write explicit on converting constructors so that they are never triggered implicitly. Alas, we can't write the same on conversion operators, which, after all, are pretty much just the other side of the same coin. This is a frequently proposed extension, and was specifically considered in Sydney. It has much sympathy in the committee.
• nullptr. I presented a refined version of a proposal coauthored by myself and Bjarne Stroustrup on nullptr, an explicit null pointer constant; this feature was described in detail in last month's column. [6] This is a feature that came directly from the C++/CLI work and directly overlaps with the ISO C++ evolution, so everyone wanted to be sure to check with the EWG to minimize the potential for divergence of similar features in C++/CLI and ISO C++ itself. The core of the proposal is still as described in [6], and this time the main change request was to simplify the design surrounding the type of nullptr.
• Aside: Permit me to editorialize briefly here about why I think this is good progress. Now, you might recall that the main change request for nullptr at the previous meeting was in some ways the inverse of the direction just discussed, namely that we should add to the design in this same area. That's not inconsistent, it's just par for the course; sometimes there's backtracking as alternatives are explored and either liked or rejected, and as a proposal author, you just have to be ready for that and expect that you're going to be directed to write up several versions of your proposal, some of which may roll back to essentially previous versions. That's not (necessarily) inconsistent feedback from the group from one meeting to another; it's more a case of everyone gradually getting the chance to get as familiar with your feature as you already are, and it's a good thing because it means people are taking the proposal seriously. Proposal authors should not, and generally do not, get frustrated with this or view it as wasted work and rework. I really believe it isn't that at all; rather, it's a necessary part of getting a group consensus, which is the essential thing in the standardization process. Patience is necessary, and it's generally rewarded.)
• Strongly typed enums. The fact that enums aren't scoped, implicitly convert to their underlying type, and have an unspecifiable underlying type are all serious portability problems, and sometimes they lead to subtle correctness problems, too. David Miller and I proposed a strongly typed enum type, building on Miller's work on this in the C++ committee last year and my independent work on this in the context of C++/CLI that came up with essentially the identical semantics, just different syntax. For more details on why this is a good idea and what particular problems current enums can cause, see my article in last month's issue. [7]

I hope to cover several of these features in upcoming installments of this or another column.

Summary

C++ library extensions are in full swing, and C++ language extensions are moving well. C++ and C++/CLI continue to actively collaborate well to respect C++ evolution and craft the highest possible quality of C++ language extensions for modern environments. C and C++ are continuing to work in good faith to iron out the source-level incompatibilities between the two languages, notably the language extensions introduced in the C99 Standard. This can only benefit programmers everywhere, especially those who use both languages, or even just use compilers that support both languages.

What's not to like? It's been quite a good year.

References

1. [1] H. Sutter. "Trips Report: October-December 2003," C/C++ Users Journal, 22(4), April 2004.
2. [2] H. Sutter. "Smart(er) Pointers," C/C++ Users Journal, 20(8), August 2002. http://www.cuj.com/documents/s=7980/cujcexp2008sutter/.
3. [3] H. Sutter. "Tuples," C/C++ Users Journal, 21(6), June 2003. http://www.cuj.com/documents/s=8250/cujcexp2106sutter/.
4. [4] H. Sutter. "Generalized Function Pointers," C/C++ Users Journal, 21(8), August 2003. http://www.cuj.com/documents/s=8250/ cujcexp2106sutter/.
5. [5] H. Sutter. "Generalizing Observer," C/C++ Users Journal, 21(9), September 2003. http://www.cuj.com/documents/s=8840/cujexp0309sutter/.
6. [6] H. Sutter. "Much Ado About Nothing: A (True) Null Pointer Value for C++," C/C++ Users Journal, 22(5), May 2004.
7. [7] H. Sutter and J. Hyslop. "Enumerations," C/C++ Users Journal, 22(5), May 2004.

Herb Sutter (http://www.gotw.ca/) is convener of the ISO C++ Standards committee, author of Exceptional C++ and More Exceptional C++, and Visual C++ architect for Microsoft.