ISO/ IEC JTC1/SC22/WG21 N0734

                                     Document Number: WG21/N0734
                                                      X3J16/95-0134
                                                Date: 16 September 1995
                                             Project: Programming Language C++
                                            Reply to: Dan Saks
                                                      dsaks@wittenberg.edu
 
 
                             X3J16 Meeting No. 18
                             WG21  Meeting No. 13
                               9 - 14 July 1995
 
Monterey Marriott
350 Calle Principal
Monterey, CA 93940 USA
 
 
1     Opening activities
 
      Lenkov convened the meeting as chair at 09:00 (PDT) on Monday, 10 July
      1995.  Lajoie was the vice-chair, and Saks was the secretary.
 
      Sun Microsystems hosted the meeting.
 
1.1   Opening comments
 
1.2   Introductions
 
      Saks circulated an attendance list each day, which is attached as Appen-
      dix A of these minutes.  Lajoie circulated a copy of the membership list
      (SD-2 = 95-0001R1) for members to make corrections.
 
1.3   Membership, voting rights, and procedures for the meeting
 
      Lenkov reminded the attendees that this is a co-located meeting of WG21
      and X3J16.  (The combined membership is denoted WG21+X3J16 in these min-
      utes.)
 
      Lenkov explained the voting rules:
 
      --  In straw votes, all WG21 technical experts may vote, regardless of
          attendance at prior WG21 meetings.  An X3J16 attendee may vote only
          if he/she is the voting representative of a member organization that
          has met X3's attendance requirements (N0609 = 95-0009).  (The voting
          representative is the principal member, or an alternate if the
          principal is not present.)  A WG21 technical expert who is also an
          X3J16 voting member still casts only one vote in a straw vote.
 
      --  In WG21 formal votes, only the head of each national delegation may
          vote.
 
      --  In X3J16 formal votes, only one representative from each X3J16 mem-
          ber organization may vote, and only then if the organization meets
          X3's attendance requirements.
 
1.4   Distribution of documents not distributed before the meeting
 
      A bunch.
 
1.5   Approval of the minutes from the previous meeting
 
      Saks submitted the minutes from the previous meeting (N0661 = 95-0061)
      for approval.
 
      Henricson said his e-mail address appearing under item 5.2 was trun-
      cated.  The complete address is "mats.henricson@eua.ericsson.se".
 
      Motion by Saks/Rumsby:
 
          Move we approve N0661 = 95-0061 as the minutes of the previous
          meeting with this correction.
 
      Motion passed X3J16: lots yes, 0 no, 0 abstain.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
1.6   Agenda review and approval
 
      Lenkov submitted the proposed agenda (N0712 = 95-0112) for approval.
      Harbison asked to insert a new item:
 
      12.1 Schedule Change
 
      and renumber items 12.1 through 12.3 as 12.2 through 12.4, respectively.
 
      Motion by Saks/Lajoie:
 
          Move we accept N0712 = 95-0112 as amended as the agenda for this
          meeting.
 
      Motion passed X3J16: lots yes, 0 no, 0 abstain.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
1.7   Report on the WG21 Sunday meeting
 
      Harbison summarized the highlights of Sunday's WG21 meeting.  Six dele-
      gations attended: Canada, Germany, Japan, Sweden, the UK, and the US.
 
      Harbison said WG21 discussed the reasons for the two-week delay in sub-
      mitting the draft to SC22 for CD ballot.  They agreed that the editing
      process need not be changed but it must be clarified.
 
      Harbison said the deadline for national bodies to submit final votes on
      CD ballot slipped from 28 August to 28 September.  WG21's job at the
      Tokyo meeting in November will be to resolve the comments on those bal-
      lots.  WG21 must then update the draft to reflect the resolution(s) to
      those comments.  Harbison explained that WG21 agreed not to try to rush
      the updated draft to SC22 in only two weeks.  Rather, we will distribute
      a new draft in the mailing before the March 1996 meeting, and decide
      what to do with the document in March -- submit it for another CD
      ballot, submit it for DIS ballot, or keep editing it.
 
      Stroustrup added that we have not yet decided whether to slip the
      project schedule four or eight months.
 
1.8   Liaison reports
 
      ==== WG14 (ISO C) ====
 
      Plum explained that WG14 met for five days in Copenhagen, Denmark in
      June, 1995.  WG14 is now taking straw votes to determine what will go
      into what is now known as "C9X".
 
      Plum said the straw votes in favor of adding the following features were
      so unanimous he would be surprised if WG14 later reversed them:
      --  // comments
      --  new keyword restrict (as implemented by Cray Research)
      --  arrays of varying dimensions (as in gcc and Cray)
      --  new headers, complex.h and fp.h, to support math
 
      WG14 will look at reconciling incompatibilities with C++.  Plum thought,
      for example, that WG14 might consider changing C to treat nested structs
      as truly nested.  WG14 might also deprecate implicit int, and make C9X
      compatible with C++ in its treatment of bool and wchar_t.
 
      Plum said the more controversial issues before WG14 involve whether to
      add some C++ features, such as classes, to C9X.
 
      At WG14's request, WG21+X3J16's c++std-compat (C compatibility) e-mail
      reflector is now tied to WG14's reflector.  Messages sent to c++std-
      compat now appear on both reflectors.
 
1.9   New business
 
      Lenkov said he has submitted his resignation as chair of X3J16.  He
      recommended that Clamage be the next chair.  There will be a formal call
      for volunteers in the next pre-meeting mailing.  Lenkov encouraged X3J16
      members to support Clamage.  Lenkov will remain for a time as Hewlett-
      Packard's principal representative.
 
      The committee thanked Lenkov for his work and guidance over the past
      several years.
 
1.10  Drafting Committee
 
      Lenkov explained the role of the drafting committee: to prepare a writ-
      ten statement of the formal motions so that voting members (particularly
      those whose native language is not English) have an opportunity to read
      and understand what they are voting on.
 
      Lenkov said that Saks (as secretary) will head the drafting committee.
      Each ad hoc working group (WG) chair is responsible to bring that WG's
      motions to, and participate in, the drafting committee.  Lenkov added
      that each chair may delegate the job to another WG member, but the chair
      remains responsible.
 
      As usual, Corfield, Gafter, Hartinger, and Unruh volunteered for the
      drafting committee.
 
The committee recessed to WGs at 10:15 on Monday.
 
2     WG sessions
 
3     Technical session: Template Compilation Model
 
4     WG sessions
 
The committee reconvened at 08:35 on Wednesday.
 
5     Project Editor's report
 
      Lenkov opened the committee of the whole.
 
      Koenig presented the project editor's report (N0764 = 95-0164).  He ex-
      plained that the WP was supposed to be drafted in five weeks, but it
      took seven because of controversies that arose during the process.  He
      explained why he thought this happened, and presented a proposal to
      avoid such problems in the future.
 
      Koenig proposed that:
      --  The editor has the last word over the content of the WP.
      --  If the convener or anyone else believes WP is incorrect or otherwise
          inappropriate, that person can attach an addendum explaining that
          belief.
      --  The committee can (and should) resolve discrepancies at subsequent
          meeting(s).
 
      Lenkov explained that, on Sunday of this week, WG21 approved the pro-
      posal that Koenig just presented to the joint session.  WG21 also agreed
      that motions submitted by WGs should include wording that's as close as
      possible to final wording intended for the draft (but no closer? :-).
 
      Gafter asked if a given editorial box or addendum will remain part of
      the draft until the issues it raises are resolved.  Koenig replied that,
      strictly speaking, they are not part of the draft, but he intends to
      leave them in the document until resolved.
 
      Plauger encouraged Koenig and Harbison to write down the editing pro-
      cedures.
 
      Plum said he thought there were two important issues here:
      1)  the procedures for editing a draft that goes to SC22
 
          Plum said he never objected to the "Skaller Resolution" (empowering
          the editor to make substantive changes within certain constraints;
          see N0435 = 94-0048) when applied to a draft that stays within
          WG21.  He was concerned about the procedures for editing a draft
          that we submit to SC22, and thought we should agree on such pro-
          cedures before the next time we send a draft to SC22.
 
      2)  the use of editorial boxes and addenda
 
          Plum said we need to reach a point where people know that, even if
          they have a good idea, they can't just rely on having the ear of the
          editor to get those changes into the draft.  The changes must be
          approved officially.
 
      Harbison more-or-less agreed with Lenkov that WG21 approved what Koenig
      has proposed.  WG21 also agreed that the Convener is ultimately respon-
      sible to ensure that WG21 follows appropriate procedures.
 
      Harbison asked what happened to the issues that are in dispute.  Koenig
      said the important proposals are marked by 27 "editorial proposal" boxes
      in the draft.  Myers added that the issues in the boxes are on the
      Library WG issues list, and were probably all discussed at this meeting.
 
      Plum said Koenig's current proposal is not what he understood as the
      proposal on Sunday.  In particular, he took exception to the second bul-
      let in the proposal.  It's not a matter of some crank just objecting to
      words in WP, but whether the WG actually approved the change.  Koenig
      said he agreed with Plum in principle, but in practice, it often comes
      down to a matter of opinion as to whether or not the WG approved the
      change.
 
      Plauger explained that, by ISO rules, the responsibility for the draft
      content is the editor's and the responsibility for following procedures
      is the convener's.  That's why these positions require ISO approval.  No
      matter what we do, the last round of changes will still have errors.
      That's why we need a human editor, who must make creative decisions.
      That's also why we have a review committee.  This is true irrespective
      of the Skaller resolution.
 
      Harbison agreed to work with Koenig to specify the editing procedures.
      Lenkov asked Koenig and Harbison to draft a formal motion.
 
      Straw Vote: Who approves of N0691 = 95-0091 as the current WP?
          X3J16: lots yes, 0 no, 5 abstain.
          WG21: 3 yes, 0 no, 3 abstain.
 
      Koenig said he understood the abstentions as objections to the process,
      not to the content of the document.
 
      Schwarz noted that, at one time, Koenig said he intended to incorporate
      the substance of the editorial boxes as normative text in the next WP,
      unless someone objected to a particular box.  Schwarz asked if that was
      still Koenig's intent.  Koenig said he never thought WG21+X3J16 approved
      that policy.  He planned to leave each editorial box in place until we
      formally resolved the issue for that box.
 
6     General Session I
 
