Columns

Standard C

Developing the Standard C++ Library

P.J. Plauger

P.J. Plauger is senior editor of The C Users Journal. He is convenor of the ISO C standards committee, WG14, and active on the C++ committee, WG21. His latest books are The Standard C Library, published by Prentice-Hall, and ANSI and ISO Standard C (with Jim Brodie), published by Microsoft Press, and Programming on Purpose (three volumes), published by Prentice-Hall. You can reach him at pjp@plaugher.com.

Background

My approach to learning a programming language is to write a compiler for it. I admit this is somewhat unorthodox, but it has always worked for me. True, my first two C compilers were hardly of production quality. But by the time I got the third one working, I had something with some commercial merit. Not only that, I felt I really understood C by then.

That approach has not worked for me with C++. On several occasions over the past eight years, I've sat myself down with the time and energy available to write at least a rough and ready C++ compiler. It was never long before I ran into some quagmire of complexity of appalling extent. Even if I could see a path to the other side of the swamp, I despaired of holding my nose against the stench long enough to make it across.

So I have resigned myself to never being the author of a C++ compiler. (I'm hardly alone. I estimate that perhaps 100 production quality C compilers were written by the mid 1980s. The number of distinct and marketable C++ compilers today, at a similar point of language maturity, is probably under ten.) And that, to me, means that I will never be as adept a C++ language lawyer as I am with C.

My one advantage is that C++ is based heavily on C. Where C++ experts know how they want the newer language to work, I know how it has to work in many cases. (Still, I have learned to keep my peace. See my Editor's Forum, CUJ August 1993.)

Despite the malodorous imagery above, I don't mean to imply that C++ is nothing but a swamp. It demonstrably has its adherents and its uses. It also has its implementors. People who like writing C++ compilers delight in complexity much the way we C implementors delighted in minimalism. There's no question, however, that either aesthetic can lead to tools that are of use to others. They simply present different shortcomings.

I find myself using C++ more with each passing day. But I do so with a Cajun respect for my environment. I learn how to spot safe paths among the perils when the light is good. And I stick to known paths the rest of the time. The swamp may not be your friend, but it doesn't have to be your enemy either.

Existing C++ Libraries

One path I'm comfortable following is through the realm of libraries. It is often the case with modern programming languages that the library supplied with a translator is about as important as the language itself. Input and output are essential operations to nearly all programs — sets of library functions cooperate to perform I/O nowadays, rather than funny statements embedded directly in the language. Similarly, most complex operations have migrated out of the language into support libraries. String manipulations and nontrivial data conversions are two representative examples.

I observed some time ago that the fundamental references on C++ say next to nothing about the library that accompanies a typical C++ compiler. The Annotated C++ Reference Manual, (see reference [1] in the Bibliography at the end of this article) is one of the two base documents for the draft C++ standard. It contains hardly more than a sentence on the subject of libraries. The other base document is the ISO C Standard [3]. It, naturally, describes only the library that C++ inherits from Standard C.

Stroustrup's own description of C++ [2] has a chapter on iostreams, the set of classes that conspire to provide strongly typed I/O for many C++ programs. But that is more anecdotal than a complete reference. His book also has a chapter on constructing libraries in general. But even the language reference manual at the end says little about what comes with C++.

More recently, Steve Teale has published a book [5] describing iostreams in some detail. It covers the subject in considerably more depth than anything that has gone before. I was thus disappointed to find that he had fixated on an earlier version of iostreams. Its resemblance to what's currently in the C++ draft standard is often only superficial. Still, you won't find a more thorough overview of iostreams in any other book that I know of today.

Nature abhors a vacuum. Though it is filling slowly, a vacuum still exists in the description of the library that comes with a typical C++ compiler. That means, of course, that no adequate base document exists for describing the library in the draft C++ standard. It means, in fact, that we are still not entirely sure what all will be in the Standard C++ library. So that's where I have been focusing most of my energies these days.

I admit to a selfish reason for making progress in this area. I have had good success with an earlier book on the Standard C library [4] and the code that goes with it. I am now under contract with Prentice-Hall to produce a similar book on the Standard C++ library (whatever that is). And I intend to produce one or more related software products. I can do none of that, however, until I have a better notion of where the C++ standard is going in the area of libraries.

The Library Working Group

C++ is being standardized by a joint ANSI/ISO committee. The ANSI part is called X3J16, the ISO part JTC1/SC22/WG21, or WG21 for short. X3J16/WG21 meets every four months for a week, somewhere in the world. Practically every waking hour of that week is consumed with technical presentations, debates, and reviews. Between meetings, people prepare and read position papers, argue endlessly on e-mail reflectors, and try out various bright ideas with real live code.

All this activity is comparable in intensity to what X3J11 put into developing the C++ Standard for ANSI. (It is now the ISO Standard [3] mentioned earlier.) One difference is, C++ is a much more complex language that C, by practically any metric. Another difference is that the joint committee continues to evolve the C++ language, adding major features at the rate of at least one per year. One result is that after four years of standardization effort, the C++ draft standard is not as far along as the draft C standard was after two years of effort. (The biggest change X3J11 made to C, I believe, was to add function prototypes. And we got that out of the way early on.)

The e-mail reflectors are a help. They at least expose many issues to debate between meetings. (People are still annoyed to find they have to repeat these debates face to face, however.) Another big help is parallel sessions at the meetings. X3J11 worked almost exclusively as a single committee of the whole. The joint committee, by contrast, spends much of its meeting time working in specialized subgroups.

Since returning from my year in Australia at the end of 1991, I have attended the past five meetings of X3J16/WG21. At all of those meetings, I have participated in meetings of just the Library Working Group (or LWG). The Chair of the LWG is Mike Vilot of ObjectCraft in Nashua, NH. Mike has worked with Grady Booch, and is the author of an excellent book on the Booch Components written in C++ [6]. He has kept the LWG focused, as best he can, on determining first the scope, then the details, of what will be the Standard C++ library.

Also active on the LWG (among others) is Jerry Schwarz, creator of iostreams. Jerry has seen this important subsystem through several generations of evolution. Most important of all, he has helped shape the version that will become standardized along with the C++ language. I doubt that anybody else besides Jerry could have made the necessary technical, and political, decisions about what to change and what to keep the same in standardizing iostreams.

I don't mean to slight the other active participants in the LWG by citing these two. Equally, I don't want to try to denumerate all who have contributed — that's a sure way to slight whomever I overlook. So let me drop just one more name. Our own Chuck Allison, who writes the monthly "Code Capsules" column, has been a regular participant since before I rejoined the effort. Chuck, in fact, chaired the LWG at the August meeting in Munich in Mike Vilot's absence.

Shape of the C++ Library

So much for organizational matters. Let's look at how the Standard C++ library itself is organized. Long before I became active again, the LWG had settled on a broad structure for the library:

(1) The Standard C library, the functions you know and love, but suitably amended to meet any special requirements of a C++ environment

(2) Language support, those functions called implicitly by expressions or statements you write in a C++ program

(3) iostreams, the extensive collection of classes and functions that provide strongly typed I/O

(4) Support classes, classes like string and (perhaps) complex that pop up in some form in every library shipped with a C++ compiler

To this list, I insist on prepending:

(0) Introduction, the ground rules for implementing and using the Standard C++ library

As of the March 1992 meeting in London, none of these components had been voted into the Working Draft (the currently accepted version of the draft C++ standard). The LWG was taking a certain amount of heat because of this, unfairly in my estimation. Remember that the library alone, of all the major components of the eventual C++ standard, began with no base document to speak of. It had taken the LWG two years just to feel out the scope of the problem and to work up preliminary drafts of some of the components.

Since that time, the joint committee has voted to accept proposals for pretty much all of (1) the Standard C library, (2) language support, and (3) iostreams — at least to date. Each of these components is still subject to varying degrees of amendment. The joint committee has also accepted a number of components for (4) support classes. These include, to date:

I'd call that pretty steady progress. The problems now are to decide how much more to add before quitting, to get that stuff added, and then to get the whole works boiled down to good standards language for inclusion in the Working Draft. All of these decisions are strongly colored by an ever tightening schedule. Only three meetings remain before the joint committee is supposed to release the Working Draft for its first real public scrutiny (in July 1994, that is). That's not much time.

At the Munich meeting, I felt we made real progress on all these remaining areas. Under Chuck Allison's guidance, we made a harsh evaluation of how much more we could take on in the way of additions to the library. We made even harsher evaluations of how badly we needed various desirable additions. And we laid plans for getting caught up on wording.

As I mentioned separately in my Editor's Forum in this issue, I have put a lot of effort personally into translating all the library proposals to date into uniform standardese. That amounts to well over 100 pages, even in the dense format of the Working Draft. My task now is to keep editing that draft, in response to criticism from the LWG and other interested parties, until it is generally acceptable. If I succeed, then I can pass the result on to Andy Koenig, the official project editor for the joint committee, for him to revise as he sees fit and include in the Working Draft.

An important side effect of this effort is that it provides a draft of component (0), introduction. I did my best to distill out the relevant principles from the Standard C library, suitably amended for the peculiar needs of C++. Already, that work has stimulated several useful discussions on the library reflector. I'm hoping that we can reach agreement soon on how much latitude implementors can expect in implementing this library. That strongly colors how much latitude users have in writing portable code that uses the library.

Disagreements

I don't want to create any false impressions. The foregoing overview reads like the LWG speaks with one voice and has a clear vision of where it's going. That is far from the truth. Standards just don't get developed that way. Any time you put three score very intelligent and opinionated experts in one room, you can expect more disagreement than harmony. (I find it a miracle that standards get hammered out at all, given the raw ingredients that go into them. Nevertheless, they do more often than not.)

Not everyone agrees with everything that's currently in the library draft standard. Some favor stripping it down to its bare essentials (perhaps (0), (1), (2), and (3) in their current forms). Leave the rest, they say, for a separate C++ Library Standard that can address the numerous design issues properly. Let's focus our energies for now on giving people what they need, an adequate C++ standard as soon as possible.

Others dislike the notion that the library will be anything less than complete. Definitions of "complete" naturally vary all over the map, but practically all go much farther than the LWG has gone to date. Most go farther than the LWG decided it can probably go at the Munich meeting. I know from experience that the drafting of standards encourages invention. Shutting down those inventive urges takes an effort of will. I see the joint committee as just starting to exercise that sort of effort.

A significant fraction of the joint committee has no faith in the published schedule at all. They see no need to start tightening the screws in any one area, not if several other areas of the C++ standard won't be ready on time. Of course, arguments like that lead to projects that never get done. There's always somebody else who's responsible for the current slippage, so it's okay if we slip for awhile.

I believe, in fact, that some fraction of this fraction doesn't even want a schedule they can have faith in. These are people who'd rather just get together every four months for the rest of whatever and swap lore about the latest ideas in C++ language evolution. Hard cheese for them — they've gotten caught up in a process that takes deadlines seriously.

And of course, as I've indicated in the Editor's Forum, not everyone is happy to see a thumping great chunk of wording handed to them with little or no warning. I do not take it as a foregone conclusion that the words I wrote will find their way into the Working Draft.

What Happens Next

Disagreements or no, the LWG has to keep moving forward. The next joint meeting is in San Jose CA, 8-12 November 1993. At that meeting, I expect the LWG will have more than one proposal to consider on how to extend iostreams to handle streams of wide characters. UNICODE is already a part of Windows NT and a few other significant operating systems. ISO insists that its standardized form, called ISO 10646, be supported properly by future programming language standards. The pressure is strong to make "wide streams" a part of the Standard C++ library.

I also expect to see lots of proposals for additional support classes. Those who take seriously the decision reached at Munich feel this will be the last opportunity to carve out a niche in the C++ library for their favorite addition. Even if the door doesn't slam shut, it will certainly be harder to get through with new proposals after the November meeting.

For my part, I plan to use this column to explore the Standard C++ library in greater detail. You've seen some of the history and the politics. Now it's time to get into the technical nitty gritty. Starting next month, that is.

Bibliography

[1] Margaret A. Ellis and Bjarne Stroustrup, The Annotated C++ Reference Manual, Addison-Wesley, 1990.

[2] Bjarne Stroustrup, The C++ Programming Language, Second Edition, Addison-Wesley, 1991.

[3] ISO/IEC 9899:1990, International Standard for Programming Language C, 1990.

[4] P.J. Plauger, The Standard C Library, Prentice-Hall, 1992.

[5] Steve Teale, C++ IOStreams Handbook, Addison-Wesley, 1993.

[6] Mike Vilot, C++ Programming PowerPack, Sams Publishing, 1993.