Nashua, US, March 1997

"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

Can you hear me?

• Can you hear me in the back?
• Can I hear you?

Thanks!

Agenda

"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.

Agenda

• Who attends a C++ meeting?
• Terminology
• How meetings occur
• Recent meeting information
• Nashua meeting details
• Impacts?

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.

"Slang" Quickie

• 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
• 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 lots.
• There is a C++ standard.
  • There is not.

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 is, now)

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 US TAG.
• 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.
  • Yet
  • Formally at least.
• Of course, issues should be raised and addressed, for later reconciliation.
  • For instance, typos.

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.
  • There still is none.
• Nor is there a Draft Standard yet.
• Still "on schedule".

• BTW, language and lib are not considered separately.

Status of the CD

• Out there.

• 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

Significance:

• 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)

Practical significance:

• 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.

What next:

• 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?
  • Film at 11?

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.

Additional Information

• Significant Recent Event:
  • ISO (re)allows electronic CD.

• Appropriate additional pointers (URL links, etc) to committee information can be found on the Comeau WEB page too: http://www.comeaucomputing.com
• Don't hesitate to send any questions to: comeau@comeaucomputing.com

Back to Top

Chiswick, UK, July 1997

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

• Traits
  • Trait: A characteristic, especially a distinguished & personal one.
  • In short, a property or attribute, even a peculiarity
• Terminology
  • 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 will never ever be.
    • 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! ;-)
• CD2
  • 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)
    • Discussion/amendments/etc
    • 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)
    • Party on Thursday night!
  • 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?
    • None!
  • Gotcha's:
    • None!
  • Snafu's:
    • None!
• 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++"?
    • Yes!
    • 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

Back to Top

Nice, France, March 1998

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 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:

• 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 another issue.)
  • 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 time-wise).
  • 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.

Back to Top

Santa Cruz, US, October 1998

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:

• 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

Back to Top

Dublin IR, April 1999

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.

Back to Top

Kona HI, US, October 1999

Back to Top

Tokyo, Japan, April 2000

Back to Top

Toronto, Canada, October 2000

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

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.

Back to Top

Redmond, WA, US, October 2001

• 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.

Back to Top