6.1   Core Language WG
 
      ==== Core (Adamczyk) ====
 
      Adamczyk presented resolutions to numerous small core issues.  He said
      his Core subgroup approved all these recommendations unanimously (or
      nearly so).
 
      Adamczyk began with a C compatibility issue (from public comment 7.12
      (N0736 = 95-0136).  He explained that C allows at most three characters
      in an octal escape sequence in character and string constants such as
      '\377'.  C++ allows any number of characters (2.9.2), which means that C
      and C++ interpret the following differently:
 
          "\1234"     // 2 characters in C, 1 in C++
 
      Adamczyk recommended making C++ the same as C in this regard.  That is,
      octal escape sequences in C++ should allow at most three characters.
      (See Motion 2(a) for the precise wording.)
 
      Charney asked if WG14 might change C to be like C++ instead.  Plum re-
      plied "Not a chance."
 
      Adamczyk presented a proposal to clarify the evaluation order for mem-
      initializers (from public comment T16.3 of N0736 = 95-0136 and issue 359
      from N0711 = 95-0111).  He explained that, although the WP prescribes
      the initialization order for bases and members, it does not specify the
      evaluation order for expressions in ctor-initializers.
 
      For example, in:
 
      struct A {
          int i;
          float x;
          A() : x(f()), i(g()) { }
      };
 
      the WP doesn't say whether A() evaluates f() before or after g().  Adam-
      czyk proposed to specify that the expressions in a mem-initializer are
      evaluated just before that initialization is done, and each initializa-
      tion is followed by a sequence point.  (See Motion 2(b).)  The intent is
      that each mem-initializer is a full expression.  Any temporaries created
      during the initialization of a base or member are destroyed immediately
      afterward.
 
      Adamczyk explained that the rules on passing arguments to ellipsis (...)
      parameters (WP clause 5.2.2 paragraph 7) do not mention pointer or
      pointer-to-member arguments.  The WG proposed to allow both, as in
 
      void f(int, ...);
 
      char *p;
      f(1, p);        // proposed to be OK
      int A::*pm;
      f(2, pm);       // proposed to be OK
 
      (See Motion 2(c).)
 
      Adamczyk explained that the current WP (clause 9 paragraph 4) allows a
      POD to have a user-defined copy assignment operator.  This means that a
      POD might not have bit-wise copy semantics.  He proposed to disallow
      user-defined copy assignment in PODs to ensure that they do have bit-
      wise copy semantics.  (See Motion 2(d).)
 
      Adamczyk presented a proposal to specify volatile semantics more pre-
      cisely (N0707 = 95-0107).  The WG proposed that accesses via volatile
      lvalues must occur in the order written and between the surrounding
      sequence points, and no more nor less accesses are allowed.  It also
      proposed that the number of accesses for bit fields will be implementa-
      tion-defined.  (See Motion 3.)
 
      Ball said he thought the number of accesses for bit fields should be
      unspecified, not implementation-defined.  Plum said he thought the pro-
      posal simply said the proposed properties apply only to an implementa-
      tion-defined set of types.
 
      Plauger explained that the C committee has gone around on this issue
      before, and found it impractical to specify the number of accesses to a
      volatile object between sequence points.  Plauger offered to spend a
      couple of hours explaining the problems to Eager (the original author of
      the proposal) over an unspecified number of beers.  Eager explained that
      the point of the proposal was to specify the number of accesses.
 
      After a bit more discussion, Adamczyk suggested changing the proposal
      from saying the number of accesses is implementation-defined to saying
      the number is unspecified.
 
      Ball again objected to the proposal, arguing that sometimes a program
      must touch surrounding bits when accessing a bitfield.
 
      Unruh noted that the proposal said the set of types with volatile seman-
      tics can't be empty.  Eager said he'd accept as an amendment that the
      set could be empty.
 
      Straw Vote: Who favors this proposal?
          WG21+X3J16: 16 yes, 9 no, 19 abstain.
          WG21 only: 3 yes, 0 no, 3 abstain.
 
      Adamczyk presented a collection of four proposals on access checking
      (N0704 = 95-0104).
 
      1)  When a constructor throws an exception from a new expression, the
          delete function used to free memory must be accessible and unam-
          biguous.  For example,
 
          class A {
          public:
              A(int);
              void * operator new(size_t);
          private:
              void operator delete(void *);
          };
 
              new A(1);  // error, delete not accessible
 
      Adamczyk explained that some programmers declare X::operator new private
      just to prevent deleting X objects.  He suggested that an implementation
      that turns off exceptions should probably turn off this check at the
      same time.
 
      Lenkov asked if anyone objected.  No one did.
 
      2)  A function selected by overload resolution must be accessible.
 
      3)  The copy constructor and destructor for a thrown object must be
          accessible and callable at the throw point, even if elided.
 
      4)  A handler parameter cannot have an abstract class type.  The param-
          eter must be initialized from a runtime copy, and destroyed on exit
          from the handler.  The parameter's copy constructor and destructor
          must be accessible and callable (even if the calls can be elided).
 
      (See Motion 2(e).)
 
      Adamczyk presented a proposal to specify that the access of a redeclared
      member must be the same on each declaration (N0703 = 95-0103).  For
      example:
 
      struct A {
          class B;
      private:
          class B { };  // error
      };
 
      (See Motion 2(f).)
 
      Adamczyk then presented a proposal to correct the access rules for pro-
      tected members (from core issue 449 of N0711 = 95-0111, and from c++std-
      core-4920 and c++std-core-5598).
 
      Adamczyk explained that the ARM imposes a constraint on accesses to
      protected members, but only for nonstatic members.  When WG21+X3J16
      added rules regarding access to protected members via pointers-to-
      members, the new words in the WP mentioned only "qualified-id" instead
      of "qualified-id in a pointer-to-member."  The January 1995 WP "clari-
      fied" the rules for pointers-to-members in such a way that the con-
      straint applied to static data members when referenced in a qualified-
      id.  But the check only makes sense when applied to nonstatic members.
      Adamczyk gave this example:
 
      struct A {
      protected:
          typedef int I;
          static int m;
      };
      struct B : public A {
          void f() {
              I x1;     // okay
              B::I x2;  // okay
              A::I x3;  // error by WP; silly
              m = 1;    // okay
              A::m = 1; // error by WP; silly
          }
      };
 
      Adamczyk recommended removing the first paragraph of clause 11.5, and
      replacing it with a note that the section described an added constraint
      that should not apply to static members, types, and enumerators.  He
      noted that the second paragraph of clause 11.5 handles pointers-to-mem-
      bers properly.  (See Motion 2(g).)
 
      Next, Adamczyk presented a proposal to specify the semantics for refer-
      ences in unions (N0709R1 = 95-0109R1 and core issue 335).  He explained
      that WG21+X3J16 considered eliminating references in unions, but several
      national bodies objected.  Thus, his Core group proposed to "fix" refer-
      ences in unions instead of banning them.
 
      Specifically, the WG recommended option 2 of N0709R1 = 95-0109R1.  They
      also recommended removing an unapproved change to the definition of
      aggregate (clause 8.5.1) that precludes const members and references in
      aggregates.  (See Motion 2(m).)
 
      Ball asked what's the point of this; it's all pain and no gain.  Gibbons
      suggested that wrapping a reference in a struct before putting it in a
      union would achieve the same results without complicating the language.
 
      Plum recalled that we earlier proposed to disallow references in unions,
      but Skaller objected because it would preclude an extension he wanted to
      propose.  But we didn't approve that proposal.
 
      Stroustrup said you can put references in unions, and break reference
      semantics.  You can put const objects in unions, and break const seman-
      tics.  You can put objects with constructors in unions, and break ini-
      tialization guarantees.  But why?  He challenged anyone to come up with
      reasons.
 
      Koenig and others speculated on reasons.  Stroustrup later said the
      problem is not that he can't imagine uses for references in unions; it's
      that he can.
 
      Straw Vote: Who favors option 2 of N0709R1 = 95-0109R1?
          WG21+X3J16: 9 yes, 35 no, 6 abstain.
          WG21 only: 1 yes, 4 no, 1 abs.
 
      The committee considered option 1 of the paper (to ban references from
      unions).
 
      Straw Vote: Who favors option 1?
          WG21+X3J16: 34 yes, 1 no, 2 abstain.
          WG21 only: 4 yes, 1 no, 1 abstain.
 
      Adamczyk said he'd submit option 1 for a formal vote.  (See Motion 4.)
 
      Adamczyk presented a proposal to specify additional semantics for type
      bool (N0714 = 95-0114).  Specifically, he proposed only point 3 of the
      paper, to allow bool as the left operand of compound assignment opera-
      tors.  (See Motion 2(h).)  He gave this example:
 
      bool v, w;
 
      v |= w;  // Was legal in pre-bool world; should be allowed
      v *= 5;  // Strange, but propose to allow as well
 
      Adamczyk then proposed to disallow bool operands for both the prefix and
      postfix decrement operators (from core issue 517), and to add a pseudo-
      template to clause 13.6 to specify assignment for pointers-to-members
      (from core issue 518).  (See Motion 2(j).)
 
      Straw Vote: Who opposes the above? 1.
 
      Corfield said he opposed this proposal because it blurs bool with int
      even more.  Gafter said he'd rather bool be a distinct non-integral
      type, but that's not going to happen; bool is already an integral type.
      He said this proposal just makes the language rules more regular.
      Koenig said he'd rather constrain assignment operators for bool to
      "sensible" ones.
 
      Bruck said the original bool proposal didn't allow implicit conversion
      from int to bool, but WG21+X3J16 voted to allow such conversions.  Given
      that deliberate decision, this is the right thing to do.
 
      Straw Vote: Who favors the previous proposal?
          WG21+X3J16: lots yes, 5 no, 8 abstain.
          WG21 only: 3 yes, 1 no, 2 abstain.
 
      Adamczyk then presented a proposal to explicitly allow enumeration
      operands for arithmetic operators (from core issues 489 through 492,
      494, 495, and 498).  He explained that enumeration types are no longer
      integral and therefore no longer arithmetic.  The WP still states that
      many operators, such as "/", require arithmetic operands.  The wording
      has not been updated to account for the fact that enumerations are no
      longer integral.  The WG recommended adding "or enumeration" to each of
      the indicated cases.  (See Motion 2(i).)
 
      Plum asked why the WG did not recommend reclassifying enumerations as
      arithmetic types.  Adamczyk said they considered it, but rejected it.
      They decided to stay with the status quo that enumerations are not
      arithmetic, but convert to arithmetic type.
 
      Straw Vote: Who opposes this proposal? 1.
 
      Adamczyk presented a proposal to clarify when ?: yields an lvalue result
      (from core issue 472).  The WP currently states that ?: yields an lvalue
      result if and only if the operands are lvalues with the "same type".
      The WG recommend clarifying the WP to say that "same type" does not
      ignore cv-qualifiers.  For example,
 
      const int b;
            int c;
 
          (a ? b : c) = 1;  // not an lvalue
 
      In other words, the types must be the same before any implicit conver-
      sions.  (See Motion 2(k).)
 
      Gibbons asked why not merge the cv-qualifiers.  Adamczyk explained that
      they wanted to keep things simple.
 
      Straw Vote: Who opposes this recommendation? 0.
 
      Adamczyk then presented a proposal to clarify the semantics for compar-
      ing pointers-to-members (from core issue 481).  The issue is whether two
      pointers-to-members are equal if they merely refer to the same member,
      or if they only refer to the same member in the same class instance.
      The WG recommended the latter.  (See Motion 2(l).)
 
      For example,
 
      struct B {
          int x;
          int f() { return x; }
          B(int a) : x(a) { }
      };
      struct L : B { L(int a) : B(a) {} };
      struct R : B { R(int a) : B(a) {} };
      struct D : L, R { D():L(1), R(2){}};
      int (B::*pb)() = &B::f;
      int (L::*pl)() = pb;
      int (R::*pr)() = pb;
      int (D::*pdl)() = pl;
      int (D::*pdr)() = pr;
 
      The hierarchy looks like:
 
      pdl-> B   B <- pdr
            |   |
            L   R
             \ /
              D
 
      Under this proposal pdl is not equal to pdr.
 
      Straw Vote: Who opposes this recommendation? 0.
 
      Unruh asked if this applies to pointers to virtual or non-virtual member
      functions.  Adamczyk explained that the WP already has rules regarding
      pointers-to-members to virtual functions (clause 5.10) that leave the
      result unspecified.
 
      ==== Core (Lajoie) ====
 
      Schwarz presented a proposal to clarify the One-Definition Rule (ODR)
      (N0716 = 95-0016 and N0746 = 95-0146).  His goal was to specify rules
      that are simple, effective, and usable.  The proposal describes five
      separate "ingredients" that definitions must meet to satisfy the ODR:
 
      1.  "token identity" -- each definition must use the same token se-
          quence.  For example, the following definitions for class D violate
          the ODR:
 
          // in one file
 
          class D {
              int i;
              int a[10];
          };
 
          // in another file
 
          class D {
              int i;
          private:
              int a[0xa];
          };
 
      2.  "name identity" -- after lookup, overload resolution, etc., corre-
          sponding names used in the definitions must refer to the same en-
          tity.  For example, the following violates the ODR:
 
          // in one file
 
          typedef int *P;
          class D {
              P r;
          };
 
          // in another file
 
          typedef short int *P;
          class D {
              P r;
          };
 
          As another example, the following violates the ODR if it appears in
          more than one translation unit:
 
          static int i;
          class D {
              int f() { return i; }
          };
 
      3.  "value identity" -- a name in a definition in more than one trans-
          lation unit referring to a const object with internal or no linkage
          need not be identical as long as the type and value are the same.
          For example, the following does not violate the ODR:
 
          const int ten = 10;
          class D {
              int a[ten];
          };
 
      Gafter asked why we should allow this.  Schwarz said code such as this
      already exists.  Also, he didn't want to encourage using macros for
      constant expressions.
 
      4.  implicit functions calls within definitions must also be the same.
          For example, the following violates the ODR:
 
          // in one file
 
          void *operator new(size_t, int); // 2nd parameter has type int
          class D {
              int *f() { return new (10) int; }
          };
 
          // in another file
 
          void *operator new(size_t, long); // 2nd parameter has type long
          class D {
              int *f() { return new (10) int; }
          };
 
      5.  generated constructor definitions must use the same constructors for
          corresponding objects.  For example, the following violates the ODR
          because the two Ds do not use the same constructor as B's default
          constructor:
 
          // in one file
 
          class B {
              B(int);
              B(int, int);
          };
          B(int = 0) { }
          class D : public B { }
          D d1;
 
          // in another file
 
          class B {
              B(int);
              B(int, int);
          };
          B(int = 0, int = 0) { }
          class D : public B { }
          D d1;
 
      Schwarz explained that the other possibility is to outlaw default argu-
      ments on out-of-line member function definitions.
 
      Schwarz showed another example that was posted to an e-mail reflector:
 
      extern inline void f() { }
      class D {
          void g() { f(); }
      };
 
      He said this is OK.  Eliminating the "extern" makes it a "potential vio-
      lation" of the ODR.  A potential violation becomes an actual violation
      if it appears in more than one translation unit.
 
      Schwarz emphasized that ODR violations need not be diagnosed.  (See
      Motion 5 regarding the ODR.)
 
      Straw Vote: Who favors this proposal to specify the ODR? lots yes, 0 no,
          0 abstain.
 
      Schwarz proposed a new rule that out-of-class member function defini-
      tions may not contain default arguments.  (See Motion 6.)  For example:
 
      class B {
          B(int);
          B(int, int);
      };
      B(int = 0) { }      // forbid this
      class D : public B { }
      D d1;
 
      Gibbons said this is overkill.  It could be handled by a rule that dis-
      allows adding a default argument value to the first parameter of a con-
      structor defined outside its class.  Ball and Gafter argued that
      Gibbons' alternative would not solve the problem.  Schwarz said Gibbons
      was right in principle, but didn't phrase the rule correctly.  (Schwarz
      hinted that some other rule would do it).
 
      Plum asked whether this would merit a diagnostic.  Schwarz said there's
      no reason not to diagnose it -- it doesn't involve multiple translation
      units.
 
      Straw vote: Who favors this proposal? lots yes, 2 no, 4 abstain.
 
      Schwarz proposed the following rule: A program has undefined behavior,
      if for some name f, there are definitions of more than one function with
      that name and extern "C" linkage.  (See Motion 7.)  For example,
 
      namespace N {
          extern "C" void f() { }
      }
      extern "C" void f() { }
 
      Unruh wanted this to apply to declarations as well as definitions.
 
      Straw vote: Who favors the rule as proposed by Schwarz: lots yes, 0 no,
          4 abstain.
 
      Lajoie presented several resolutions to linkage issues.  She began with
      this example:
 
      struct X {
          void f() { g(); }
          void g() { h(); }
      };
      X x;
      x.f();
 
      Clause 7.1.2 currently states "A call to an inline function shall not
      precede its definition."  Lajoie explained that this constraint pro-
      hibits the call to g in X::f.  The WG recommended deleting this con-
      straint.  (See motion 8.)
 
      Stroustrup explained that the restriction was originally intended to
      facilitate generating good code.  Gibbons agreed with the proposal, and
      suggested that compilers can issue a warning if they can't in fact in-
      line the function.
 
      Straw Vote: Who favors this proposal? lots yes, 5 no, 6 abstain.
 
      Lajoie then explained that the WP currently states that an unnamed class
      defined in a declaration with a typedef specifier gets a dummy name.
      The WG recommended revising the WP to state that:
 
          An unnamed class has no linkage, except when it is defined in a
          typedef for a class type, in which case it has external linkage.
 
      (See motion 8.)
 
      Lajoie gave this example:
 
      typedef class { } S;    // class has external linkage
      class { } x;            // class has no linkage
 
      This change removes the need to give the second class in the example a
      dummy name.
 
      Lajoie gave additional examples:
 
      typedef struct { } *ps;
 
      ps p;           // becomes ill-formed
      void f(ps);     // becomes ill-formed
 
      She explained that this proposal changes these constructs from having
      undefined behavior to being ill-formed.
 
      Koenig suggested this proposal turns
 
      void f(struct { } *);
 
      into a C incompatibility.  Unruh explained that a call to f has unde-
      fined behavior, but its declaration does not.  Schwarz added that the
      problem with this f is that we don't know how to "mangle" its name.
 
      Nelson said he didn't think this proposal increased the set of C pro-
      grams that aren't C++; it just changes the way they are diagnosed.
 
      Straw Vote: Who agrees with this proposal?
          WG21+X3J16: 18 yes, 12 no, 18 abstain.
          WG21 only: 4 yes, 0 no, 2 abstain.
          X3J16 only: 20 yes, 8 no, 14 abstain.
 
      Lajoie presented resolutions to issues regarding new and delete (N0748 =
      95-0148).  She said the WG recommended that operators new and delete can
      only be declared in class scope or at file scope; they can't be declared
      in a named namespace.  (See Motion 9.)
 
      Stroustrup asked why.  Lajoie replied that if operator new and operator
      delete could be declared in a namespace, the name look up rules for
      these operators would have to be revised substantially.  Since no member
      of the Core WG cared enough about this functionality to work on a pro-
      posal, the WG decided to clarify the WP by making the restrictions im-
      plied in 3.7.3 explicit.
 
      Straw Vote: Who favors this proposal? lots yes, 0 no, 9 abstain.
 
      Unruh observed that adopting this proposal means the library's global
      new and delete must be at file scope.
 
      Lajoie then proposed a change in the lookup rules for class-specific
      operators new and delete.  She gave this example:
 
      struct A {
          void *operator new(size_t);
          struct B { };
      };
 
      new A::B;       // finds global new
 
      According to he current WP, it finds A::new.
 
      The proposed new lookup rule for operators new and delete is:
      --  look in the scope of A::B
      --  if no allocation function is found, look in the global scope
 
      (See Motion 9.)
 
      Saks asked what "new B" calls when in the scope of B.  Lajoie said it
      still calls the global new.
 
      Straw Vote: Who favors this proposal? lots yes, 0 no, 2 abstain.
 
      ==== Core (Gibbons) ====
 
      Gibbons said the WG recommended resolving the following template issues
      from N0701 = 95-0101 as recommended in that paper: issues 2.24, 2.27,
      3.24, 3.25, 3.26, 3.27, 4.11, 7.3/2.  (See Motion 10.)
 
      Gibbons said the WG also recommended resolving the following issues with
      changes from the proposals in N0701 = 95-0101: 2.25, 2.26, 7.2, 7.4,
      7.5, and 7.6.  The revised proposals appear in N0744 = 95-0144.  (See
      Motion 11.)
 
      Straw Vote: Who agrees with the recommendations? lots yes, 0 no, 2
          abstain.
 
      Gibbons then presented a proposal to specify the syntax for declaring
      specializations (item 4.10 of N0701 = 95-0101, plus N0743 = 95-0143,
      with minor changes to both).  (See Motion 12.)  Corfield said this also
      solves the problem that static member specializations must be declared
      everywhere they are used but defined only once.
 
      Straw Vote: Who agrees with this recommendation? lots yes, 0 no, 1
          abstain.
 
      Gibbons presented a proposal to relax restrictions on the return type of
      operator-> (as discussed in N0719 = 95-0019, part 2).  (See Motion 13.)
 
      Straw Vote: Who agrees with this proposal? lots yes, 0 no, 1 abstain.
 
      Gibbons explained that the WG discussed name injection from class
      templates, and the consequences of doing injection at the point of
      instantiation.  There appear to be serious problems, but they had no
      written proposal.  He expected that we'd see a proposal to remove name
      injection at the next meeting.
 
      Gibbons then presented a proposal to provide a means for determining if
      stack unwinding is in progress (N0692 = 95-0092).  That is, it provides
      a way to test if the program has evaluated a throw expression, but not
      yet completed initialization of the handler.  The WG recommended adopt-
      ing the proposal as in N0692 = 95-0092, except they changed the name
      "throwing" to "uncaught_exception".  (See Motion 14.)  Gibbons explained
      that this facility is necessary for high availability systems, and
      there's no alternative in the language
 
      Straw Vote: Who favors this proposal? lots yes, 0 no, 0 abstain.
 
      Gibbons then presented a proposal to allow the volatile qualifier in
      exception declarations, as in
 
      catch (const volatile T& t) { ... }
 
      The WG saw no need to disallow volatile in this context.  The change
      allows calls to volatile member functions applied to thrown objects.
 
      Schwarz noted that thrown objects are always temporaries (rvalues).
      Adamczyk pointed out an earlier change that you can't bind a const
      volatile & to an rvalue.  Gibbons offered to withdraw the proposal.
 
      Straw Vote: Who thinks this is not ready for a formal vote? 20 yes.
 
      Gibbons said he'd keep this on the issues list.
 
      Gibbons presented a proposal to allow qualification conversions when
      matching types for handlers.  (See Motion 16.)  For example, the pro-
      posal would allow
 
      throw new A();
 
      to be caught by
 
      catch (const A *a) { ... }
 
      Gibbons said these conversions were accidentally removed when clause 4
      was restructured, because clause 15 refers to clause 4.
 
      Straw Vote: Who agrees with this proposal? lots yes, 0 no, 1 abstain.
 
      Gibbons proposed extending the C "struct hack" to namespaces.  (The
      "struct hack" allows a class or enum name to have the same spelling as a
      nontype name in the same scope.)  (See Motion 15.)  Gibbons explained
      that this is intended to aid conversion of C code to C++ with name-
      spaces.
 
      Straw Vote: Who agrees with this recommendation?  lots yes, 1 no, 3
          abstain.
 
      Stroustrup presented a proposal to simplify name lookup for qualified
      names in namespaces (based on N0728 = 95-0128).  He gave this example:
 
      namespace A {
          int i;
      }
 
      namespace B {
          using namespace A;
          int j;
      }
 
      void f()
      {
          A::j++;
          B::i++;         // 1
          B::j++;
          using namespace B;
          i++;            // OK
          j++;
      }
 
      He explained that the current WP does not allow the reference to B::i on
      // 1, but people expect it to work.  This proposal makes it work.  (See
      Motion 17.)
 
      Straw Vote: Who favors this proposal? lots yes, 0 no, 3 abstain.
 
