The draft C++ Standard passes another important milestone, and our intrepid columnist helps tidy it up a bit more on the way by.
Copyright © 1997 by Dan Saks
I concluded last month by telling you I would have more to say about the new and delete operators. I do. However, what I have to say has been influenced by my experiences at the most recent C++ standards committee meeting, so I'd like to share those experiences with you.
The committee met during the second week of November 1996 in Waikoloa on the Big Island of Hawaii. The reason we met there was that our host, Plum Hall Inc., is located in nearby Kamuela. (Committee members take turns hosting meetings at sites near their offices.) Apparently, a number of our members could not make the meeting because their managers were suspicious that business meetings in Hawaii aren't really business meetings. (I wonder what gives them that idea.) I can't speak for everyone, but I know that many of us did put in full work days, and then some. Honest.
For the C++ community, the single biggest outcome of the meeting was that we voted to submit the draft C++ standard for a committee draft (CD) ballot. CD ballot is the second of three ballots that a draft must pass before it becomes an international standard (IS). This CD ballot offers another opportunity for the public (that's you) to comment on the draft.
For me, the November meeting marked the end of my tenure as secretary. After 6-1/2 years and 20 committee meetings, I realized that the thrill was gone, so I resigned. (The normal tour of duty for officers in standards committees is three years.) I will continue to attend standards committee meetings, but I will be much less involved with administrivia. I will have more time to participate in the technical goings on. I will also allow myself an occasional game of FreeCell while the meeting is in progress, a luxury I could never afford as secretary.
CD Ballot and Public Review
As you've no doubt surmised by now, developing an international standards for a programming language is a slow process. This is especially true when the standards committee meets only three times a year. It doesn't help if the language starts out big, and the committee makes it bigger.
The ANSI C++ standards committee X3J16 held its first meeting in December, 1989. The ISO working group WG21 started meeting simultaneously with X3J16 in June, 1991. It was not until July, 1994 that WG21 submitted the working draft for the first round of balloting, called CD Registration. (See the Editor's Forum, CUJ, September 1994.) I explained the alphanumeric soup of programming language standards organizations in an earlier article. (See "Stepping Up to C++: C++ at CD Registration", CUJ, January 1995). Table 1 summarizes the code names that apply to C++.
The current CD ballot is the second one for C++. WG21 submitted the draft for its first CD ballot in March, 1995. (See the Editor's Forum, CUJ, May 1995.) The draft didn't fare well in that ballot, which is why we're at it again.
It is WG21 (not X3J16) that submits the draft for balloting. CD balloting is an international procedure that takes place among the national standards bodies that are members of JTC1/SC22. WG21 sends the draft to SC22, which attaches the ballot to the draft and passes it on to each SC22 member. Each national body then has some number of months to review the draft before accepting or rejecting it. The acceptance criteria becomes increasingly more rigid with each ensuing ballot stage.
Each national body has its own procedures for determining its vote on the CD. In the US, X3 makes the draft available for public review and comment. During the review, anyone in the US can submit comments on the draft, which X3 factors into its decision.
Although X3 actually casts the ballot, it seeks advice from a technical advisory group (TAG). The US TAG for C++ is none other than the US-domiciled members of X3J16. (X3 technical committees have members from all over the world. They just can't participate in shaping the US position on international standards.)
X3 forwards public review comments to the US TAG, which in turn mulls them over and drafts a written response to each one. The US TAG then advises X3 on how to vote on the CD ballot. It is unlikely that X3 will vote contrary to that advice.
If you want to review the draft, you will need a copy of it. During the last public review, the draft was available on various public web and ftp sites. It's not clear if the draft will be so freely available this time around. Your only option may be to purchase a copy from X3 or some other national standards body. See the information at the end of this article for help in finding a dealer near you.
How Did It Get So Big?
If you do review the draft and submit comments, I suspect the US TAG will not look favorably upon comments requesting additional language or library features. Yes, there are all sorts of goodies that might be helpful to some programmers, but C++ is already too big and in danger of buckling under its own weight. I believe the C++ committee is no longer inclined to make either the language or library bigger.
The first draft C++ Standard, based on AT&T's C++ Product Reference Manual (PRM)[1] , described the C++ language in a mere 135 letter-size (8-1/2" x 11") pages (excluding the table of contents and index). It contained no library specification. The widely available Annotated C++ Reference Manual (ARM)[2] uses essentially the same words as the PRM, but with additional commentary.
The draft C++ Standard has since grown into a hefty document. The current draft consists of more than 680 letter-size pages (again excluding the table of contents and index) using essentially the same typefaces as the PRM. Roughly 340 pages describe the language; the other half describes the library.
It is highly unlikely that anyone on the committee, or anyone in the world, understands everything that's in the draft. Most people seem to content themselves by mastering either the language or the library, but not both.
From the beginning, the committee has conducted much of its technical work in subgroups. For the past two years, there have been six subgroups — three devoted to language issues, and three devoted to library issues. For the most part, committee members seem to stay mostly on the language side or on the library side of things, crossing over only occasionally. My interest in C++ compiler testing has kept me focused on language issues. My fellow columnists Chuck Allison, Pete Becker, and P.J. Plauger all work in library subgroups. Pete chairs one of them.
How did the draft get so big? Well, certainly adding new language features had something to do with it, but not as much as you might expect. During its first four years, the committee added templates, exceptions, run-time type information, namespaces, new-style casts, and a boolean type to C++. Yet, by May 1994, the language portion of the draft had grown to only (only?) 235 pages.
The other 105 pages came from filling in the details. The base document (the PRM) was rather vague about many language details, and completely silent about others. Two of the three language subgroups have spent much of the last six years just filling in those missing details. The other language subgroup has been fixing flaws in the earlier specifications of the language extensions. 105 pages worth of details is a lot of details.
As of May 1994, the library specification was only about 215 pages. In July 1994, the committee went on its last big binge and added the Standard Template Library (STL) to the draft C++ Standard. Although the STL components displaced some older library components, the STL still increased the library specification by more than fifty percent. The resulting shock wave is still rattling much of the library.
Some Personal Observations
So what's this got to do with what I have to write about new and delete expressions? As part of the research for my writing, I participated in the subgroup(s) that were addressing unresolved problems regarding new and delete. (Going into the meeting, the committee had a list of five or six open issues regarding new and delete, and dozens more regarding other parts of the language.) We discussed how to fix most of the problems, but had to leave a few open for lack of time.
I offered to rewrite the sentences in the draft to correct the known problems in new and delete. In the course of editing, I discovered quite a number of other minor problems. Again for lack of time, we simply could not address the problems this time around. Those flaws remain in the draft that will be available for public review.
For example, in a new expression such as
p = new T;T is the type of the object created by the new expression. Of course, we all know this is so, but the draft never says so explicitly. You can infer this from the text and examples, but I don't think you should have to do so.
Syntactically, T is something called a new-type-id. A new-type-id is similar to the more general type-id construct defined in another section of the draft. The draft is fairly clear that a type-id specifies a type, but it never says explicitly that a new-type-id also specifies a type. Again, you can infer this from surrounding statements and examples, but you shouldn't have to.
Last month, I explained that a new expression that creates a single object of type T implicitly calls a function named operator new to allocate storage for the object. A new expression that creates an array of T calls a function named operator new[] to allocate storage. What I didn't tell you, but I'll explain later in the next month or so, is that operator new and operator new[] can be class members as well as global functions. Thus, for every new expression, the compiler must look up the name operator new or operator new[] in different scopes to select the one it will call. A similar situation holds for delete expressions, operator delete, and operator delete[].
The lookup rules appear to be pretty simple. Unfortunately, the draft describes them in several different places, and each description is just different enough from the others to be disconcerting. Moreover, in most places, the draft says the result of one of these lookups must be unambiguous (must find exactly one function). In at least one place, the draft omits the ambiguity check. Again, it's probably just an oversight, and "we all know" what the rule is supposed to be, but it's unsettling nonetheless.
None of the flaws I've described is a show-stopper. However, this is only a small sample of the flaws. When you add up all these glitches, they turn reading the draft into a bigger chore than it has to be.
As I delve into the details of new and delete, or just about any other part of C++, I will have to take pains to distinguish that which is well-established from that which is still a bit uncertain. I will try to provide you with practical guidance on what you can rely on, and what you should avoid.
I don't want to be entirely negative here. Without a doubt, the draft is much clearer and more precise than it was years ago, and it keeps getting better. C++ is clearly a presence in the software marketplace, and this draft, despite it flaws, will improve the quality of much of what we do. And it is, after all, still only a draft. The final round of balloting (DIS ballot) is still at least a year away. That gives us some time to fix a lot of these problems. No matter how hard we work, the formal standard will still have flaws in it. That's just life. After the draft becomes a standard (probably late in 1998), we'll just continue handling problems through defect reports.
Whom to Contact
If you want to participate in the US public review of the draft C++ standard, try contacting:
X3 Secretariat, ITI
1250 Eye Street NW, Suite 200
Washington DC 20005-3922 USA
+1-202-626-5740
Readers outside the US should try contacting their national standards bodies. Here's a sampling:AFNOR - (France)
BSI - (UK)
DIN - (Germany)
ITSCJ - (Japan)
SANZ - (New Zealand)
SCC -(Canada)
SA - (Australia)If you need assistance locating your national standards body, try contacting:
William C. Rinehuls
SC22 Secretariat
8457 Rushing Creek Court
Springfield, VA 22153 USA
+1-703-912-9680
+1-703-912-2973 (fax)
rinehuls@access.digex.net
WG21+X3J16 will meet three times in 1997:
- March 9-14 in Nashua, NH, USA, hosted by Digital
- July 13-18 in Guilford (near London), UK, hosted by Programming Research
- November 9-14 somewhere in New Jersey, USA, hosted by AT&T Research
If you would like to participate in the C++ standards process as a member of X3J16, contact the vice-chair:
William M. (Mike) Miller
Software Emancipation Technology, Inc.
Kiln Brook V
20 Maguire Road
Lexington, MA 02173-0843 USA
+1-617-863-8900
+1-617-863-5441 (fax)
wmm@world.std.com oReferences
[1] AT&T C++ Language System Release 2.1, Product Reference Manual. (AT&T, 1989).
[2] Margaret A. Ellis and Bjarne Stroustrup. The Annotated C++ Reference Manual (Addison-Wesley, 1990).
Dan Saks is the president of Saks & Associates, which offers training and consulting in C++ and C. He is active in C++ standards, having served nearly 7 years as secretary of the ANSI and ISO C++ standards committees. Dan is coauthor of C++ Programming Guidelines, and codeveloper of the Plum Hall Validation Suite for C++ (both with Thomas Plum). You can reach him at 393 Leander Dr., Springfield, OH 45504- 4906 USA, by phone at +1-937-324-3601, or electronically at dsaks@wittenberg.edu.