(c) © 1997-2013 Comeau Computing. All Rights Reserved.
The below contains a summary for the following ANSI/ISO C++ Meetings:
- Nashua NH, US, March 1997
- Chiswick, UK, July 1997
- Morristown NJ, US, November 1997
- Nice, France, March 1998
- Santa Cruz CA, US, October 1998
- Dublin IR, April 1999
- Kona HI, US, October 1999
- Tokyo, Japan, April 2000
- Toronto, Canada, October 2000
- Copenhagen, Denmark, April 2001
- Redmond, WA, US, October 2001
Copyright © Comeau Computing. All rights reserved.
Revised: July, 2013
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
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:
91-34 120th Street
Richmond Hill, NY 11418-3214
Can you hear me?
- Can you hear me in the back?
- Can I hear you?
"First Things First, But Not Necessarily in That Order"
- This stuff is complicated.
- I have only a few minutes
- So where to start?
- I will be jumping around, or so it will seem to appear.
- Who attends a C++ meeting?
- How meetings occur
- Recent meeting information
- Nashua meeting details
Who attends a C++ meeting?
- Basically: Whoever wants to.
- This is strictly volunteer.
- This is strictly pay you own way.
- Each "company" only gets one vote.
- ANSI=American National Standards Institute
- ISO=International Standards Organization
- NB=National Body
- X3J16=US committee
- WG21=ISO committee
- PC=Public Comment
"Slang" Quickie (more)
- US TAG=WG21 NB from US
- D/WP=Draft/Working Paper
- D/WD=Draft/Working Document
- CD=Committee Draft
- DIS=Draft International Standard
- C9X=The C Committee
- DR=Defect Report
- TC=Technical Corrigenda
General Meeting information
- Meetings occur 3 times a year
- Email and papers between meetings
- Two Groups meet
- ANSI/ISO jointly meets through week
- Liaisons exist when meeting separately
- Effective result:
One joint international standard
Effective General Flow of a Typical Meeting
- ISO meets on Sunday
- ANSI meets through week
- Split into working groups
- Each working group hashes out appropriate issues and/or co-meets
- All regroup back to full committee
- Each group reports to full committee and it takes straw votes
- EOW: Real votes and unfinished business
- ISO meets again separately
Significant Recent Meeting
- Kona, HI in Nov 1996
- The WP was sent out as "CD2".
- "Effectively": the draft is frozen
- "Effectively": the draft is stable
- "Effectively": bug fixes only
What CD2 does not mean:
- There is no work left.
- There is a C++ standard.
Flow of meeting in Nashua, NH
- Issues looked at:
- Core, Library, ANSI C compatibility
- Extensions, syntax, or environment WGs did not meet.
- No formal votes, not even on more stables issues.
- This was a so-called "quiet" meeting.
What does quiet mean?
- X3J16 to categorize ANSI public comments.
- X3J16 committee considering just ISO NB comments.
- Any other remaining X3J16 issues considered.
- No WG21 (==ISO) votes in Nashua.
- Effectively: US meeting only.
- BTW: ISO CD2 balloting is occurring during this period (that
What does this categorization mean?
- The issues on the table was the sources of the current issues:
public comments, plus some members details.
- From this, a list of issues, only, was recommended by the
- These are not changes to the DWP
(we cannot change the CD).
- Each NB has lists to be processed still.
- Some resolutions may appear, however, they are only suggestions
at this point in time.
What is the impact of this?
- No changes to the draft (WP) can occur.
- Of course, issues should be raised and addressed, for later
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
- The Nashua meeting had no surprises.
- Things were pretty smooth.
- Steve Adamczyk:
"Little here that is interesting!"
- Also, some remote mentions of Defect Reports in passing, which
on some superficial level is a good thing
- But: don't hold your breath ;-)
Status of the Standard
- Has not changed.
- Nor is there a Draft Standard yet.
- Still "on schedule".
- BTW, language and lib are not considered separately.
Status of the CD
- US position on CD2:
"Yes, with comments"
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."
- BTW: CD2 voting period ends in June
- Nothing has changed (yet).
- It seems likely there will be no CD3.
- "But don't tick off an NB" ;-)
- DIS in July, 1997?.
- International Standard
(i.e. "Standard C++") in July, 1998?.
- (Then DRs, TCs, proposed Amendements during next 5 years)
- The world sighs. ;-)
- Many public comments were effectively rejected.
- Lame compiler vendors/book authors/user groups should get
their acts together.
- More responsible and attentive vendors et al can smoothly
tweak their "products".
- Note: This is NOT just about new C++ features.
- C9X needs to contemplate any issues.
- More public comments ????.
- UK meeting in July.
- All ??? NB comments available.
- They must be worked out.
- Size is daunting.
- Most are supposed to be trivial though, or will be rejected.
- Continue fixing the draft (vs changing it).
- What about serious flaws that pop up?
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.
- Some technical highlights will be provided under the Comeau
URL soon too.
- Comeau will continue to update the community about ANSI/ISO
C++ meetings through its web page, and in newsgroups.
- Significant Recent Event:
- ISO (re)allows electronic CD.
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.
- Trait: A characteristic, especially a distinguished & personal one.
- In short, a property or attribute, even a peculiarity
- WP: Working Paper
- FDIS: Final Draft International Standard
- IS: International Standard
- WG: (informal) C++ committee Working Group
- CD: Committee Draft
- NB: National Body
- ANSI: American National Standards Institute
- ISO: International Standards Organization
- OMDB: Over My Dead Body
- Morristown's Agenda
- Vote out WP as proposed FDIS
- Nothing seems to be holding us back, so: "We must"
- The process
- We must consider what we can live with vs what we cannot live without
- What are the realities available to the committee?
- The document won't be perfect
- It MUST ship!
- It will be "good enough to ship"
- This should occur by Friday
- Or something has gone seriously wrong and we are doomed! ;-)
- Changes occurred from CD1 to CD2 and since then
- So much progress did occur
- But those changes were not approved due to bureaucracy constraint (they were accepted informally though)
- Expected Real Time Plans for the meeting's logistics:
- WGs report progress & work plans (Monday)
- WGs meet
- WGs close out remaining open issues
- WGs complete formal proposals
- No new topics allowed. (The end is the end.)
- Proposal == exact wording
- Of course, proposals must accommodate any cascading effects to other parts of the WP
- Distribute proposals to members for review
- WGs present proposals (Tuesday afternoon)
- Proceed with an "On the spot" formal motion and formal vote to accept/reject the proposals
- Expected Plans for other logistics:
- Production of Document (Wednesday/Thursday)
- Immediate drafting, editing, clarifying, correcting, etc.
- Make proposed FDIS sections available on paper
- Immediate proofreading by section
- Make proposed FDIS in whole available on paper
- Final proofreading
- Final production of proposed FDIS on paper
- Rejoicing (Thursday)
- Formal motions (Friday)
- Approve the WP itself (since all proposals are now over with)
- Submit for approval as FDIS
- The above enumerated the expected plans, but What Really Happened?
- Hot items (but not extraordinarily hot):
- auto_ptr discussions on Monday night
- <cname>, std and :: discussion on Tuesday morn
- Some concluding discussion about the C<T> instantiation of a non-inline function where T is incomplete
- Show stoppers?
- What Were The Votes on whether to accept the WD as the FDIS????
- X3J16 Approved Unanimously!
- WG21 Approved Unanimously!
- US TAG Approved Unanimously!
- ==> ALL technical work is complete
- Can now call it "Standard C++"?
- It's called ISO/IEC 14882
- We hence now have (at least):
- ISO C++, ANSI C++, BSI C++, AFNOR C++, DIN C++
- A link to the press release can be found at the Comeau Web site.
- What next?
- "Submission" to ISO.
- Important: The "technical experts" have spoken united in the above votes
- However, ratification through bureaucracy still needs to occur at this point.
- ==> But that's not expected to be controversial.
- Who approves FDIS?
- About 20 countries will do so around March 1998
- "Standard C++": When?
- Physical paper copy expected around August 1998
- Between then and now
- Not completely sure, but next meeting is in March 1999 in France
- Ok, C++98, now what?
- Additional meetings will still continue
- DRs, TCs, chartered WGs, etc
- GC and more libs have always been rumored
- And we'll be lots smarter/experienced
- But nothing formally till C++200x
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:
- TR: "sounds good"
- NA (normative addendum): want in before 5 years
- DRs are not a back door to extensions
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
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:
- How to (re)organize ourselves?
- Processing DRs in some way made sense to everybody.
- But what about extensions?
- Well, they are dangerous, and so we should be cautious
- There are at least 2 kinds of extensions
- big ones ("milestones" if you will):
- persistence, concurrency, GUI, etc
- freeze/wait till some experience... we need practical proposals...
need something to think about which comes from somewhere
- small extensions
- strings, hash maps, fixing an inconsistency, to make more complete,
"obviously something is missing", minor utilities (?), etc.
- How to handle??? ==> In near future have informal discussions.
Perhaps 2 days in October?
- Try to avoid letting the extensions to be too different.
- Let's take the opportunity to support small extensions informally
- Let's consider helping practical users to avoid having multiple solutions.
- When we do that, will we do something more?
- Should results go into Technical Reports?
- What do we do, and when?
- And who (making a distinction between committee's activities vs individuals) does what?
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:
- Final non-technical balloting on "Standard C++" was expected to be
completed by this month but unfortunately it has still not started.
In the grand scheme of things, this may not change anything except
for the time the national bodies start selling the standard
(right now there is still no way for the public to obtain it besides
becoming a committee member). There was word late into the meeting that
the final proof will go out by the end of this month but that remains
to be seen.
- The official job of the committee for now is to handle defect reports.
However, the above bullet impacts workload because we cannot handle defect reports
to something that does not officially exist yet.
- Person to person meetings were moved from 3 times a year to 2 times a year.
Similarly, 5 day meetings are going to be 3 day meetings. This is temporary
and subject to change when the workload is known. This may turn out to be
erratic until some sense of the work involved becomes the driving factor.
- The C++ committee is going to co-locate with the C committee for some
meetings, at least the next one.
- There was various discussions about the future of C++,
where the committee fits into things, what might be added or changed,
what new "Projects" might be added. A few of the areas that seemed
to leap out to me at least for the temporary time-frame include:
- Investigate how performance issues, in particular using the "Embedded C++"
proposal as one starting basis, should fit into Standard C++, if at all.
- Investigate incompatibilities with "C9X"
(There was concern that the C committee did not do this, but that's
- Co-locate some of the C++ meetings with some of the C meetings in the
spirit of strengthening both languages independently as well as
strengthening the communication and feedback between the two groups,
who have historically been "chasing" each other (the Standards overlap
- Discussing what a defect report is, how it should come into the
committee, and what policies and flow of control should be applied to it.
The committee spent considerable time on this.
- Need to look at possible technical reports, projects, or just informal WGs
- How to handle big extensions or small extensions
- Currently the committee is being conservative.
When or how this may change is still up in the air.
It seems certain there will be a year of quiet activity for the most
part though (quiet less in that there will not be anything done, but
in that laying groundwork, getting feedback, doing analysis, etc,
is up front work with no immediate effect). The committee also seemed
to express the feeling of getting real user experience on a number of
library issues and analyzing that somehow not only to consider what works
but also what doesn't, perhaps including looking at other languages.
Also, how important is consistency with what we currently have?
If nothing else, TRs (Technical Reports) may have their place.
There was some inconclusive and somewhat wandering discussion about
"vision" and what to do next. For now it was decided that just lots of talking is good.
- The next meeting is going to be in October (so no July meeting).
April 99 in Ireland possibly. Oct 99 for HI?
- The following Proposal passed:
"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++."
Note: At first glance this seems wrong, but you must consider that
a number of things in C9x were solved differently from C++. It's nobody's
fault except the historical priorities and technical issues for each
respective language. Clearly compiler vendors will be considering C9x
independently, but until the features are somewhere, this might be best left
as is until we have real world information about the new features actually
in compilers and their needs in real programs. Both the C and C++ committees
have been consciously aware of this aspect for a long time. The respective committee liaisons may have some recommendations in the future.
C9x people support this, they never thought they were undertaking the features
for the 5 year revision period for C++.
BTW, when the C committee's work, "C9X", is standardized, there will no
longer be a C89 standard.
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:
- Putting explicit specification into the type system completely, which implies static type checking. There's just too many other cases otherwise.
- The default initialization issue.
Exact characterization of what this is might need work, but the intent was agreed on as the right direction to take.
- A number of extern "C" issues which the standard is vague on.
Perhaps a paper on linkage contexts is needed.
- The issue of what happens if exit is called from a signal handler was considered.
Should be outlawed. C9x already did this.
What happens if an atexit() is called at exit() time?
During exit()ing, can another function be registered?
Let's conform to C committee. Also, note that static objects etc during this will be undefined behavior.
Some Library Issues:
- They looked at 70 issues and 80-90% were "slightly above the typo level"
- Some namespace recommendations were expressed.
A proposal perhaps resulting in a TR was discussed, but no words yet for a motion.
- Discussed the WG20 internationalization effort re N536/N1168.
Don't know yet how to proceed, see what happens in the intl-reflector
The committee established a subgroup to consider the issue of a Performance TR.
Their issues included:
- Since this is new, we expect more ideas as time goes by.
- The research involved in this group might end up producing a large documents.
- They came close to submitting the new work item proposal (NP), but the actual wording is hard. As well, it was not clear whether there should be an NP for performance issue and another for portable machine level issues (fixed sized types, etc). And extensive discussion took place in full committee on this issue too.
- It was decided that there should be sole focus for the report. Hence it could cover ESP (embedded systems programming), RT (real-time programming), dedicated servers, and many other things.
- The report might include: simple guidance, specifications, etc.
- We may need to vote on this NP between meetings
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:
- Core Issue 35, the default initialization of T(), which in some cases surprisingly does not result in initialization to 0 as do other such default initializations.
- Core Issue 106, allowing references to references, not particularly so it can mean anything (effectively ref-to-ref would collapse into a ref), but so that various constructs involving templates can work.
- Lib Issue 96, the implications that vector<bool> is not really a container.
- Lib Issue 69, about whether the storage layout of a vector must be contiguous.
More work on processing defect reports occurred.
More work on processing defect reports occurred.
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.
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.
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):
- As in past meetings, the core and library working groups continued to process defect reports.
- The TR from the performance working group is shaping up nicely.
- The library working group is continuing with their plans for a library TR.
- There was some more discussion on C++0x.
- There was some discussion about stronger liasons to an from the C++ committe and the C committee, as well as some aspects to merging the two languages.
(c) © 1997-2013 Comeau Computing. All Rights Reserved.
91-34 120th Street
Richmond Hill, NY 11418-3214
Last Updated July, 2013
/* the end */