6.2   Library WG
 
      ==== Dawes ====
 
      Dawes introduced several resolutions covering 41 issues from Clauses 17
      through 20 (library front matter, diagnostics, and utilities).  He said
      his subgroup unanimously supported all these resolutions.  Dawes briefly
      summarized all but one of the motions.  He said there's no point in a
      straw vote; he asked WG21+X3J16 to wait until Thursday to see the de-
      tails of the motions in print before raising any objections .  (See
      Motions 18 through 20, 22 and 23.)
 
      Henricson summarized the remaining proposal from Dawes' subgroup, which
      recommended a policy for using exception specifications in the standard
      library (N0741 = 95-0141).  (See Motion 20.)
 
      Unruh asked that the library distinguish between an exception thrown by
      an argument to a standard function call and an exception thrown by a
      standard function itself.  (The latter must be derived from the standard
      exception class.)  Stroustrup said Unruh's conceptual model is correct
      but can't be mandated.
 
      Straw Vote: Who favors this proposal? lots yes, 0 no, 7 abstain.
 
      ==== Wilhelm ====
 
      Wilhelm introduced a pair of proposals regarding Clause 21 (strings).
      The first proposal was to resolve various open issues raised in N0721R1
      = 95-0121R1.  (See Motion 24.)  The second proposal was to remove some
      overloaded member functions from the basic_string class template (N0694
      = 95-0094, part 1).  (See Motion 25.)
 
      Lenkov asked if anyone objected to these proposals.  No one did.
 
      ==== Myers ====
 
      Myers proposed resolutions to numerous issues regarding Clause 22 (from
      N0698 = 95-0098R1).  (See Motions 26 through 29.)
 
      Plum raised concerns over the basic architecture of the C++ standard
      library.  He said there are at least three approaches: 1) implement the
      C++ components as a layer around any standard C library; 2) implement
      the C and C++ libraries as an integrated collection, 3) implement the
      library as a layer around one specific C library.  Plum said he assumed
      it was committees' intent to not favor one over another.  Myers replied
      that the current implementation for locales doesn't allow (1).  He said
      he didn't think the committees ever said they wanted that.  Plum said
      the committees previously rejected one model for implementing locales
      that had to be implemented on top of C, and apparently Myers took this
      to mean the committees wanted to preclude (1).
 
      Myers said the issues this affects are not up for vote right now, and he
      thought interested parties could work something out.
 
      Schwarz explained that the original design for iostream was not intended
      to be layered on top of stdio.  Maybe some ingenious person could do it,
      but it certainly wasn't in the plan.
 
      Plauger thought we shouldn't demand that the C++ library be implemented
      on top of the C library, but we shouldn't preclude it either.  He
      thought he had been asking for this for some time.
 
      ==== Podmolik ====
 
      Podmolik introduced a proposal to resolve several issues regarding
      clause 23 (containers) (from N0697R4 = 95-0097R4).  (See Motion 30.)
 
      Podmolik then explained that Stroustrup had asked the Library WG to con-
      sider adding hash tables to the standard containers.  Stroustrup had
      argued that since the project schedule had slipped, we would have time
      to fully integrate hash tables in the library.  Podmolik said the sub-
      group turned down the request 8 to 11 (many abstained).
 
      Stroustrup said he was concerned that dropping hash tables may lead to a
      split vote on Friday between WG21 and X3J16.
 
      Straw Vote (WG21 only): Who feels strongly that we should reconsider
          adding hash tables? 0 yes.
 
      Straw Vote: Who agrees with these resolutions to the clause 23 issues?
          lots yes, 1 no.
 
      Podmolik then presented a proposal to resolve several open issues re-
      garding clause 26 (numerics) (from N0710R2 = 95-0110R2).  (See Motion
      31.)
 
      Straw Vote: Who favors this proposal? lots yes, 0 no.
 
      ==== Dodgson ====
 
      Dodgson introduced a few proposals regarding clauses 24 and 25 (itera-
      tors and algorithms).  The first proposal was to add operator-> for
      iterators (N0738 = 95-0138).  (See Motion 32.)
 
      Gafter suggested relaxing the language rules so that operator-> would be
      checked at each call point, not at its declaration.  Corfield said C++
      already checks templates at the call point, and the standard iterators
      are all templates.  Gafter asked what, if anything, we should do about
      non-template iterators.
 
      Koenig noted that the proposal says an iterator must define operator->
      "if it works".  He didn't think this was meaningful.  It works if it
      works, and doesn't work if it doesn't work.  Koenig was also concerned
      that it might be hard to define operator-> for input iterators.  Lenkov
      suggested approving the proposal as is, and opening an issue on whether
      to allow operator-> for input iterators.
 
      Next, Dodgson proposed adding operator+ and operator- for iterators
      (N0739 = 95-0139).  (See Motion 33.)
 
      Koenig suggested this might break existing code.  If the library expects
      operator+ and operator- to be defined, and you don't supply them, code
      won't compile.  Plauger defended these additions are very convenient for
      algorithm designers -- that's why Stepanov asked for them.
 
      Straw Vote: Who favors this proposal?
          WG21+X3J16: 25 yes, 1 no, 18 abstain.
          WG21 only:  3 yes, 0 no,  3 abstain.
 
      Dodgson presented a proposal for some small changes to clauses 24 and 25
      (N0740 = 95-0140).  (See Motion 34.)  Lenkov asked for objections; there
      were none.
 
      Lenkov closed the committee of the whole.
 
