(c) © 1997-2013 Comeau Computing. All Rights Reserved.

Comeau Computing Home Comeau Computing's Executive Summary of ANSI/ISO C++ Meetings

The below contains a summary for the following ANSI/ISO C++ Meetings:
  1. Nashua NH, US, March 1997
  2. Chiswick, UK, July 1997
  3. Morristown NJ, US, November 1997
  4. Nice, France, March 1998
  5. Santa Cruz CA, US, October 1998
  6. Dublin IR, April 1999
  7. Kona HI, US, October 1999
  8. Tokyo, Japan, April 2000
  9. Toronto, Canada, October 2000
  10. Copenhagen, Denmark, April 2001
  11. Redmond, WA, US, October 2001

Comeau Computing.
Copyright © Comeau Computing. All rights reserved.
Revised: July, 2013

Nashua, US, March 1997

On March 18, 1997, Greg Comeau provided an executive summary of the C++ committee's meeting in Nashua, NH to a local New York user group (see the Comeau C++ Resources Page for more information). The following information is a 1:1 HTML version of the MS-PowerPoint presentation slides used. We hope you find it useful in understanding some of the standards process as well as in determining the status of the standard.

"CD2" in Nov 1996, Now What?

Executive Summary Of The ANSI/ISO C++ Meeting In Nashua, NH

Greg Comeau, Comeau Computing

First, a few words on Logistics

Please Note: Any use, redistribution, copying, taping, rebroadcasting, or transcriptions, of any form or fashion, of this lecture, or of any related handout material, is expressly forbidden without the express written consent of Comeau Computing. Individuals present in this room, or with handout material explicitly provided to them by license from Comeau Computing, may only use this information provided it is for the strict personal, private and non-commercial use of that individual. Any performance or reperformance of this lecture, in whole or in part, is expressly forbidden without the express written permission of Comeau Computing. For licensing course material, or for other questions or concerns, contact us at: Comeau Computing 91-34 120th Street Richmond Hill, NY 11418-3214 718-945-0009, http://www.comeaucomputing.com comeaucomputing@gmail.com

Can you hear me?




"First Things First, But Not Necessarily in That Order"


Who attends a C++ meeting?

"Slang" Quickie

"Slang" Quickie (more)

General Meeting information

Effective General Flow of a Typical Meeting

Significant Recent Meeting

What CD2 does not mean:

Flow of meeting in Nashua, NH

What does quiet mean?

What does this categorization mean?

What is the impact of this?

From this point on: any major changes, or suggestions thereof, to the draft would probably mean that CD2 would be prevented from being adopted as the DIS.

A Good Thing

Status of the Standard

Status of the CD

Possibly read: "Yes, we would like to see CD2 advanced to DIS status, and here are our comments for things we would like to see fixed."


Practical significance:

What next:

Where to get additional information:

This presentation will be posted to the Comeau Computing WEB page tomorrow (as copyrighted HTML) located at: http://www.comeaucomputing.com.

Additional Information

Back to Top

Chiswick, UK, July 1997

At this meeting, lots of assorted work was done in order to address comments from National Bodies such as France, Germany, UK, etc. This was significant because the remaining open issues needed to be rectified in order for CD2 to move into FDIS status.

For instance, an issue which came up was the status of the Standard C library within C++ programs. In specific, should C names from <stdio.h> or <cstdio> such as printf belong in the global namespace as ::printf or in the the std namespace as std::printf? It was confirmed that so-called .h style headers should use the global namespace and so-called cname headers should use the std namespace. The preference is the cname forms unless strict compatibility with C is needed. Personally, we feel that this will be a muddled issue for many years to come. It'll be interesting to see if we've seen the last on this.

Back to Top

Morristown, US, November 1997

Back to Top

Nice, France, March 1998

What follows is a very loose discussion followed by an executive summary of the Nice meeting.

This was a strange meeting. This is to say, the technical experts voted out the Standard at the last meeting and so things were now stuck in a bureaucratic phase of approval. This meant that the committee formally could not work on things like DRs since the document was still not bureaucratically approved, so things were somewhat circular.

