This isn’t the column I’d intended to write. I was planning to write about an interesting technique in template programming, but I’m now sitting in sunny Redmond, Washington, where I’ve come for the October meeting of the C++ Standardization Committee. I’m not going to present any new classes in this column, or explain any obscure corners of the standard library; it’s clear that there’s something more important.
The C++ Standard was finished in 1997 and released in 1998. What has the Standardization Committee been doing for the last three years? There’s a simple answer: standards maintenance. The Standard was a large project, and, like all large projects, it had bugs. (It still has some.) There were inconsistencies, ambiguities, components that couldn’t be implemented, and requirements that didn’t mean what we thought they did. We’ve been fixing those problems as we’ve found them and as they’ve been reported to us. We have now finished a “Technical Corrigendum,” which is bureaucratese for a patch that fixes many of these bugs.
If you’re curious about the sort of things the committee has been dealing with, we make two lists available: one for issues having to do with the core language (<http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html>) and one for issues having to do with the standard library (<http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html>).
Maintenance isn’t a very glamorous activity; it’s only noticed when it’s done poorly. Some of the issues before the committee are serious (as you’ll see if you take a look at those two lists), and sometimes we’ve had to work hard to figure out the right answer, but we haven’t made many really visible changes. That’s deliberate, of course: our main goal has been stability. We’ve tried to avoid surprises. When we’ve made changes, we’ve usually tried to restore something that everybody assumed was already the case. If nobody but language lawyers ever notices what we’ve been doing for the last three years, then we’ve been doing our job.
Library Extensions
That’s all changing. Stability was the right goal for the last couple of years, but people — the Standardization Committee, and the C++ community as a whole — have gradually become more and more interested in doing new things, not just maintaining the old. It’s the right time. There’s been a lot of good work in C++, and implementations are finally getting to the level where it’s possible for us to write standard C++ without compromises; it’s becoming less and less necessary to litter your code with workarounds for a half dozen deficient compilers. It’s time for us to standardize more of what people need today, not just what people needed five years ago.
The C++ Standardization Committee lives underneath a larger bureaucracy, and we’ve set the official process in motion. By the time you read this, we expect that we will have formal permission to begin working on extensions. We’re starting with the library.
Why the library? Partly it’s because there’s a pretty strong feeling that now isn’t the time for us to be making big changes in the core language. We already have a language with a great deal of expressive power, and we’re still learning what we can do with it. Every so often I still sometimes will learn about some new and surprising technique that I hadn’t previously realized was possible; modern ideas of good C++ style are very different from what would have been considered good style 10 years ago. Partly we want to focus on the library because user demand for new libraries is extremely high. And partly it’s because it seems more consistent with the C++ philosophy: we want to provide general abstraction facilities, not special-case features. We didn’t define a built-in complex number type, for example; we defined std::complex as part of the standard library, using classes and templates and operator overloading. Finally, it’s much easier to experiment with libraries than with language extensions; not many of us are in a position to tinker with C++ compilers.
This doesn’t mean that the core language will remain absolutely unchanged, of course, but it does mean we’ll mainly think about language changes in the context of what we need for better libraries: we’ll change the language only if we find a convincing argument that the abstraction facilities of the existing language are inadequate. Maybe we’ll need some changes to namespace aliasing rules, for example, to support versioning of the standard library — we won’t know until we try. Or perhaps we’ll find there are some library components that can’t be implemented in any reasonable way without typedef templates — when I look at some of the elegant techniques in Andrei Alexandrescu’s book [1], I sometimes think I’m just seeing a shadow of what his work might look like if we had typedef templates. For example:
template <typename A, typename B>
typedef typelist<A, typelist<B, nil_type> >
typelist2<A, B>;
It’s always difficult to say in advance exactly what we want to see, but we do at least have some ideas about the directions we’re most interested in [2]:
- Filling obvious gaps. One of the most frequent questions people ask about the Standard C++ library is “Why doesn’t it have hash tables?” There isn’t really any good reason. There’s a historical reason, which is trivial: the proposal was presented at the wrong time. Lots of vendors do provide hash tables as a nonstandard extension. If we see an obvious gap in the library, and especially if it turns out that vendors provide it anyway (either as an extension or for the library’s own internal use), then it’s a good candidate.
- Better compatibility between C and C++. The world has changed in the last few years, and one of the things that has changed is the C language. The C++ language was deliberately designed to be very compatible with the standard C language [3]. The C++ Standard references the version of the C Standard that was defined in 1989 (sometimes called “ANSI C”), but there’s now a newer version of the C Standard. It has new keywords and new library facilities. We should look at past and future work in C, and we should ensure that future versions of C++ and future versions of C become more compatible with each other.
- Better infrastructure for library building. Some of the most exciting work in C++ development today involves template-based programming, even template metaprogramming. By experience, the C++ community has learned that many of these techniques use a few common base components. Many people have independently invented such ideas as type traits classes, compile-time IF, compile-time boolean operations, expression templates, and dispatching on categories. Standardization would mean that people wouldn’t have to waste time on such reinvention and reimplementation.
- Better support for novices. Just as we’ve learned new techniques for C++ programming, so we’ve learned new techniques for teaching C++ [4]. However, there are still some facilities that are too difficult to explain and too easy for a non-expert to use incorrectly. Can these facilities be changed, or at least supplemented by other components that were designed specifically for teaching?
- Support for (some) important application domains. This is a dangerous goal, because it’s not clear where to draw the line. I don’t think we want to have a C++ Standard with packages for molecular dynamics, or accounting, or DSP, or CAD. On the other hand, some application areas are important to a wide range of programmers. Many different kinds of programs need better text processing than we have in the standard library; I think that most of us, for example, have used one of the many third-party regular expression libraries. Nowadays most of us care about networking, and many of us are moving in the direction of distributed programming. High-performance numerics come up again and again. The importance of internationalization, including such character sets as ISO 10646, will only grow. We can’t solve everyone’s problems, but we can try to solve the ones that matter most.
Naturally, this isn’t an exclusive list: sometimes you don’t realize you wanted something until you see it! At least to some extent, we should be opportunistic. By definition, really innovative work will be something that we couldn’t have asked for in advance, something we couldn’t have been expecting. Alex Stepanov’s STL, for example, with its separation of containers and algorithms and with its reliance on abstract requirements rather than on inheritance, was a brilliant innovation in library design. It was recognized as such — but only after people saw it.
What You Can Do
Design by committee rarely works well. The C++ language was largely the invention of one person, Bjarne Stroustrup [5]. With very few exceptions, every major feature of C++ has been the work of one person or of a small group. A standards committee can evaluate, can refine and modify, can accept or reject, but for the most part it can’t invent. We expect that the committee will be looking at proposals presented by others. (Individual committee members can and will contribute proposals, of course, but not the committee itself.)
At the time of writing, the standardization committee hasn’t yet sent out a call for proposals. (By the time you read this, I expect that we will have.) But even though we haven’t asked for proposals yet, we’ve already received some anyway! We started looking at those proposals at this meeting. Here are a few of them:
- C99’s <inttypes.h>. C99 defines a new header, <inttypes.h>, that makes it easier to talk about integer types with specific sizes. It includes typedefs like int_least16_t (the smallest signed integer type that’s at least 16 bits long) and uint32_t (an unsigned integer type that’s exactly 32 bits long; this typedef is undefined if there is no such type). In one sense, of course, this header doesn’t give you anything you didn’t have already. It doesn’t define any new types: the integer types are still short, int, long, and so on. But, if the exact size of a type matters for your program, <inttypes.h> gives you a way to ask for the right type without using ugly #ifdefs. It’s likely that this facility will be adopted into C++: lots of users want it, and C compatibility has been and is an important goal.
- “Smart pointers.” The C++ library defines just one smart pointer class: std::auto_ptr. In some circles, auto_ptr has a bad reputation. My own opinion is that the only real problem with auto_ptr is that it’s overused: it’s the only smart pointer class in the Standard, and a lot of programmers assume that means that they’re supposed to use auto_ptr for everything. It’s a natural assumption, but it’s wrong: auto_ptr was never intended to solve anything but one narrow problem. We need to add some more smart pointer classes, ones that are suitable for a wider range of uses. One very natural possibility, one that’s already in wide use, is Boost’s shared_ptr [6].
- Hash tables. At least three library vendors provide hash tables as an extension. One of the things a standard is supposed to do is reflect existing practice, so this is a natural candidate. The tricky part is that we’ve got multiple almost-compatible implementations. How do we resolve the differences?
We’re still early in this process, and there are many unanswered questions: we’ve received a few proposals, and we’ve given some of them a first look, but we certainly haven’t yet made a definite decision to adopt any of the ones we’ve seen. It’s not too late for new proposals; we’re near the beginning of this process, not the end.
And that, finally, is the important part. All we’ve seen so far is the first crop of proposals. The C++ community is large, and there has been an enormous amount of good work on C++ libraries. We want to standardize the best possible extensions, not just the ones we happen to notice first.
If you’ve done some of that work, if you’ve written something that you would like to see added to the Standard C++ library, now is your chance! We want to see your proposals.
We still need to work out some of the details on how to submit a proposal for a library extension, but a pretty safe bet is that you’ll be able to do it by posting it to the Usenet newsgroup comp.std.c++, and the moderators of that group will forward it to the C++ Standardization Committee as appropriate. Just remember that a proposal should be more than a wish. A proposal should describe something that has actually been implemented; it should solve an important problem; and it should discuss why you made the design decisions that you did.
Keep watching this space! We live in interesting times.
Notes
[1] Andrei Alexandrescu. Modern C++ Design: Generic Programming and Design Patterns Applied (Addison-Wesley, 2001).
[2] This list is largely inspired by Bjarne Stroustrup’s list of future directions. See, for example, the Future Directions for C++ panel discussion at <http://technetcast.ddj.com/tnc_play_stream.html?stream_id=560>.
[3] Not 100 percent compatible, of course; C++ is not a strict superset of C. The unofficial slogan for many years has been “As close to C as possible, but no closer.”
[4] See, for example, Andrew Koenig and Barbara Moo. Accelerated C++ (Addison-Wesley, 2000).
[5] Bjarne Stroustrup. The Design and Evolution of C++ (Addison-Wesley, 1994).
[6] <http://www.boost.org/libs/smart_ptr/index.htm>
Matt Austern is the author of Generic Programming and the STL and the chair of the C++ standardization committee’s library working group. He works at AT&T Labs — Research and can be contacted at [email protected].