The committees recessed at 18:15 on Wednesday and reconvened at 08:30 on
Thursday.
 
      Clamage (acting as chair) opened the committee of the whole.
 
      ==== Clamage ====
 
      Clamage introduced numerous small changes to iostreams in response to
      public comments (N0749 = 95-0149).  (See Motion 35.)  No one objected.
 
6.3   Extensions WG
 
      R. I. P.
 
6.4   Environments WG
 
      No discussion.
 
6.5   C Compatibility WG
 
      Plum presented a proposal to allow implementation dependent extension
      support (N0731 = 95-0131).  He explained that the C standard allows ex-
      tensions provided they do not change the behavior of a strictly conform-
      ing program.  The Japanese delegation requested similar leeway in C++.
      This proposal allows an implementation to, say, extend the language to
      allow national characters in identifiers.  The implementation must issue
      a diagnostic, but then it can accept the program provided it does not
      change the behavior of a well-formed program.
 
      Koenig expressed concern that this also allows, say, an implementation
      to ignore private and protected access specifiers (after issuing at
      least one diagnostic).  Stroustrup agreed that this is real problem.
      Meyers explained why this proposal is not the same as what Koenig and
      Stroustrup were concerned about.  Plum said he'd rather treat mandated
      diagnostics as a separate issue.
 
      Unruh observed that the WP currently allows an implementation to issue
      just one diagnostic for any violation, and then proceed with the trans-
      lation.  Plum said this proposal means we acknowledge that the draft is
      this way, and we intend to allow extensions.
 
      Committee discussed limiting this to only allow extended characters in
      identifiers.  Saks said this is probably not the only use for these ex-
      tensions.  He was concerned that this issue would come up again if we
      limited the proposal too much.
 
      Stroustrup and Bruck emphasized there is support for extended characters
      in identifiers.
 
      Straw Vote: Who favors this proposal?
          WG21+X3J16: lots yes, 5 no, 5 abstain.
          WG21 only: 5 yes, 0 no, 1 abstain.
 
      Stroustrup said he was afraid we just opened can of worms.
 