In any event, this gave the committee an opportunity to take a deep breath. It also gave the committee a comfortably paced opportunity to consider what the future will hold and what waters should be charted or not.

FYI, at this point the FDIS Status was that it was not out in ballot yet, but would be shortly. It was noted that the CD1 ballot period for C9x would be closing on April 7 (there were some 300 comments and paper "10176" needs interpretation from WG20). C9X expects a final CD this year, after June meeting, with hopefully FDIS bureaucracy approval in 99.

It was decided that for now, the committee should move from meeting 3 times a year to two times a year, around April and October, effectively meaning there would no longer be a July meeting, at least for now. Probably too, it would be interesting to see the C and C++ committees co-locate their meetings. This might increase the quality and understanding of both standards.

A common consideration was that "C++ needs stability, and that should reign over the committee doing new things."

As mentioned above, things were still in an unclear state ISO-wise, nevertheless, it was considered useful to expect that DRs would be incorporated in the working paper in about 2-3 years.

Some discussion about ISO copyrights and their revenue streams was brought forth. Standard organizations' budgets are not outrageous, and upon DIS, ISO asserts copyright and feels obliged to go after offenders. Some argued that the criteria used by some standards organizations was "unimaginative" about what the so-called price per page should be.

It was also raised that the ISO Council voted to assert that ISO hold a copyright on every WG "N#" document number. JTC1 asked for a 1 year extension to study this. Result: all SC's reported it has worked well for each JTC to determine its own distribution issues, and so one year was not long enough, and so asked for a few more years. Suffice it to say that some of this is confusing (we also feel some of it is bogus but so be it for now).

Although our document is now a DIS, it's not yet available on paper (see above). To see it quickly for now, then you must join the standards body. Next year national bodies (ANSI, etc) will sell you a copy.

Some discussion took place about:

Possibilities for TRs might include: hash tables, garbage collection, embedded systems. It was agreed that if this were to go forward that we would need to produce proposals, but that now was not time to ask the committee to vote on anything yet. Just talking is good.

Things moved along to discuss DRs. It was considered that we should begin to process DRs soon, say for next year or so. However, that process must not be a back door to extensions. Furthermore, we should start to discuss what new work items/areas we might wish to bring up. It would certainly be too premature right now to raise it otherwise, hence let's just start to identify future work items.

Of course, in order to be successful at not being hasty, the committee needs to be sure they understand the direction of the language before making extensions, etc. To wit, they need knowledge of the sum of things proposed along with a history et al. Before we start, we should do things like tech sessions for a year. Then, before we vote, maintain a view. Some of the problems of the users is that vendors adopted the issues in a different order. We might be able to clarify that better, and we can make suggestions for portability. For instance, perhaps issues should be forwarded to to comp.std.c++?

At this point it was noted that a message arrived that ISO finally received the final proof of the draft and that balloting will go out by the end of this month.

Discussion turned to wondering if C could document their "known" incompatibilities with C++ (with realization that no guarantee can be created by the process since C9x was still a work in progress). In short, the C committee was meeting again and there was not complete coordination, etc, between the two committees. Hence we therefore don't know what the incompatibilities are, and don't have the expertise yet to document them on our side yet. For instance, consider this possible proposal: In view of the number of new features in CD9899 ("C9X") which are orthogonal to the C++ Features in FDIS 14882, WG21 requests that SC22 affirm that WG21 (C++) will not necessarily be required to adopt C9X features in future revisions of C++. Requesting this passed J16, and WG21

This was clearly both a technical and political issue that perhaps could be looked into. And there were realities such as that C9x was never obliged to heed the C liaison from the C++ committee, and so on. It was noted that there are facilities in C that are solved in C++ in a different way. There is enough history to back this up. For instance, consider that the new ways of initialization proposed in C9x would not be necessary if C had constructors. But -- big but -- C was not obliged to heed the C++ liaison. But the C9x people support this latter point: they never thought they were undertaking the features for the 5 year revision period for C++. This is significant because there will soon no longer be a C89 standard. But the C++ standard does not incorporate C be reference, but by inclusion. We may therefore want to create a C document of some sort.

