I've just spent most of the past two weeks in a frenzy of code writing. I haven't returned phone calls, my mail has gone unopened, and I face nearly a hundred e-mail messages after I finish this little essay. On the other hand, I got the job done. Last night I shipped off my Standard C++ library to a major compiler vendor, up to date and as complete as current compiler technology permits. By the time you read these words, you'll probably know which one, from their announcement. And within a matter of weeks thereafter, you should actually be able to see the finished product.
I know it sounds like poor planning to work so hard just before final delivery, but it's not entirely my fault. The March meeting of the ANSI/ISO C++ standards committees indulged in another binge of changes. They passed about five dozen resolutions that alter the draft, roughly double the usual number. Over half of these apply to the library.
That's not quite as bad as it sounds. The committees are still processing public review comments from their first ISO Committee Draft ballot. Many of the resolutions simply endorse small changes and corrections suggested by those comments. I can't complain about those, because a significant fraction of the comments are mine, and I mostly got what I want.
I feel I can complain about some of the remaining resolutions, however. Several of them simply add still more inventions to an already inventive draft. It's hard to find justification for these additions in the comments that nominally drive all remaining changes, but that doesn't seem to deter most committee members.
What I have real trouble with are the untested inventions that keep finding their way into the draft. One proposal, born scant weeks before being voted in, originally called for a member function called register. You can guess how well it was exercised at that point. Another proposal resulted in sweeping changes to the internals of the Standard Template Library. Its primary visible effect is to change the return type of two or three template functions. That proposal ends with the bald caveat, "Note that although we believe this code to be correct, we have not tested it: we do not have access to a compiler that supports partial specialization."
And so it goes. Having said all that, I do concede that the process of standardizing C++ is converging. Both language and library change relatively slowly these days, certainly compared to the heady days of the early "standardization" effort. At least now vendors and sophisticated customers have the sense that Standard C++ is a target worth aiming for. But I'll be glad when I don't have to spend three fortnights a year tracking this moving target.
P.J. Plauger
Senior Editor