6.6   Formal Syntax WG
 
      No discussion.
 
6.2   Library WG (revisited)
 
      Myers presented a proposal to clarify when input iterators are invalida-
      ted.  The proposal was to add a statement that "input iterators are not
      equality preserving".  He also presented some other issues regarding
      streambuf_iterators.  The discussion went nowhere.
 
6.7   Editing Procedures
 
      Harbison presented his clarification of the editorial procedures (N0751
      = 95-0151).  Some members expressed lingering confusion over editorial
      boxes.  When can the editor remove a box?  Are there different kinds of
      boxes?
 
      Plum asked that this be a straw vote, not a formal motion.  Schwarz
      thought this procedure should apply only to WG21, not to X3J16.
 
      Straw vote: Who supports this clarification of the editing procedures?
          lots yes, 0 no, 3 abstain.
 
      Bruck asked that this resolution be a formal motion.  Plum said he would
      not object if all references to WG21+X3J16 in the resolution referred
      instead to just WG21.  (See Motion 37.)
 
      Clamage closed the committee of the whole.
 
The committees recessed at 10:15 on Thursday and reconvened at 16:10 on
Thursday.
 
7     WG Sessions
 
8     Distribute formal motions
 
9     General Session II
 
9.1   Core WG
 
      ==== Gibbons ====
 
      Gibbons summarized his subgroup's discussion of pointer-to-member casts
      across virtual bases:
      --  Many compilers don't implement it.
      --  It has surprising runtime overhead.
      --  There's no existing practice.
      Hence, it's not worth it.
 
      He also summarized their discussion of pointer-to-member casts to base
      classes:
      --  It's arguably in the ARM.
      --  It reflects current practice (including widely used class librar-
          ies).
      --  It has minimal implementation and runtime costs.
      His subgroup unanimously supported this.
 
      ==== Lajoie ====
 
      Lajoie explained that the current WP clearly says extern "C" is not part
      of a function's type.  The WG agreed it was too late to change this.
      She said the WG will look at changing the WP to leave it implementation-
      defined whether extern "C" is part of the type system.
 
      Gibbons observed that exception specifications are another declaration
      attribute that is not part of the type system.  He suggested treating
      extern "C" the same as except specifications.
 
      Lajoie said the WG also discussed the extent to which an implementation
      uses ::operator new.  They reached some conclusions:
      Is it used to allocate...
      --  objects of static or auto storage?    No
      --  temporaries?                          ???
      --  exception handling data structures?   ???
      --  RTTI data structures?                 ???
      --  wherever needed in the library?       Yes
 
9.2   Library WG
 
      Wilhelm said the WG discussed problems in clause 21 (strings).  Speci-
      fically, they discussed:
      --  restructuring string_char_traits
      --  modifying requirements on charT
      --  implementation limits and max_size()
      --  adding c_strlen()
      --  revising the pattern for parameters, overloads and default arguments
 
      Regarding the last item, Steinmuller showed that the second parameter to
      the string append function has inconsistent semantics:
 
      s.append(string("abc"), 1) != s.append("abc", 1)
                              ^ position            ^ length
 
9.3   Extensions WG
 
      Nothing.
 
9.4   Environments WG
 
      Nothing.
 
9.5   C Compatibility WG
 
      Nothing.
 
9.6   Formal Syntax WG
 
      Nothing.
 
9.7   Schedule Change
 
      Harbison discussed the project schedule.  He explained that, a few meet-
      ings ago, we discovered that the ISO policy on DIS ballot was different
      from what we previously understood.  We thought we could still make
      changes to the draft document after sending it for DIS, but in fact, we
      can't.  When we found out, we decided to remain optimistic; however, it
      was time to slip the schedule.
 
      He suggested taking a four month delay to dispose of comments from the
      CD ballot and update the draft accordingly.  He thought we'd probably
      stage another CD ballot after March '96.  We'd get the results from the
      second CD ballot in November '96, and stage the DIS ballot in March '97.
 
      Plauger said what's important this week is what we didn't do.  We didn't
      add twenty more pages of standardese.  We didn't add hash tables.  Even
      if it takes us a few more years, the world will think we're done because
      we've stopped adding to the language.
 
      Harbison said we'd hold at least one meeting while the DIS ballot is in
      progress.  We may use that time to transition into handling defect re-
      ports.  We may also decide then to meet less frequently.
 
      Harbison suggested moving the March '96 meeting to a few weeks earlier.
      This might give us a little more time after that meeting to edit the
      draft.  The suggestion received little support.
 
      The UK offered to host the July '97 meeting.  Harbison said we still
      have no hosts for the March and November '97 meetings in the continental
      US.  Also, the July '97 meeting will not be the week including July
      11th, to avoid conflicts with the July 4th holiday in the US and, pos-
      sibly, the Wimbledon tournament in the UK.
 
      Ball asked whether we would pursue option 2 or option 3 from N0751 =
      95-0151.  Bruck said Sweden favored option 2, which gives a faster turn-
      around.  Several others agreed.  Harbison agreed to shoot for option 2.
      No one objected.
 
10    WG sessions (if any time left)
 
      Clamage closed the committee of the whole.
 
The committee recessed at 17:30 on Thursday and reconvened at 08:45 on Friday.
 
11    Review of the meeting
 
      WG21+X3J16 reviewed the wording of the formal motions in preparation for
      voting.
 
      Schwarz said he did not intend to move motion 6 because Gibbons said
      he'd invoke X3's "two-week" rule.  (The "two-rule" states that if an X3
      technical committee raises an issue less than two weeks before a meet-
      ing, that committee may vote on it at the meeting only if no voting
      member objects.)  Gibbons said he thought this measure wasn't necessary
      for the ODR, nor was it discussed thoroughly as a separate topic.  No
      WG21 delegation objected to withholding motion 6.
 
      Lenkov counted 47 X3J16 voting members and six WG21 delegations.
 