There was a minor discussion about a new topic, that of pursing some sort of Embedded Systems proposal. The sense of the committee is that they did not yet know what should be looked at, but at least looking was a direction they wanted to pursue.

The committee then resumed discussion about the future. It was raised:

Some thought there should be no TR before a year. As people do stuff, they therefore make existing practice, and only then is it appropriate to bring it to the committee. In the meantime, the committee needs to demonstrate stability. It was then asked where would C9X numerics fit in? Also, it was mentioned that we have a unique opportunity wrt future extensions, that is, to try and implement library extensions before standardizing them. This opportunity is appetizing. We really want "user experience reports" to see what we can learn about what works and doesn't in things such as STL as it now stands. That is, first, this should not be an attempt to standardize, but to learn from it. We will have gained a lot. Furthermore, increased consistency cannot be done by subtraction. And adding arbitrary extensions w/o a clear view of where C++ should go is not a good idea. We need a vision. We need to allow ourselves a clear guideline on which extensions are acceptable.

This of course begs the question of: What mechanism(s) can be available to expose libs to the world so that may later be considered for standardization? Well, some felt that the ISO C++ committee should not be the committee to provide that mechanism. Let's keep on the standardization hat and let other wear the invention hat. That said, it was raised that wrt TRs, it's important for WG21 (the C++ committee) to get the ideas debated. People who are interested can look at it, else don't. It should also be noted that TRs have no "legal" basis per se. Of course too, something should wait till it is concrete enough before coming to the committee if at all possible. The committee's job should not be in the experimental parts. As such, let a TR follow the experience. C++'s design is very pragmatic, and always was. So we need to listen to users, to solve their problems. An artist won't paint a picture from a vision, but from a sketch book.

The committee then ensued on various mock situations w.r.t. DRs and how the process might actually occur, since DRs are a new thing for the committee.

Here's an executive summary of the Nice meeting:

Back to Top

Santa Cruz, US, October 1998

This was a three day meeting. For the most part, the purpose of this meeting was to consider questions and comments about the defect stage, and how we would handle such reports.

The committee discussed the issue of the practicality of making the core and library issues lists public. It was felt that since there was finally a Standard that problems should be able to be tracked externally. Points were raised about how soon the list should be made public and how soon specific issues should be made public. (Do realize that at this point there is no list.) The general consensus seemed to be that we should get as much info out there as possible w/o being misleading.

In short, there was still NO Defect Reports yet, but technical progress occurred as well as investigating a chain of command and processing when DRs finally do start coming in. As well, the Performance subgroup seems to be finding itself well. Some details follow.

The committee looked at some major core language issues:

Some minor core issues included:

Some Library Issues:

The committee established a subgroup to consider the issue of a Performance TR. Their issues included:

Back to Top

Dublin IR, April 1999

It's interesting to note that in Morristown some folks felt that the committee might shrink in size once the Standard was voted in. However, it's already over a year later and that has not really occurred. In fact, this was a 5 day meeting with some nice hard core conversations. The subgroup chairpersons worked hard to produce nicely organized lists of issues which had been brought forth already along with their status (open, not a defect, etc). The luxury of time was back in the hands of the committee as they were in full swing initiating the DR (defect report) processing. You might want to check out a web page at Comeau Computing that mirrors the committee's public Issues Lists.

The flow for handling DRs was discussed and clarified. (What follows is our understanding of the flow, not some official narrative.) Formally, defects are sent to the ISO Convener. However, he (rightly) feels that it is not the best approach if he alone handles all the DRs directly per se. So instead, the convener will take input from different sources: NBs (national bodies), the editor of the Standard, and the UK C++ Panel group. The editor of the standard feels similarly though, so although it is within his power, he would rather take his input from X3J16. J16 of course internally delegated their work to subgroups (core, library, etc) as they have always done. The subgroups will maintain issues lists.

