C/C++ Users Journal July, 2005
I'm still getting caught up after several weeks in Europe. Not all of it was Standards meetings, to be sure, but even being a tourist is hard work. And the mail stacks up whatever the reason you're not there to open it on a daily basis. Travel definitely has its pluses, but I suspect it's one of the major barriers to getting software done and out the door.
Last month I reported on the C Standards meeting in Lillehammer, Norway, one of the busier I've attended in recent years. Now I have to report that the C++ meeting that followed it was equally active. We wrapped up an important project, processed more than a few Defect Reports, and did some serious planning for the rest of the decade.
The serious project was the Library Technical Report, more succinctly known as "TR1." I've mentioned this more than once on this page, and Pete Becker now has an ongoing series of columns on TR1. You can also find an overview of TR1 by Matt Austern in the June 2005 issue of Dr. Dobb's Journal. All that coverage should give you a hint as to its importance—TR1 represents the first major addition to the Standard C++ Library since the C++ Standard was approved in 1998.
There's a lot to it. A number of pieces can be categorized as template metaprogramming aids—the kind of things you find yourself needing once you discover the true magic and power of templates. Others have more targeted applications, such as regular expression matching, high-quality random-number generation, and good old hash tables (which didn't quite make the cut for the C++ Standard). These pieces alone add up to quite a bit, but there are two more major components. One is a set of "special math" functions—Bessels, elliptic integrals, and that sort of thing—which are very hard to write at all well. The other is a great long list of additions needed to reconcile the Standard C++ Library with the C99 library.
TR1 is not officially required for an implementation to call itself Standard C++. Officially it's called a "nonnormative" TR. But I think you'll find that a number of compilers will soon be offering at least pieces of it. The recently released GCC 4.0, for example, includes preliminary versions of some TR1 features. Still more pieces are available from Boost (http://www.boost.org/), which supplied the "prior art" for parts of TR1. My company, Dinkumware Ltd., has spent over two years writing a commercial version of all this stuff. It helped that we already had the C99 bits, but we still devoted much of our limited development resources to this one project. The good news is we're almost done, and we'll have complete support for TR1 available soon.
Officially, TR1 has another round of balloting to go before it's approved. But the last ballot closed with no public comment, a rare occurrence. And the Library Subcommittee made only minor fixes to the text. So the spec is stable and it's time to start building experience among C++ programmers.
That's the purpose of a nonnormative TR, you see. We know, from bitter experience, what happens when things get formally standardized before they're well exercised in the field. You get required features that are impractical to implement, or worse, impractical to use. And a standards committee can only repair so much through the mechanism of Defect Reports. Far better to standardize only what's proved to be useful by working programmers.
And that feeds into the serious planning I mentioned earlier. The C++ committee has begun the process of nailing down what should go into the next version of the C++ Standard. For years we've been tossing around the cryptic term "C++0X." It represents an implicit promise that the next version of the C++ Standard will be approved before 2010. (The C committee did much the same through the 1990s with C0X, which luckily crystallized out as C99.) Working backwards, we've begun to accept what has to be done, and when, if we want to produce a C++09. Equally important, we've begun to accept what we're not likely to get done if we're to preserve the zero in that name. It's a sobering exercise.
As Bjarne Stroustrup recently described in "The Design of C++0x" (CUJ, May 2005), the C++ committee already has a long list of candidates for "improving" C++. Over the coming year, we'll prune that list, and try to identify a coherent set of changes that play well together. If your favorite feature doesn't make the cut, remember that we have to stop somewhere. And we're already planning for TR2.
P.J. Plauger
Senior Contributing Editor
pjp@plauger.com