11.1  Formal motions
 
      1)  Motion (to accept the WP) by Lajoie/Bruck:
 
          Move we accept N0687 = 95-0087 as the current WP.
 
      Motion passed X3J16: lots yes, 0 no, 1 abstain.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      ==== presented by Adamczyk ====
 
      2)  Motion (to resolve numerous core issues) by Adamczyk/Holaday:
 
          Move we amend the WP as follows:
 
          a)  (to allow no more than three digits in octal escapes in char-
              acter constants and strings):
 
              Amend 2.9.2 [lex.ccon] as follows:
 
              --  Replace the grammar production for octal-escape-sequence
                  with:
 
                  octal-escape-sequence:
                      \ octal-digit
                      \ octal-digit octal-digit
                      \ octal-digit octal-digit octal-digit
 
              --  In paragraph 4, change "one or more octal digits" to "one,
                  two, or three octal digits" and change "There is no limit to
                  the number of digits in either sequence" to "There is no
                  limit to the number of digits in a sequence of hexadecimal
                  digits".
 
          b)  (to clarify the evaluation order for mem-initializers):
 
              Add the following to the end of paragraph 3 of 12.6.2
              [class.base.init] (after the two bullets):
 
                  There is a sequence point (_intro.execution_) after the
                  initialization of each base and member.  The expression-list
                  of a mem-initializer is evaluated as part of the initiali-
                  zation of the corresponding base or member.
 
          c)  (to allow pointer and pointer-to-member arguments to be passed
              to an ellipsis):
 
              Replace paragraph 7 of 5.2.2 [expr.call] with the following:
 
                  When there is no parameter for a given argument, the argu-
                  ment is passed in such a way that the receiving function can
                  obtain its value by an invocation of va_arg (_lib.support.
                  runtime_).  The argument shall have arithmetic, enumeration,
                  pointer, pointer to member, or class type; otherwise the
                  program is ill-formed.  If the argument has a non-POD class
                  type (_class_), the behavior is undefined.  If the argument
                  has an integral or enumeration type that is subject to the
                  integral promotions (_conv.prom_), or a floating point type
                  that is subject to the floating point promotion (_conv.
                  fpprom_), the value of the argument is converted to the pro-
                  moted type before the call.  These promotions are referred
                  to as the default argument promotions.
 
          d)  (to disallow operator= in POD classes):
 
              In paragraph 4 of clause 9 [class], at the end of the sentence
              "A POD-struct is an aggregate class that has no members of type
              ... non-POD-union" add ", and no user-defined copy assignment
              operator."  Add the same text to the end of the next sentence
              (beginning "Similarly, a POD-union ...").
 
          e)  (to mandate access checking on throw/catch and overloaded
              functions):
 
              Amend the WP as specified in N0704 = 95-0104.
 
          f)  (to specify access of a redeclared member):
 
              Amend the WP as specified in N0703 = 95-0103.
 
          g)  (to eliminate protected member access check for static data
              members, etc.):
 
              Delete paragraph 1 of 11.5 [class.protected].
 
              Replace the first sentence in paragraph 2 of 11.5 [class.
              protected] with:
 
                  When a friend or a member function references a protected
                  non-static member of a base class, an access check applies
                  in addition to those described earlier in this clause.
 
                  [Footnote: This additional check does not apply to other
                  members, e.g., static data members.]
 
              Delete the following sentence from paragraph 2 of 11.5
              [class.protected]:
 
                  If the nonstatic protected member thus accessed is also
                  qualified, the qualification is ignored for the purpose of
                  this access checking.
 
          h)  (to allow the left operand of a compound assignment operator to
              have bool type):
 
              Amend the WP as specified in point 3 of N0714 = 95-0114.
 
          i)  (to clarify that operators such as "+" can take enum operands:)
 
              Amend the WP as specified in core issues 489, 490, 491, 492,
              494, 495, and 498 of N0711 = 95-0111 (these issues begin on page
              13 of that paper).
 
          j)  (to remove bool decrement and add pointer-to-member assignment
              in prototypes for built-in operators in overload resolution):
 
              --  In 13.6 [over.built] replace paragraph 4 with:
 
                  For every pair (T, VQ), where T is an arithmetic type, and
                  VQ is either volatile or empty, there exist candidate opera-
                  tor functions of the form:
 
                      VQ T&   operator++(VQ T&);
                      T       operator++(VQ T&, int);
 
                  For every pair (T, VQ), where T is an arithmetic type other
                  than bool, and VQ is either volatile or empty, there exist
                  candidate operator functions of the form
 
                      VQ T&   operator--(VQ T&);
                      T       operator--(VQ T&, int);
 
              --  After paragraph 19 of the same section, add:
 
                  For every pair (T, VQ), where T is a pointer to member type
                  and VQ is either volatile or empty, there exist candidate
                  operator functions of the form
 
                      VQ T&   operator=(VQ T&, T);
 
          k)  (to clarify when "?" operator yields an lvalue):
 
              Change the last sentence of paragraph 3 of 5.16 [expr.cond] to:
 
                  The result is an lvalue if the second and the third operands
                  are of the same type (before any implicit conversions) and
                  both are lvalues.
 
          l)  (to define comparison of pointers to members):
 
              In paragraph 2 of 5.10 [expr.eq] replace the second sentence
              with:
 
                  A null pointer to member value compares equal to another
                  null pointer to member value, and unequal to any other
                  pointer to member value.  Two pointers to members that are
                  not null pointer to member values compare equal if and only
                  if they would refer to the same member of the same complete
                  object or of the same subobject if they were dereferenced
                  with a hypothetical object of the associated class type.
 
          m) (to remove unapproved change to definition of aggregate):
 
              In 8.5.1 [dcl.init.aggr], remove the words "no non-static
              members of reference type, no non-static const members,".
 
      Corfield asked to omit (h) from the motion.  Adamczyk/Holaday accepted
      this as a friendly amendment.
 
      Motion (as amended) passed X3J16: lots yes, 0 no.
      Motion (as amended) passed WG21: 6 yes, 0 no, 0 abstain.
 
      Motion to approve (2h) by Adamczyk/Micco.
 
      Motion passed X3J16: lots yes, 11 no.
      Motion passed WG21: 3 yes, 1 no, 2 abstain.
 
      3)  Motion (to more precisely specify volatile semantics) by Eager/
          Adamcyzk:
 
          Move we amend the WP as specified in point 1 of the Proposed Changes
          section of N0707 = 95-0107.
 
      Ball said he opposed this motion because it imposes unreasonable con-
      straints on volatile semantics.  He thought the C standard already says
      as much as can be said.  This proposal would force him to document that
      the set of types in his implementation that have these semantics is
      empty.
 
      Stroustrup said Ball is suggesting that we are about to do the equiv-
      alent of voting that the value of pi is 3.
 
      Eager/Adamczyk withdrew the motion.
 
      4)  Motion (to eliminate references in unions) by Adamczyk/Myers:
 
          Move we amend the WP as specified in Option 1 of N0709 = 95-0109.
 
      Harbison pointed out that Australia and New Zealand are on record as
      opposing this.  Corfield said UK previously opposed this and are not
      happy that it came back for another vote in exactly the same form.
 
      Plum said we've had plenty of discussion on unions on reflector.  The
      draft does not specify the semantics for unions very clearly, and this
      proposal at least clarifies the status quo.  If proponents of "union as
      first class objects" would come forth with a proposal, we can still
      consider it, but leaving the status of unions "in a gray area" is not
      good.
 
      Motion passed X3J16: lots yes, 2 no.
      Motion passed WG21: 4 yes, 1 no, 1 abstain.
 
      ==== presented by Schwarz ====
 
      5)  Motion (to describe the One Definition Rule) by Schwarz/Wilkinson:
 
          Move we amend the WP as described in N0746 = 95-0146.
 
      Motion passed X3J16: lots yes, 0 no.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      6)  Motion (to forbid adding default arguments in certain definitions):
 
          Move we amend the WP by add the following as a new paragraph between
          paragraphs 3 and 4 of 8.3.6 [dcl.fct.default]:
 
              Out of class member function definitions shall not contain
              default arguments.
 
      No one moved this.
 
      7)  Motion (to forbid multiple extern "C" definitions) by Schwarz/
          Wilkinson:
 
          Move we amend the WP by adding to the end of 3.2 [basic.def.odr]:
 
              A program has undefined behavior if the same name is used in
              more than one extern "C" function definition.
 
      Motion passed X3J16: lots yes, 1 no.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      ==== presented by Lajoie ====
 
      8)  Motion (to resolve assorted linkage issues) by Lajoie/Anderson:
 
          Move we amend the WP as described in N0747 = 95-0147.
 
      Motion passed X3J16: lots yes, 0 no.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      9)  Motion (to resolve assorted issues on new and delete) by Lajoie/
          Bruns:
 
          Move we amend the WP as described in N0748 = 95-0148.
 
      Motion passed X3J16: lots yes, 1 no.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      ==== presented by Gibbons ====
 
      10) Motion (to accept proposed resolutions to various template issues)
          by Spicer/Gibbons:
 
          Move we amend the WP according to part 1 of N0744 = 95-0144.
 
      Motion passed X3J16: lots yes, 0 no.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      11) Motion (to resolve various template issues) by Spicer/Corfield:
 
          Move we amend the WP according to part 2 of N0744 = 95-0144.
 
      Motion passed X3J16: lots yes, 0 no.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      12) Motion (to specify the syntax for declaring specialisations) by
          Corfield/Spicer:
 
          Move we amend the WP as follows:
 
          --  adopt the proposal in issue 4.10 of N0701 = 95-0101, with the
              following change:
 
              point 1., delete the last sentence.
 
          --  adopt the proposal in N0743 = 95-0143 with the following change
              to the suggested "WP changes":
 
              Replace the following sentence from 14.5 [temp.spec], paragraph
              1:
 
                  [Note: a static member of a template can only be specialized
                  in a definition due to syntactic restrictions.]
 
              with:
 
                  A specialization of a static data member of a template is a
                  definition if the declaration includes an initializer;
                  otherwise, it is a declaration.
 
              and add an editorial box acknowledging that there is still no
              syntax for default initialization of said member.
 
      Motion passed X3J16: lots yes, 0 no.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      13) Motion (to relax restrictions on the return type of operator->) by
          Corfield/Scian:
 
          Move we amend the WP as proposed in part 2 of N0719 = 95-0119.
 
      Motion passed X3J16: lots yes, 0 no.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      14) Motion (to provide a means of determining whether stack unwinding is
          in progress) by Gibbons/Bruck:
 
          Move we amend the WP as proposed in N0692 = 95-0092 with the fol-
          lowing changes:
 
          --  replace "throwing" by "uncaught_exception" throughout the "Pro-
              posal" section except for the last sentence which should read:
 
                  Notes: When uncaught_exception() is true, throwing an
                  exception can result in a call to terminate (_except.
                  terminate_)
 
          --  change 15.5.1 [except.terminate] to cross-reference 15.5.3
              [except.uncaught] instead of 18.6.3 [lib.terminate]
 
          --  add a cross-reference from 15.5.3 [except.uncaught] to 18.6.3
              [lib.terminate]
 
          --  add a cross-reference from 18.6.3 [lib.terminate] to 15.5.3
              [except.uncaught]
 
      Motion passed X3J16: lots yes, 0 no.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      15) Motion (to allow the C "struct hack" to persist across namespaces)
          by Ball/Stump:
 
          Move we amend the WP as follows:
 
          --  in 7.3.3 [namespace.udecl] replace paragraph 10 by:
 
              In a set of local declarations and using-declarations for a
              single name given in a single declarative region, either they
              shall all refer to the same entity or all refer to functions, or
              if one declaration refers to a class name or enumeration name,
              the other declarations shall all refer to the same entity or all
              refer to functions and the class name or enumeration name is
              hidden. (see 3.3.6 [basic.scope.hiding])
 
          --  remove editorial box 33
 
      Motion passed X3J16: lots yes, 2 no.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      16) Motion (to allow qualification conversions in a handler) by
          Gibbons/Spicer:
 
          Move we amend the WP by adding to 15.3 [except.handle] paragraph 2,
          subpoint [3], after "base classes":
 
              , or a qualification conversion (4.4 [conv.qual]), or a combina-
              tion of these two.
 
      Motion passed X3J16: lots yes, 0 no.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      17) Motion (to provide simpler lookup rules for qualified name lookup in
          namespaces) by Bruck/Corfield:
 
          Move we accept the recommendations of N0728 = 95-0128 by amending
          the WP as proposed in N0745R1 = 95-0145R1.
 
      Motion passed X3J16: lots yes, 0 no.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      ==== presented by Dawes ====
 
      18) Motion (to change the requirements on arguments to functions using
          the stdarg macros) by Dawes/Micco:
 
          Move we amend the WP as described in N0695 = 95-0095.
 
      Motion passed X3J16: lots yes, 1 no.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      19) Motion (to resolve several library issues from Clause 18 Issues
          List) by Dawes/Henricson:
 
          Move we adopt the proposed resolutions for issues 007 and 009
          through 012 from N0705 = 95-0105, but change the name
          "denormal_loss" to "has_denorm_loss" in 007.
 
      Motion passed X3J16: lots yes, 0 no.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      20) Motion (to resolve several library issues from Clause 20 Issues
          List) by Myers/Dawes:
 
          Move we adopt the proposed resolutions for issues 001 through 013,
          015, and 016 from N0699R1 = 95-0099R1.
 
      Motion passed X3J16: lots yes, 0 no.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      21) Motion (to set exception specification policy for the Standard
          Library) by Henricson/Dawes:
 
          Move we amend the WP as described in N0741 = 95-0141.
 
      Motion passed X3J16: lots yes, 1 no.
      Motion passed WG21: 5 yes, 1 no, 0 abstain.
 
      22) Motion (to specify constraints on template arguments in the Standard
          Library) by Dawes/Rumsby:
 
          Move we amend the WP as described in N0700 = 95-0100, with the
          following changes:
 
          Page 3: delete the "Comparable Requirements" section
 
          Page 4: delete "EqualityComparable" from replace_if,
              replace_copy_if, fill, and fill_n.
 
      Motion passed X3J16: lots yes, 0 no.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      23) Motion (to resolve several public comments regarding the Library) by
          Dawes/Rumsby:
 
          Move we resolve item 18.6.1.1 of public comment T21-118 appearing on
          page 103 of N0736 = 95-0136 by replacing WP subclause 18.6.1.1
          [lib.bad.exception] paragraph 1 with the following:
 
              The class bad_exception defines the type of objects thrown as
              described in [except.unexpected].
 
      Motion passed X3J16: lots yes, 0 no.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      ==== presented by Wilhelm ====
 
      24) Motion (to resolve string issues) by Wilhelm/Rumsby:
 
          Move we accept the proposed resolutions for the following clause 21
          [lib.string] issues from N0721R1 = 95-0121R1:
 
              004, 005, 007, 008, 015, 016, 019, 020, 022, 023, 032, 033, 035,
              036, 038 through 058, 064, 065, 066, 069 through 073.
 
          Also, accept the proposed resolution for issue 21 with the following
          change.  Replace:
 
              int compare(size_type pos, size_type n,
                  charT* s, size_type n = npos) const;
 
              Returns: basic_string(*this, pos, n).compare(basic_string(s, n))
 
          with:
 
              int compare(size_type pos, size_type n1,
                  charT* s, size_type n2 = npos) const;
 
              Returns: basic_string(*this, pos, n1).
                  compare(basic_string(s, n2))
 
          Also, accept the following change to the working paper as the
          resolution for issue 31:
 
              In section 21.1.1.9 [lib.string.ops], add the member:
 
              const allocator_type& get_allocator() const;
 
              Returns: a reference to the string's allocator object.
 
      Motion passed X3J16: lots yes, 0 no.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      25) Motion (to remove overloads on the basic_string template) by
          Wilhelm/Rumsby:
 
          Move we accept "Proposal 1" of N0694 = 95-0094, and add the
          following member to the basic_string template in subclause
          21.1.1.8.6 [lib.string::replace]:
 
              basic_string<charT,traits,Allocator>&
              replace(size_type pos, size_type n1, size_type n2, charT c)
 
              Returns: replace(pos, n1, basic_string(n2, c))
 
      Motion passed X3J16: lots yes, 0 no.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      ==== presented by Myers ====
 
      26) Motion (to resolve minor locale issues) by Myers/Dawes:
 
          Move we accept the proposed resolutions from N0698R1 = 95-0098R1 for
          clause 22 [lib.localization] issues 001 through 008, 011 through
          015, 020, 021, 025, 028, 032, and 036.
 
          Also, accept the proposed resolution for issue 024, but change
          "boolean" to "bool".
 
      Motion passed X3J16: lots yes, 0 no.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      27) Motion (to clarify locale monetary formatting) by Myers/Dawes:
 
          Move we accept the proposed resolutions from N0698R1 = 95-0098R1 for
          clause 22 [lib.localization] issues 026 and 027.
 
      Motion passed X3J16: lots yes, 0 no.
      Motion passed WG21: 5 yes, 0 no, 1 abstain.
 
      28) Motion (to fix locale time_put facet time/date format specification)
          by Dawes/Myers:
 
          Move we accept the proposed resolution from N0698R1 = 95-0098R1 for
          clause 22 [lib.localization] issue 023.
 
      Motion passed X3J16: lots yes, 0 no.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      29) Motion (to clean up istreambuf_iterator and ostreambuf_iterator
          description):
 
          Move we amend the WP as described in documents N0753 = 95-0153 and
          N0754 = 95-0154.
 
      No one moved this.
 
      ==== presented by Podmolik ====
 
      30) Motion (to resolve various containers issues) by Podmolik/Rumsby:
 
          Move we accept the proposed resolutions from N0697R4 = 95-0097R4 for
          clause 23 [lib.containers] issues 004, 011, 012, 014 through 023,
          025, 026, and 027.  In addition, resolve issue 029 by modifying the
          vector constructors in WP subclause 23.2.5.2 [lib.vector.cons] to
          read as follows:
 
              explicit vector(const Allocator& = Allocator());
 
              explicit vector(size_type n, const T& value = T(),
                  const Allocator& = Allocator());
 
              vector(const vector<T,Allocator>& x,
                  const Allocator& = Allocator());
 
              template <class InputIterator>
              vector(InputIterator first, InputIterator last,
                  const Allocator& = Allocator());
 
      Motion passed X3J16: lots yes, 0 no.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      31) Motion (to resolve library numerics issues) by Podmolik/Holaday:
 
          Move we accept the proposed resolutions from N0710R2 = 95-0110R2 for
          clause 26 [lib.numerics] issues 001, 002, 004, 005, and 006.  In
          addition, resolve issue 003 by modifying the description of
          operator<<() in WP subclause 26.2.5 [lib.complex.ops] to read as
          follows:
 
              template <class charT, class traits, class T>
              basic_ostream<charT, traits>&
              operator<<(basic_ostream<charT, traits>& o,const complex<T>& x);
 
              Effects: inserts the complex number x onto the stream o as if it
              were implemented as follows:
 
              template <class charT, class traits, class T>
              basic_ostream<charT, traits>&
              operator<<(basic_ostream<charT, traits>& o,const complex<T>& x)
              {
                  basic_ostringstream<charT, traits> s;
                  s.flags(o.flags());
                  s.imbue(o.getloc());
                  s.precision(o.precision());
                  s << '(' << x.real() << ',' << x.imag() << ')' << ends;
                  return o << s.str();
              }
 
      Motion passed X3J16: lots yes, 0 no.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      ==== presented by Dodgson ====
 
      32) Motion (to add operator-> for iterators) by Dodgson/Corfield:
 
          Move we amend the WP by incorporating the changes specified in N0738
          = 95-0138.
 
      Motion passed X3J16: lots yes, 0 no.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      33) Motion (to add operator+ and operator- for iterators):
 
          Move we amend the WP by incorporating the changes specified in N0739
          = 95-0139.
 
      No one moved this.
 
      34) Motion (to make numerous small changes to iterators and algorithms)
          by Dodgson/Dawes:
 
          Move we amend the WP by incorporating the changes specified in N0740
          = 95-0140.
 
      Motion passed X3J16: lots yes, 0 no.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      ==== presented by Clamage ====
 
      35) Motion (to make numerous changes to iostreams) by Ball/Myers:
 
          Move we amend WP clause 27 [lib.input.output] by incorporating the
          changes specified in N0749 = 95-0149.
 
      Motion passed X3J16: lots yes, 0 no.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      ==== presented by Plum ====
 
      36) Motion (to allow implementation-dependent extension support) by
          Santo/Plum:
 
          Move we add the following to WP clause 1.7 [intro.compliance]
          (subject to further wordsmithing by the project editor):
 
              A conforming implementation may have extensions (including
              additional library functions), provided they do not alter the
              behavior of any well-formed program.
 
      Winder asked if these words are intended to change the well-formedness
      of a program.  Plum said they are not.  Schwarz and Hartinger said they
      had a little problem with the word "extension" and wished to see it
      defined.
 
      Motion passed X3J16: lots yes, 3 no.
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      ==== presented by Harbison ====
 
      37) Motion (X3J16 only: to recommend that WG21 adopt editorial
          procedures) by Harbison/Myers:
 
          Move we recommend that WG21 adopt the procedures governing the
          editing and review of the Working Paper described in motion 38.
 
      Miller asked what's the difference between this and N0750 = 95-0150.
      Harbison said he changed some, but not all, occurrences of "WG21+X3J16"
      to "WG21".  He said he made a few other minor changes, but none sub-
      stantive.
 
      Motion passed X3J16: lots yes, 0 no, 1 abstain.
 
      38) Motion (WG21 only: to adopt editorial procedures) by Bruck/Lajoie:
 
          Move we adopt the following procedures governing the editing and
          review of the Working Paper:
 
              The WG21 Project Editor shall use his best efforts to incorpo-
              rate all Working Group resolutions into the Working Paper after
              each meeting. If he is unable to do so, he shall notify the
              Convener.
 
              WG21 authorizes the Project Editor to make any other changes in
              the Working Paper that the Project Editor believes are needed,
              with the goal of producing a Working Paper that better reflects
              the consensus of the Working Group or otherwise promotes the de-
              velopment of the standard. The Project Editor shall record all
              substantive changes not covered by resolutions.  This record of
              changes may take the form of editorial boxes in the Working
              Paper provided to WG21 and X3J16 or it may be a separate docu-
              ment, or both.
 
              If the Project Editor delegates any part of the editing task to
              assistants, he shall ensure that those assistants understand and
              agree to follow these procedures, and he shall include the as-
              sistants' records of substantive changes as part of his final
              record.
 
              At each meeting, WG21 and X3J16 shall be given the opportunity
              to ratify the changes as part of the approval process for the
              Working Paper.
 
              The following additional procedures shall apply when the Project
              Editor is producing a Working Paper to be submitted to become
              CD, DIS or IS, when WG21 and X3J16 do not have the opportunity
              to review the final draft:
 
              Designated representatives of WG21 and X3J16 shall review the
              Project Editor's Working Paper and the record of substantive
              changes.  The Project Editor shall take into consideration all
              reviewer comments that are submitted in a timely fashion, and
              shall incorporate some or all of them into the Working Paper at
              his sole discretion.  The Project Editor shall notify reviewers
              of the disposition of their comments, and shall add to the
              record of changes any substantive comments suggested by the
              reviewers.
 
              The WG21 Convener shall approve the submission of the CD, DIS,
              or IS as long as the procedures herein described have been fol-
              lowed and there appears to be a consensus on the content of the
              Working Paper by the Project Editor and the reviewers.  Other-
              wise, the Convener shall notify the WG21 delegations present at
              the previous meeting and ask for recommendations for a resolu-
              tion and disposition of the Working Paper.
 
      Motion passed WG21: 6 yes, 0 no, 0 abstain.
 
      ==== other ====
 
      39) Motion (to thank Dmitry Lenkov):
 
          Move we thank Dmitry Lenkov for all his efforts on behalf of C++
          standardization.
 
      Applause.
 