Effectively, the subgroups (that is, members of the committee) can submit Issues and Potential DRs to the Issues List Maintainer (this is usually done by public posting to the committee's internal newsgroup). Additionally, the moderators of comp.lang.c++ have volunteered to act as a filter in sending Potential Defects submitted by the general public at large to the Issues List Maintainer. If the moderators Reject it, the UK C++ Panel group will acts as an ombudsman and if they deem it a Defect, they will sent it to the convener. If they deem it a Potential Defect, that it is sent to the respective Issues List Maintainer. If they also reject it, then an NB can still pick it up as a Defect and submit that to the convener.

Once a respective Issue is on a list, the respective subgroup will review it. If they decide that it wasn't really a Defect, then as above, an NB can still pick it up as a Defect and submit that to the convener. If they decide it is a Potential Defect, then it is proposed to the whole committee. If the whole committee votes that they feel it is a potential defect then it is submitted to the editor. As mentioned above, the editor prefers go with the sentiment of the committee (this is probably not a promise, but there's many years of a good track record here).

NBs can also submit directly to the convener, whether as discussed above or on their own. So to summarize, the convener gets Defect Reports from NBs, the UK Panel, and the Editor. The Convener then effectively provides the Defects to the ISO committee (it's passed J16 already at this point) who can vote it Tentatively Resolved. Finally there is a Record of Response generated to the person who originally submitted the Defect, and the Issue is Officially Resolved. It then finds its way into a TC (Technical Corrigenda).

In short, the TC is a collection of the correct wording resolving the respective Defects. It is guessed that two TC's for Standard C++ might be issued. Do note that policy is to wait 5 years before re-opening up the Standard, so only Defects can be processed at this point. (Don't get us wrong, things like pure extensions will still find their way onto Issues Lists for when the right time comes, they just won't be officially handled at this point, since this activity is just for handling defects.)

The bottom line is that the status (Potential Defect, Rejected, etc) of the Issue will be recorded in the Issues List and will be made publically available by the committee. Check out the latest public Issues Lists.

The above is just intended as a quick overview. For a more precise description on how DRs will be handled in terms of the public, check out the details offered in the respective questions of the comp.std.c++ FAQ on how to do it.

Some of the more interesting technical issues discussed by the subgroups included:

Back to Top

Kona HI, US, October 1999

More work on processing defect reports occurred.
Back to Top

Tokyo, Japan, April 2000

More work on processing defect reports occurred.
Back to Top

Toronto, Canada, October 2000

Two TCs were always expected, and at this meeting, the final work on processing defect reports for TC#1 occurred. This means there will now be formal Defect Reports, Record of Responses to be produced, and also that TC#1 can now be prepared (for the meanings of these terms, see discussions above from earlier meetings).

Additionally, the committee considered and accepted a new "work item" to produce a type-2 technical report on C++ library issues. The report will consider current library practice, APIs, logical extensions, etc. and may include things for the next revision of the standard when that comes along.

Back to Top

Copenhagen, Denmark, April 2001

TC1 is still being edited. In the meantime, the committee continued hard at work in processing the additional defect reports that have been brought forth in order to subsequently produce a second TC. Nothing was particularly surprising.

As well, work on the C++ performance report continued.

Additionally, the committee agreed to submit a proposal to ISO in order to produce a Technical Report (TC) of Type 2 on C++ Library Extensions. The report will consider current library practice, APIs, logical extensions, etc. and may include things for the next revision of the C++ standard. Here's the scope, from the new work item proposal:

Library extensions of broad interest to users of C++ (possible examples include hashtables, regular expressions, and extensions for C99 compatibility), and potential future directions for the standard C++ library.
Informally, there was also some discussion about a possible new work item or a possible new subgroup within the committee that might take place in terms of the future and evolution of C++. This was an evening talk given by Bjarne Stroustrup by going through a number of points from his slides. We'll add more about this shortly.
Back to Top

Redmond, WA, US, October 2001

Here's a summary so far, in no particular order, of more significant aspects of the meeting (the meeting is still occurring, so this description is "live", so this info is not yet complete):
Back to Top

(c) © 1997-2013 Comeau Computing. All Rights Reserved.

Comeau Computing
91-34 120th Street
Richmond Hill, NY 11418-3214
Last Updated July, 2013
/* the end */