11.2  Review of action items
 
      Clamage opened the committee of the whole.
 
      Clamage summarized the results of Thursday's steering committee meet-
      ing.  He said they discussed how to handle ANSI (US) public comments.
      They agreed that:
      --  Lajoie will keep a master list of all the ANSI public comments.
      --  She will pass this list on to each of the subgroup chairs.  They
          will categorize each comment handled within their group as:
          rejected, accepted, editorial, or still open.
      --  We will send an acknowledgment to the sender of each comment.  This
          acknowledgment will contain a general description of how we pro-
          cessed the comments, and explain that the specific resolutions to
          their comments will be sent when all the comments are resolved.
          Plum and Clamage volunteered to write the letter and insure that
          copies are sent.  Lajoie will provide the addresses.
      --  We will formally respond to comments when we have resolved them all,
          including ANSI and national body comments.
 
      The people to whom Lajoie will send public comments are...
 
      Core:
          Adamczyk - clauses 4, 5 (not 5.5), 8, 11, and 13
          Gibbons - clauses 7.3, 5.5, 14, and 15
          Lajoie - memory model, object model, ODR, clauses 3, 6, 7 (not 7.3)
              9, 10, and 12
 
      Library:
          Becker - clause 25
          Dodgson - clause 24
          Colvin - clause 17
          Henricson - clause 18
          Holly or then Myers - clause 26
          Myers - clauses 20 and 22
          Podmolik - clause 23
          Wilhelm - clause 21
          Vilot - clauses 19, 27 and appendix D
 
      Other:
          Koch - Appendix B
          Plum - clauses 1, 2, and 16, and Appendix C
          Scian - Appendix A
 
      Koenig asked that these people be prepared to help with editing between
      meetings.  If they cannot do it themselves, please find others to help.
 
      The WG chairs submitted the following action items.
 
      Core WG (Lajoie):
 
      --  Anderson will write a paper on linkage of names in unnamed name-
          spaces.
      --  Hartinger and Lajoie will write a paper on extern "C" and the C++
          type system (to make this implementation-defined).
      --  Lajoie will write a paper describing how operator new can be used by
          an implementation (for allocating static and automatic variables,
          temporaries, RTTI data structures, exception handling data struc-
          tures).
      --  Miller will write a paper to resolve core issue 470 (describing when
          a pointer allocated with user-defined placement new can be deleted).
      --  Gibbons will write a paper on pointer-to-member and scalar types.
      --  Nelson will write a paper to resolve core issue 417 (describing when
          pointer arithmetic is allowed for a pointer to an abstract class).
      --  Nelson will write a paper to clarify the terminology used to de-
          scribe objects (to resolve core issues 421 and 460).
      --  Glassborough will write a paper to restrict the type of the function
          main.
      --  Schwarz will write a paper to identify where the WP should require
          complete types.
 
      Other:
 
      --  Plum and Clamage will write the public comment acknowledgment letter
          template.
 
12    Plans for the future
 
12.1  Schedule Change
 
      Done Thursday afternoon.
 
12.2  Next meeting
 
      Sawatani briefly explained some of the arrangements for the November
      meeting in Tokyo.  She said tee shirts and jeans would be acceptable
      attire.
 
12.3  Mailings
 
      X3 is still doing them.  The post-meeting deadline is two weeks from the
      end of the meeting.  The pre-meeting deadline is Sept. 26.
 
12.4  Following meetings
 
      Harbison listed the meeting dates for the upcoming meetings:
      --  November 5-10, 1995 in Tokyo, Japan hosted by ITSC
      --  March 10-15, 1996 in Santa Cruz, USA hosted by Borland
      --  July 7-12, 1996 in Stockholm, Sweden, hosted by Ericsson
      --  November 10-15, 1996, Kona, Hawaii, USA hosted by Plum Hall
 
13    National delegation caucuses
 
14    Adjournment
 
      The committees thanked Sun Microsystems for hosting the meeting.
      Applause.
 
      Clamage closed the committee of the whole.
 
      Motion by Koch/Lajoie:
 
          Move we adjourn.
 
      Motion passed WG21+X3J16: lots yes, 0 no.
 
The committee adjourned at 11:17 on Friday.
 
 
Appendix A - Attendance
 
Name                  Affiliation               Stat   M   Tu  W   Th  F
 
Hesse, Joseph         ACTC                      P      V   V   V   V   V
Motamedrasa, Saeed    AMD                       P      V   V   V   V   V
Podmolik, Larry       Andersen Consulting       P      V   V   V   V   V
Wilhelm, Richard      Andersen Consulting       A      A   A   A   A   A
Winder, Wayne         Asymetrix                 P      V   V   V   V   V
Koenig, Andrew        AT&T Bell Labs            A      V   V   V   V   V
Stroustrup, Bjarne    AT&T Bell Labs            A      A   A   A   A   A
Becker, Pete          Borland                   P      V       V   V
Swan, Randall         C-Team                    P          V   V   V
McKenna, Christine    Cadence Design Systems    P      V       V   V   V
Immel, Mark           Centerline Software       A      V   V   V   V   V
Charney, Reg          Charney & Day             P      V   V   V   V   V
Holly, Mike           Cray Research             P      V   V   V   V
Stump, Mike           Cygnus Support            P      V   V   V   V   V
Schwarz, Jerry        Declarative Systems       P      V   V   V   V   V
Kimmel, Cathy         Digital Equipment         O      A   A   A   A   A
Meyers, Randy         Digital Equipment         P      V   V   V   V   V
Bruck, Dag            Dynasim AB                P      V   V   V   V   V
Andrews, Graham       Edinburgh Port. Compilers P      V   V   V   V   V
Adamczyk, Steve       Edison Design Group       P      V   V   V   V   V
Anderson, Mike        Edison Design Group       A      A   A   A   A   A
Spicer, John          Edison Design Group       A      A   A   A   A   A
Henricson, Mats       Ellemtel                  P      V   V   V   V   V
Jonsson, Fredrik      Ellemtel                  A      A   A   A   A
Berman, Charles       Fidelity Investments      A                  A   A
Coha, Joseph          Hewlett-Packard           A      V   V   V   V   V
Lenkov, Dmitry        Hewlett-Packard           P      A   A   A       A
Rosler, Larry         Hewlett-Packard           O      A   A   A
Lajoie, Josee         IBM                       P      V   V   V   V   V
Colvin, Greg          IMR                       P      V   V   V   V   V
Nelson, Clark         Intel                     P      V   V   V   V   V
Andersson, Per        Ipso Object Software      P      V   V   V   V   V
Stuessel, Marc        IST GmBH                  P      V   V   V   V   V
Santo, Shigeru        Japan                     A      V   V   V   V   V
Sawatani, Yuriko      Japan                     A      A   A   A   A   A
Munch, Max            Lex Hack & Associates     O      A   A   A   A   A
Dum, Stephen          Mentor Graphics           P      V   V   V   V   V
Pennello, Tom         MetaWare                  P      V   V           V
Burggraaf, S. David   Microsoft                 A      A   A   A   A   A
Schreiber, Ben        Microsoft                 P      V   V   V   V   V
Weight, Chris         Microsoft                 S      A   A   A   A
Eager, Michael        Microtec Research         A      V   V   V   V   V
Saini, Atul           Modena Software           P      V   V   V
Bruns, John           Nations Banc-CRT          P      V   V   V   V   V
Howe, Barbara         Novell                    P      V   V   V   V   V
Vilot, Mike           Object Craft              P      V   V   V   V
Benito, John          Perennial                 P      V   V   V   V   V
Plum, Tom             Plum Hall                 P      V   V   V   V   V
Corfield, Sean        Programming Research      P      V   V   V   V   V
Hinke, John           QDS                       P      A   A   A   A
Wilcox, Thomas R.     Rational Software         P      V   V   V   V   V
Keffer, Tom           Rogue Wave Software       O          A   A
Myers, Nathan         Rogue Wave Software       P      V   V   V   V   V
Smithey, Randy        Rogue Wave Software       A      A   A   A   A   A
Saks, Dan             Saks & Associates         P      V   V   V   V   V
Koch, Gavin           SAS Institute             P      V   V   V   V   V
Tooke, Simon          SCO Canada                P      V   V   V   V   V
Wengler, Christian    SET Software Consulting   P      A   A   A   A   A
Kiefer, Konrad        Siemens AG                P      A   A   A   A   A
Hartinger, Roland     Siemens Nixdorf           P      V   V   V   V   V
Langer, Angelika      Siemens Nixdorf           O      A   A   A   A
Steinmuller, Uwe      Siemens Nixdorf           A      A   A   A   A   A
Unruh, Erwin          Siemens Nixdorf           O      A   A   A   A   A
Wilkinson, John       Silicon Graphics          P      V   V   V   V   V
Miller, William M.    Software Emancipation     P      V   V   V   V   V
Ball, Mike            Sun Microsystems          A      V   V   V   V   V
Clamage, Steve        Sun Microsystems          A      A   A   A   A   A
Gafter, Neal          Sun Microsystems          A      A   A   A   A
Landauer, Doug        Sun Microsystems          P      A   A   A   A   A
Micco, John           Symantec                  P      V   V           V
Feng, Yinsun          Taligent                  A      A   A   A   A
Gibbons, Bill         Taligent                  P      V   V   V   V   V
Harbison, Sam         Tartan                    P      V   V   V   V   V
Sullivan, Larry       TechVisions               P      V   V   V   V   V
Corcoran, Marian      UC Santa Cruz             O      A   A   A   A   A
Glassborow, Francis   UK                        A      A   A   A   A   A
Jones, Derek          UK                        A      A   A   A
Rumsby, Steve         UK                        A      A   A   A   A   A
Dodgson, Dave         Unisys                    P      V   V   V   V   V
Hauer-Lowe, Keith     Unisys                    A      A   A   A   A   A
Newhall, David        Unitech Research          O      A
Scian, Anthony        Watcom                    P      V   V   V   V   V
Welch, Jim            Watcom                    A      A   A   A   A   A
Plauger, P. J.        WG14                      O      A   A   A   A
Crowfoot, Norm        Xerox                     P      V   V   V   V   V
Dawes, Beman                                    P      V   V   V   V   V
Eckel, Bruce                                    P      V   V   V   V
Holaday, Thomas                                 P      V   V   V   V   V
 
Total Attendance                                       84  83  83  79  70
Total Votes                                            54  53  53  52  49