N0597 = 94-0210 Document Number: WG21/N0597 X3J16/94-0210 Date: 8 December 1994 Project: Programming Language C++ Reply to: Dan Saks dsaks@wittenberg.edu X3J16 Meeting No. 16 WG21 Meeting No. 11 7 - 11 November 1994 Sheraton Plaza Hotel North Gulph Rd. and First Ave. King of Prussia, PA 19406 USA 1 Opening activities Lenkov convened the meeting as chair at 09:00 (EST) on Monday, 7 November 1994. Lajoie was the vice-chair, and Saks was the secretary. Unisys (represented by Dodgson) hosted the meeting. 1.1 Opening comments 1.2 Introductions Saks circulated an attendance list each day, which is attached as Appendix A of these minutes. Lajoie circulated a copy of the membership list (SD-2 = 94-0001R4) 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 joint membership is denoted WG21+X3J16 in these minutes.) Lenkov explained the voting rules: -- In straw votes, all WG21 technical experts may vote, even those who haven't attended previous WG21 meetings. An X3J16 attendee may vote only if he/she is the voting representative of a member organization that has met the X3's meeting attendance requirements (discussed below). (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. 1 N0597 = 94-0210 -- In X3J16 formal votes, only one representative from each X3J16 member organization may vote, and only then if the organization meets the attendance requirements. Several members of the committee disagreed in their interpretation of X3's meeting attendance requirements to earn and maintain voting rights. Plum suggested that the X3 officers resolve the dispute over lunch. 1.4 Distribution of documents not distributed before the meeting 1.5 Approval of the minutes from the previous meeting Saks submitted the minutes from the previous meeting (N0539 = 94-0152) for approval. He explained that the meeting dates listed in section 12.3 (page 38) are wrong, and he will include the correct dates in the next (these) minutes. Motion by Saks/Lajoie: Move we approve N0539 = 94-0152 (with errors noted above) as the minutes of the previous meeting. Motion passed X3J16: lots yes, 0 no, 1 abstain. Motion passed WG21: 7 yes, 0 no, 0 abstain. 1.6 Agenda review and approval Lenkov submitted the proposed agenda (N0573 = 94-0186) for approval with these additions: 1.8.1 Call for volunteers to serve as IR 1.11 Meeting information from the host Lenkov also scheduled technical sessions for Tuesday and Wednesday evenings. Motion by Lenkov/Lajoie: Move we accept N0573 = 94-0186 as amended as the agenda for this meeting. Motion passed X3J16: lots yes, 0 no, 1 abstain. Motion passed WG21: 7 yes, 0 no, 0 abstain. 1.7 Report on the WG21 Sunday meeting Harbison summarized the highlights of Sunday's WG21 meeting. He ex- plained Plum's concerns that the current project and meeting schedule did not allow time for the US to conduct a two-month public review. He said that he met with Koenig, Lenkov, and Plum later Sunday evening and worked out a schedule which they believe will give the US time to conduct the public review within the current meeting schedule. 2 N0597 = 94-0210 1.8 Liaison reports ==== WG14 (ISO C) ==== Plum reported that WG14 met in Tokyo, Japan in July, 1994. WG14 has undertaken its five-year revision of C. They will meet in December to further discuss the goals of the revision. Plum explained that Amendment 1 is now official. It uses the same digraphs that the C++ draft currently uses. Shopiro asked if the C committee is planning to adopt any C++ features. Plum replied that there's a spectrum of possibilities. On one end, it's very likely that C will adopt //-style comments. Beyond that, there's controversy. Stroustrup cautioned that we (WG21) should not try to tell WG14 what to do, but he'd prefer that WG14 not make too many changes in the C lan- guage. He warned that "once said you start making changes, it's hard to stop." On the other hand, if they make changes, he hoped they'd keep compatibility with C++ as a priority. ==== SC22 Plenary ==== Harbison reported on the SC22 Plenary in the Hague, Netherlands in September, 1994 (N0559 = 94-0172). He said SC22 approved WG21's project schedule for the next year. Harbison explained that, contrary to his report (N0559 = 94-0172), Borkowski will not be the SC22 secretary. The new secretary will probably be Bill Reinhuls (currently with X3 OMC). 1.8.1 Call for volunteers to serve as IR Lenkov explained that Plum's current term as X3J16's international representative (IR) will expire soon. X3 has called for volunteers to serve as IR. Lenkov said Plum will probably offer to serve another term, but others may apply. 1.9 New business None. 1.10 Drafting Committee Lenkov explained the role of the drafting committee: to prepare a written statement for all formal motions so that all 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) is always on the drafting commit- 3 N0597 = 94-0210 tee. For this meeting, Corfield, Hartinger, and Unruh will also par- ticipate. Also, 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. 1.11 Meeting information from the host Thank you. The committee recessed to WGs at 10:15 on Monday and reconvened at 08:30 on Wednesday. 2-3 WG sessions 4 Project Editor's report Lenkov opened the committee of the whole. Koenig reported that the latest Working Paper (WP) (N0545 = 94-0158) incorporates all of the motions from the Kitchener meeting (July '94), except motion 11 (clarifying the phases of construction); the Core WG decided the motion was ill-considered, and withdrew it. He apologized for accidentally printing part of the index in constant-width font when it should be in regular font. He also explained that the complete renumbering of the library clauses fooled his software into putting changes bars on the entire library. Therefore, he simply omitted the change bars in the library clauses. Koenig said the normative text in the WP is the same as what he sent to SC22 for CD registration. (Change bars and editorial boxes are not normative). He thanked Adamczyk, Gafter, Gibbons, Holly, Lajoie, Nelson, Plum, Schwarz, Stroustrup, and Wilcox for help with editing and reviewing the WP, with special thanks to Vilot for overhauling the library. Koenig said the draft that goes out from the March 1995 meeting will be the one that goes out for ANSI public review. He will need to finish editing the draft more quickly than in the past to avoid delaying the review. Plum explained that on Sunday, WG21 discussed doing the editing on the weekend immediately after the March meeting. WG21 decided it wasn't feasible to finish that quickly, and agreed to do it in 5 weeks. He suggested that we should still try to do as much editing as possible over that weekend. Plum said our host for the March meeting (Murphy from Motorola) has offered to provide facilities to use that weekend, and we should decide if we want to take him up on it. The committee briefly discussed making the draft available electronic- ally, such as via anonymous ftp. Many liked the idea. 4 N0597 = 94-0210 Lenkov asked if anyone objected to accepting N0545 = 94-0158 as the current WP. No one did. 5 General Session I 5.1 Core Language WG Lajoie presented a three-part proposal on the addressability of objects (based on the discussion from N0569 = 94-0182). She said the WG con- sidered parts 1 and 3 editorial. 1. An object of basic or POD type becomes addressable as soon as its memory is allocated. struct C { int i; int j; }; extern C c; int *pi = &c.i; C c; 2. For non-POD objects, bases, bases' members and direct members can be addressed at the start of construction. Pictorially, C() : base_init member_init { ... } ^1 ^2 they can be addressed at 1. (This is solution A from N0569 = 94-0182, except it's not recursive through the members.) 3. Referring to a class object's base classes or members before construction starts results in undefined behavior. For example, struct A { int i; }; struct B : A { }; extern B b; int *pi = &b.i; // undefined behavior Gibbons objected to part 2 of the proposal. He wanted to move the addressability guarantees for virtual bases from 1 to 2 to avoid repeat- ing some base class initialization in each derived class. Gibbons explained a facility for converting among virtual bases that his proposal allows, but the proposal stated above does not. Pennello said Gibbons' proposal allows a style of programming that relies on the order of mem-initializers; the Core WG did not want to sanction that style. Ball said the WG's proposal might force a translator to split construc- tors in two, imposing a burden on both compilers and linkers. 5 N0597 = 94-0210 Schwarz asked if "addressability" means "the ability to do casts". Lajoie said yes, static_casts, but not dynamic_casts. Straw Vote: Who favors this proposal as presented (treating parts 1 and 3 as editorial, and part 2 with addressability guarantees at ^1)? 15 yes, 20 no, 11 abstain. Straw Vote: Who favors this proposal changed so that the addressability guarantees are at ^2 (still treating parts 1 and 3 as editorial)? WG21+X3J16: 36 yes, 6 no, 6 abstain. WG21 only: 2 yes, 2 no, 3 abstain. [Note: The WG reconsidered part 2 of this proposal in a later WG ses- sion. Pennello presented a revised proposal. See agenda item 8.2.] Lajoie presented a three-part proposal to specify the polymorphic behavior of objects during construction (based on discussions in N0570 = 94-0183). 1. Polymorphic behaviors (virtual function calls, typeid, dynamic_cast) always behave consistently. All are undefined, or all are defined to indicate the same object type. 2. Polymorphic behaviors behave during construction as if the object's type were the constructor's class. 3. Polymorphic behavior is established after base class initialization and before member initialization. Pictorially, it's established at ^2: C() : base_init member_init { ^1 ^2 (See motion 4 for precise wording and examples.) Straw vote: Who favors this proposal? lots yes, 3 no, 4 abstain. Lajoie presented a pair of proposals on const objects (N0571 = 94-0184): 1. Define a "const object" as an object created with a const-qualified type. (See motion 5.) 2. Specify that typeid ignores the top-level cv-qualifiers of its operand's type. (See motion 6.) Straw Vote: Who favors this proposal? lots yes, 0 no, 1 abstain. Lajoie presented a multi-part proposal regarding dynamically-allocated const objects (item 2.2 from N0571 = 94-0184). 1. A new-expression can create a const object. For example, 6 N0597 = 94-0210 const int *p1 = new const int(1); // ok const int *p2 = new (const int)(2); // ok typedef const int CI; const int *p3 = new CI(3); // ok 2. When specified in the type of an object allocated by a new-expres- sion, const means the program may not change the object. For example, const int *p = new const int(1); const int *q = new int(2); *(const_cast(p)) = 0; // undefined *(const_cast(q)) = 0; // ok 3. An initializer is required for an object created by a new-expression of const type if the type has no user-defined default constructor. For example, const int *p = new const int; // ill-formed const int *q = new const int (0); // ok const int *r = new int; // ok 4. Const objects created with new-expressions can be deleted. For example, const int *p = new const int (5); int *q = const_cast(p); // must cast away const delete q; // ok Straw Vote: Who favors parts 1 through 3 of this proposal? lots yes, 0 no, 0 abstain. Straw Vote: Who favors part 4? lots yes, 2 no, 4 abstain. Several members expressed concern about the requirement (in part 4) to cast away const before deleting. Koenig pointed out that const_cast can't cast T * to T *. Therefore, you can't write a template that works for both T * and const T *. Stroustrup said this is probably a bug in const_cast; he expected Koenig to exercise editorial discretion and change the semantics for const_cast to allow conversion from T to T. Lajoie suggested adding another part to the proposal: 5. The operand of delete may have a pointer to const type (thus eliminating the need for a const_cast before the delete). Straw Vote: Who favors this addition to the proposal? lots yes, 4 no, 7 abstain. Lajoie explained that the previous proposals allow the phases of construction to be described by the following steps (N0572 = 94-0185): 7 N0597 = 94-0210 1. Memory is acquired (size, alignment, address) 2. Base classes and members become addressable 3. Base class are initialized 4. Polymorphic behavior acquired 5. Member initialization 6. Constructor body executed 7. Memory becomes write-protected These steps occur in reverse order during destruction. No one dis- sented. Koch asked if these steps are recursive. Lajoie explained that steps 2 through 6 are recursive for all subobjects. ==== Core (Plum) ==== Adamczyk suggested changing the treatment of const in overload resolu- tion (N0530 = 94-0143R1). He explained that the WP currently says const is an "early" tie-breaker. He asked the committee to consider changing it to a "late" tie-breaker. Adamczyk said there's no consensus among implementations, and that this decision (either way) will have little effect on existing programs. He gave this example (from N0530 = 94-0143R1) to illustrate the difference between const as an "early" and a "late" tie-breaker: struct A { }; void f(const A *, short); void f( A *, int); main() { A a; f(&a, (short)1); // early -> ambiguous // late -> call f(const A *, short); } Corfield noted that N0530 = 94-0143R1 erroneously states that using const as a "late" tie-breaker calls the second function, f(A *, int). Stroustrup said there are no conclusive arguments to do it either way. He urged the committee to just vote and be done with it. Pennello opposed the switch to "late" tie-breaker because it complicates the argument matching rules. Adamczyk summarized the arguments on both sides of the issue (from N0530 = 94-0143R1). Straw Vote: Who favors changing const to a "late" tie-breaker? 18 yes, 20 no, 9 abstain. Adamczyk said he won't bring this up for a formal vote. Adamczyk presented a proposal to forbid binding a reference-to-const- volatile to an rvalue (N0321 = 94-0114). For example: 8 N0597 = 94-0210 class X { ... }; volatile X f(); // still ok const volatile &r = f(); // error, can't bind The proposal does not ban volatile rvalues; they are still valid, but they are useless because you can't copy them. Adamczyk explained the reasoning for the ban (from N0321 = 94-0114): Binding a reference to an rvalue binds to a copy of the rvalue, but that copy can't be volatile. Ball suggested just banning volatile rvalues. Plum said C++ already allows seemingly useless constructs, as long as they are harmless. Such constructs may ultimately prove useful. For example, an implementation might actually want to declare sig_atomic_t as a volatile type, such as: typedef volatile int sig_atomic_t; But then programmers might write: sig_atomic_t f(int); where the volatility of the return type is incidental. Plum argued that we shouldn't ban volatile rvalues because that also effectively bans potentially useful declarations like the typedef above. Straw Vote: Who favors this proposal? WG21+X3J16: 26 yes, 10 no, 12 abstain. WG21 only: 6 yes, 0 no, 0 abstain. Adamczyk proposed to remove inconsistencies in the behavior of access checking (N0547 = 94-0160). He cited the "universal law" of access checking, which is mentioned in the commentary of the ARM but not stated anywhere in the WP. That law is that "access checking does not affect meaning of a program, only its validity." In other words, if a program compiles and links, changing all the access in the program to public won't change the program's behavior. As explained in N0547 = 94-0160, the current WP violates this "law" by ignoring inaccessible base classes during overload resolution. Adamczyk proposed that implicit conversions to a base class should be considered whether or not that base is inaccessible, and if the best match employs a conversion to an inaccessible base, the program is ill-formed. Adamczyk explained that a corollary of the universal law is that access checking should be done at compile-time, not at run-time. Two features of C++ currently violate this corollary: dynamic_cast and throw. He suggested that C++ could adopt any of the following policies: 1. Check access at run-time. That is, provide access information at run-time and use it to determine semantics. 2. Catch access violations at run-time. That is, provide access infor- mation at run-time and use it to detect access violations. 3. Ignore access violations at run-time. 9 N0597 = 94-0210 4. Ban questionable cases at compile-time. Adamczyk said the Core WG recommended (3). Stroustrup opposed this proposal, saying that some C++ users feel very strongly that using a dynamic_cast to convert to a private base class breaks encapsulation. This issue has been debated extensively in the Extensions WG and in the C++ community. It's a highly emotional issue. Stroustrup added that "people will break into a rash over this". Plum didn't see why dynamic_cast would be any less secure with this than a regular cast is now. Adamczyk replied that new casts are supposed to be safer. Adamczyk also picked a "nit" over the wording in the WP. The WP says "a base class is accessible if its public members are accessible." But what if the class has no public members? Or what if it has one, but the derived class adjusts the access to that member? Schwarz observed that friendship affects accessibility of members in this context. Adamczyk agreed that the WP's definition of accessibility doesn't cover friend- ship either. Straw Vote: Who favors this proposal (to apply the "universal law" and its corollary)? 9 yes, 21 no, 16 abstain. Action Item: The Extensions WG will reconsider dynamic_cast in light of the "universal law" of access checking. Adamczyk asked if anyone objected to treating the "nit" as editorial. No one did. Stroustrup reminded Koenig (the editor) to consider Schwarz's concern when fixing the nit. Adamczyk presented a proposal to extend access privileges to entire function declarations and static member definitions. (See motion 9 for precise wording and examples.) Straw Vote: Who favors this proposal? lots yes, 0 no, 5 abstain. Adamczyk presented a proposal to disallow storage class specifiers in friend function declarations. For example, class A { friend static void f(); // ill-formed friend extern void g(); // ill-formed }; Lenkov asked if anyone objected to treating this as an editorial change. No one did. Adamczyk presented a proposal to simplify the description of the seman- tics for access declarations. In particular, he proposed that an access declaration should have the same meaning as the equivalent "using". For example, 10 N0597 = 94-0210 class A { public: int x; }; class B : private A { public: A::x; // means the same as "using A::x;" }; Adamczyk further suggested that we not lift any restrictions on access declarations; the equivalence only applies for access declarations that are valid under the current rules. Stroustrup suggested lifting the restrictions so that access declara- tions have exactly the same semantics as "using". Straw Vote: Who favors this proposal (including lifting the restrictions so that access declarations have exactly the same semantics as "using")? lots yes, 0 no, 4 abstain. (See motion 10 for the final form of the proposal.) Plum presented an example using default arguments in typedefs: typedef void F(int, int = 3); F *fp = &f; (*fp)(2); typedef void F(int = 5, int); F *fp2 = &f; (*fp2)(); He explained that, although some compilers may compile this example, they generate code that behaves badly. He cited specific compilers that produce erroneous results or core dumps. He proposed that we: 1. Disallow default arguments on typedefs, pointers to functions, and references to functions. 2. Approve all other recommendations from N0552 = 94-0165 (not having to do with default arguments). Gibbons said the list for (1) includes pointers to member functions. (See motion 11.) Straw Vote: Who favors this proposal? lots yes, 5 no, 7 abstain. Plum presented Unruh's proposal (N0561 = 94-0174) to amend the criteria for comparing user-defined conversions during overload resolution. The proposal restores words that were lost as part of a recent change to the WP. (See motion 12.) Plum presented the example from the paper. Koenig and Ball said that 11 N0597 = 94-0210 anything that makes atrocities like this (the example) ambiguous is a good thing. Schwarz presented another example: struct A { operator int *(); operator const int *() const; }; void f(const int *); A a; f(a); and claimed that the proposal makes the call ambiguous. Adamczyk said that chapter 13 deals with this issue in two places. This proposal changes one of those places without changing the other (which governs Schwarz's example). Straw Vote: Who favors this proposal? lots yes, 2 no, 5 abstain. 5.2 Library WG Vilot presented a proposal to change the library header names (N0565 = 94-0178). He said the WG preferred alternative 2 under section 2.1, which adds more headers. The proposal also reaffirms the WG's prefer- ence for header names with the ".h" suffix. (See motion 13.) Straw Vote: Who favors this proposal? lots yes, 0 no, 11 abstain. Vilot said the WG considered four proposals on language support, all having to do with exceptions (N0536 = 94-0149, N0553 = 94-0166, N0566 = 94-0179, N0579 = 94-0192). The WG preferred N0553 = 94-0166 (with some changes), which specifies a class of exception objects that don't throw exceptions. (See motion 14.) Straw Vote: Who favors this proposal? lots yes, 0 no, 4 abstain. [Note: The WG discussed this proposal again in a later session, and reopened the discussion before the committee. See item 8.1.] Vilot presented a proposal for small changes to the library (N0542 = 94-0155). (See motion 15.) Straw Vote: Who favors this proposal? lots yes, 0 no, 11 abstain. Vilot presented a proposal to change the Allocator parameter of various library class templates from a template parameter to a type parameter (N0548R1 = 94-0161R1). (See motion 16.) Corfield said he was uncomfortable with member templates (which this proposal depends upon). He asked if this proposal could be specified using partial specialization (which we think has no problems) instead of 12 N0597 = 94-0210 member templates (which we think might have problems). Ball said the Extensions WG discussed member templates, and observed that implementing them with the generality of the current specification might not be possible. Straw Vote: Who favors this proposal? 28 yes, 2 no, 17 abstain. Vilot said the WG considered four proposals concerning strings (N0532 = 94-0145, N0549 = 94-0162, N0557R2 = 94-0170R2, N0564 = 94-0177). The WG preferred N0557R2 = 94-0170R2 (with changes), which reconciles the string class interface with the rest of the STL components. (See motion 17.) Wilhelm explained that the proposal doesn't make a string behave like an STL "sequence", but the WG will consider this change for the next meeting. Straw Vote: Who favors this proposal? WG21+X3J16: lots yes, 0 no, 15 abstain. WG21 only: 2 yes, 1 no, 4 abstain. Vilot presented a proposal to clean up locales in assorted ways. (See motion 18.) Straw Vote: Who favors this proposal? WG21+X3J16: lots yes, 0 no, 11 abstain. WG21 only: 5 yes, 0 no, 2 abstain. Vilot presented a proposal to clean up other aspects of locales, includ- ing unnesting some member facets, and removing member templates from class locale. Straw Vote: Who favors this proposal? WG21+X3J16: lots yes, 0 no, 11 abstain. WG21: 5 yes, 0 no, 2 abstain. Vilot recommended removing the bit_string class from the library, because it duplicates vector. (See motion 19.) Straw Vote: Who favors this proposal? lots yes, 0 no, 2 abstain. Vilot also recommended removing class ptr_dyn_array and class template dyn_array from the library. (See motion 19, also.) Straw Vote: Who favors this proposal? lots yes, 0 no, 1 abstain. Vilot recommended more minor changes in the library, mostly to make the names and interfaces more consistent (N0558 = 94-0171). (See motion 20.) Straw Vote: Who favors this proposal? lots yes, 0 no, 6 abstain. Vilot presented a proposal to move the streambuf_iterators to a differ- ent header. (See motion 21.) He said this would be editorial except 13 N0597 = 94-0210 that it changes the name of the header that an application must include. Straw Vote: Who favors this proposal? lots yes, 0 no, 6 abstain. Vilot presented a proposal to combine the various complex number classes into a single template (N0551 = 94-0165). The WG recommended changes to the proposal to fix ambiguities by specializing templates. (See motion 22.) Vilot explained that the proposal defines conversions among complex, complex and complex in a way that tries to mimic the standard conversions among float, double, and long double. Straw Vote: Who favors this proposal? lots yes, 0 no, 4 abstain. Vilot presented a proposal to overhaul iostreams (N0556 = 94-0169). In particular, the proposal renames "baggage" as "traits", and repackages traits. It also add a new class ios_base that captures all the parts of a stream that do not depend on the type of character in the stream. (See motion 23.) Plum pointed out an error on page 5 of N0556 = 94-0169: class basic_ios : public ios_state { --------- should be class basic_ios : public ios_base { -------- Vilot explained that some Library WG members are concerned about the overhead of initializing iostreams using Schwarz's "nifty counter" tech- nique (for specifying initialization order across translation units). Some suggested making stream objects "special" in that an implementation must initialize them first. Others don't want this because it may pre- vent users from using C++ libraries from independent vendors. Vilot said the issue is still open. Straw Vote: Who favors this proposal? lots yes, 0 no, 9 abstain. Vilot presented a proposal to add a numeric limits traits template to the library (N0516 = 94-0129). (See motion 24.) Straw Vote: Who favors this proposal? lots yes, 0 no, 7 abstain. Vilot proposed adding "smart" pointer classes to the library (N0555 = 94-0168 with changes, mostly in the interface). The auto_ptr class is to satisfy the UK delegation's request (presented at the July 1994 meeting in Kitchener) for exception-safe pointers. (See motion 25.) The counted_ptr class provides added support for what the WG perceived to be a common (but not compelling) need. (See motion 26.) Straw Vote: Who favors these proposals? lots yes, 0 no, 13 abstain. 14 N0597 = 94-0210 5.3 Extensions WG Stroustrup presented a proposal to specify a template compilation model (based on part 3 of N0582 = 94-0195). It had two main aspects: 1. Templates have external linkage by default. 2. Template definitions behave like inline member function definitions with respect to the ODR (One Definition Rule).. (This implies that it's okay for a non-inline definition to appear in a header that's included in more than one compilation; it behaves like an inline definition.) (See motion 27 for the precise wording.) The intent is to allow programs to: -- place an entire template definition in a header (a .h file) -- place the template class and inline member definitions in a header (e.g., x.h) and place the corresponding non-inline definitions in a source file (e.g., x.c) as well as other combinations. Miller asked if this means that an implementation must cope with tem- plates in separate .h and .c files with no further assistance from the programmer. Stroustrup said yes. Plum asked what this says to program- mers about how to lay out templates among the files that make up a program. Stroustrup said this allows programmers to treat template classes and functions as they would non-templates. Straw Vote: Who favors this proposal? lots yes, 2 no, 7 abstain. Stroustrup presented a proposal to clarify the semantics of friend declarations in class templates (based on discussion in N0587 = 94-0200 item 2.23, and N0582 = 94-0195 item 4). The WG decided there's no really good solution to the problem, but implementations and usage appear to be converging toward a common approach. In essence, the proposal states that a friend declaration in a class template definition does not inject a name into an enclosing scope. Rather, a template specialization acts like a non-template class with regard to injecting names of friends into enclosing scopes. (See motion 28.) Unruh objected to name injection, and urged the committee to reject this proposal. Straw Vote: Who favors this proposal? WG21+X3J16: 25 yes, 5 no, 18 abstain. WG21 only: 3 yes, 2 no, 2 abstain. Stroustrup presented a proposal to distinguish type names from non-type names within templates. A statement of the problem and the proposed solution appear as option 2 in editorial box 61 of the WP (N0545 = 94-0158). Specifically, the proposal introduces the keyword "typename" which behaves, in a sense, like the keywords "class" or "struct". (See motion 29.) 15 N0597 = 94-0210 Straw Vote: Who favors this proposal? lots yes, 1 no, 10 abstain. Stroustrup proposed resolutions to a pair of minor template issues from N0587 = 94-0200. (See motion 30.) Straw Vote: Who favors this proposal? lots yes, 0 no, 5 abstain. Stroustrup described the WG's wrangling over what to do about exception specifications. They had several choices: -- abolish them -- leave them alone -- make them "checkable" (that is, to make some compile-time checking possible) -- require full and exclusive static checking To allow making them "checkable", they had to: -- fix unexpected() so that it can't "lie" -- allow exception specifications for pointers to functions and extern "C" functions, and guarantee that they don't "lie" Currently, unexpected() might "lie" by throwing an exception that's not in the exception specification of the function that caused the call to unexpected(). Stroustrup said every exception system that has worked so far has a lie. The question is: How do we make the lie livable? The WG proposed to fix unexpected() so that: -- it can't violate exception specifications -- a programmer can prevent all exception propagation by using throw() -- a programmer can channel "bad" exceptions into a predefined excep- tion tentatively called [XUNEXPECTED] (based on work done at HP) -- an implementation can perform optimizations by static checking (based on work done at Sun) (See motion 32.) Stroustrup said it appears that some programmers use exception specifi- cations, and like them. However, you can't use them with STL-like tem- plates and qsort-like functions. Exception specifications are more appropriate as subsystem barriers. Furthermore, using them on low-level functions allows the compiler to optimize dynamic checking. For exam- ple, most of the standard C library could be specified to throw nothing. Straw Vote: Who favors this proposal? lots yes, 0 no, 10 abstain. Stroustrup explained the WG's proposal to specify whether or not the stack is unwound when no handler is found for a thrown exception (based on discussion in N0420 = 94-0033). The proposal is that it should be implementation-defined. (See motion 33.) The primary reason for not unwinding is that unwinding destroys informa- tion that debuggers need. On the other hand, some architectures unwind as they search for a handler, and doing otherwise would be unacceptably expensive. Furthermore, a C++ program can always force unwinding by an 16 N0597 = 94-0210 appropriate try-block in main(). Straw Vote: Who favors this proposal? lots yes, 2 no, 1 abstain. Stroustrup presented a proposal to clarify that thrown objects are not cv-qualified. That is, the constness of the top-level type of a thrown object is ignored. (See motion 34.) Straw Vote: Who favors this proposal? lots yes, 0 no, 2 abstain. Stroustrup discussed the proposal to add non-converting constructors to C++ (based on N0477 = 94-0090). The proposal is to solve problems of the sort illustrated by the following example. If class vector has a constructor vector(int) then you can write: vector v(10); // ok But if you declare: void f(const vector &); then you can also write: f(10); // no! which you do not want. You want the compiler to require that you write: f(vector(10)); // ok The WG considered many alternatives for the syntax: -- use an extra argument: vector(int, xtra); vector v(10, xx); -- use a "noconvert" template: vector(noconvert); vector(10); -- use a keyword: constructor vector(int); vector(10); Stroustrup said the WG preferred the last alternative (from N0477 = 94-0090). He also showed some other alternatives: noconvert vector(int); vector(int) noconvert; vector(int) = 0; 17 N0597 = 94-0210 vector(int, void); constructor vector(int); Stroustrup said the WG spent a lot of time discussing the syntax, and asked people not to reopen the discussion. This proposal (as originally in N0477 = 94-0090) also adds the keyword "destructor" (just for symmetry). Vilot and Plum voiced concern over adding another keyword. Straw Vote: Who favors this proposal? WG21+X3J16: lots yes, 8 no, 9 abstain. WG21 only: 3 yes, 1 no, 3 abstain. 5.4 Environments WG None. 5.5 C Compatibility WG None. 5.6 Formal Syntax WG To placate Gibbons, Pennello proposed to alter the C++ grammar to allow p->*pm = 0; He explained that the grammar in the WP currently requires parentheses around the pm-expression: (p->*pm) = 0; He presented a revised grammar (from N0535 = 94-0148) that eliminates the need for the parentheses. He explained that the current grammar is a legacy from C. Years ago, the C committee sought to disallow assign- ments such as a * b = c. Pennello argued at the time that such assign- ments could be caught by a constraint violation. But the committee elected to disallow them syntactically. Pennello also explained that this grammar allows: a * b = c // passes grammar; fails constraint a + b = c // passes grammar; fails constraint a->*b = c // ok but doesn't allow: a ? b : c = 3 // fails grammar Straw Vote: Who favors this proposal? lots yes, 1 no, 8 abstain. 18 N0597 = 94-0210 5.7 Core Language WG (revisited) Adamczyk requested a straw vote in support of the "universal law" of access checking. That is, he wanted to know if the committee agreed that, aside from the dynamically-checked cases (throw and dynamic_cast), access control should affect validity only, and not visibility or con- sideration of base classes in implicit conversions. Straw Vote: Who agrees that C++ should follow this "universal law"? lots yes, 1 no, 17 abstain. Lenkov closed the committee of the whole. The joint committee recessed at 17:10 and reconvened Thursday at 14:45. 6 WG Sessions 7 Distribute formal motions 8 General Session II 8.1 Library WG Vilot presented one more proposal that, with the committee's consent, he'd introduce as a formal motion. Specifically, he proposed to revise istrstream, ostrstream, strstreambuf so that they would no longer be templates. (See motion 36.) No one objected. Vilot pointed out that some of the motions (under 11.1) refer to papers just distributed at the meeting. Motion 14 (to provide an exception- safe exception class in the standard library) refers to N0588 = 94-0121, which proposes an exception class that begins: class exception { public: exception(const string &) throw(); // can't throw anything Vilot said that this implies that the string class must use a reference- counted implementation. He gave this example: try { f(); } catch (exception e) { ------------- string s = e.what(); -------- } f() { throw exception("help"); ------ } 19 N0597 = 94-0210 If exceptions are to be exception-safe, then the underlined parts must not throw exceptions. This implies they can't risk allocation failures by trying to allocate memory. Since each underlined expression, above, might copy an exception, and hence a string, string copying must not attempt to allocate memory. Therefore, Vilot argued, the string must use reference-counting. Schwarz noted that the example catches an exception by value, which he thought is ill-advised. Steinmuller said that the requirement is not to use reference counting, but to avoid memory allocation while copying, or avoid copying altogether. Nelson pointed out that this wouldn't be an issue if the WG had left the exception constructor with a const char * parameter, instead of changing it to a string parameter. Ball echoed Nelson's point, adding that even a reference-counted implementation will run out of memory eventually. Colvin (the author of the proposal) said he was sympathetic to Nelson and Ball. All he (Colvin) really wanted was exception-safe exception objects; he didn't care if the parameter type in the constructor was one type or the other. Schwarz said he had argued in the WG for the string parameter only. He said he thinks null-terminated strings should be deprecated. They cause "old-fashioned" mistakes. Colvin summarized reasons that others had given for preferring strings: 1. If you throw a const char *, it must point to a static array; how- ever, static data poses a problem in multi-threaded environments. 2. The string returned by what() might have embedded nulls, so return- ing it as a const char * might lose information. Nelson pointed out that, if string::string(const char *) is not allowed to throw an allocation exception, and therefore not allowed to allocate memory, then returning a string whose value is built in an auto array of char becomes inconvenient. Ball said static data is not a problem in multi-threaded environments; there is such a thing as thread local storage. Vilot said he would withdraw this as a formal motion (motion 14). Vilot explained that he split the proposal for "smart" pointers (N0589 = 94-0202) into two motions: 25 and 26. He presented this example illus- trating the use of the auto_ptr template: g() { T *p = new T; auto_ptr ap(p); f(); // ... exception ap.release(); // 1 delete p; // 2 } 20 N0597 = 94-0210 Vilot said type T must not be an array type. To use auto_ptr with an array, use vector. He also explained that if you omit //1 and //2, ap works the same (its destructor does the work). However, if you write //1, you must write //2. Stroustrup asked what happens when you copy auto_ptrs. Vilot replied that if you copy one auto_ptr to another, the first auto_ptr must re- lease its pointer. Otherwise, both auto_ptrs will try to delete the same storage. Nelson explained that ap.release() returns ap, so you can write ap.release(); delete ap; as delete ap.release(); Gibbons objected strenuously that auto_ptrs do not transfer ownership of their pointers when you copy them. Vilot replied that that's why the WG also introduced counted_ptr. Schwarz said it's not correct to say an auto_ptr doesn't transfer ownership when copied because auto_ptrs have no copy operations. Gibbons explained that he thought the auto_ptrs should have copy operations that transfer ownership. Stroustrup agreed with Gibbons, but said the proposal is otherwise good. Vilot asked if he should withdraw the proposal. No reply at all. Vilot explained the counted_ptr template with this example: class string { counted_ptr _rep; public: .... }; string::string(char *s) : _rep(s) { } string::operator=(char *s) { _rep = s; } string::~string() { if (_rep.unique()) delete _rep.get(); } Koch expressed surprise that a counted_ptr implicitly increments and decrements its counter, but you have to delete its pointer explicitly. Holaday expressed concern that this string implementation requires two dereferences to access the value. Colvin replied that this is not the best way to implement a string class; better implementations exist. 8.2 Core WG Pennello presented the WG's revised proposal on the addressability of subobjects during construction. Using this diagram: 21 N0597 = 94-0210 C() : bases members { ... ^1 ^2 ^3 he explained that, on Wednesday, some people wanted shallow address- ability of member subobjects at ^1, and deep addressability of bases at ^2. (Shallow addressability means a program can address the object it- self, but not the object's subobjects. Deep addressability means it can address all the object's subobjects, plus all the subobjects' subob- jects, and so on.) Others wanted deep addressability of members at ^3. Today (Thursday) in the WG, some wanted: -- members are (shallow) addressable at ^1 -- direct bases are (shallow) addressable at ^1 -- the whole lattice is addressable at ^1 -- a subobject is addressable only after its construction has started Pennello presented the WG's reformulation of the proposal (parts 1 and 2 of N0595 = 94-0208). (See motions 2 and 3.) He explained that the new proposal has the following properties: -- It holds for all implementations. -- It has order dependencies, but they are based on the order of construction already required elsewhere in the WP. -- Users can write code that depends on construction order if they want to. -- Teachers can make simple recommendations such as "bases are address- able at ^2" and "members are addressable at ^3". Unruh asked if this is for PODs or for class objects. Pennello said its for class objects; PODs are constrained by C already. Straw Vote: Who favors this proposal? X3J16 only: lots yes, 0 no, 0 abstain. WG21 only: 7 yes, 0 no, 0 abstain. Lajoie summarized the Core WG's current thinking on object lifetime (from N0572 = 94-0185) and asked the committee for feedback. She got some. 8.3 Extensions WG Knuttila explained that N0594 = 94-0207 (which details the proposed changes to unexpected()) was distributed with an error. The first sentence on page 2 should be "In 15.5.2, paragraph 2, keep the first sentence and replace the rest of the paragraph with:". Stroustrup briefly explained some open issues on partial specialization of templates (N0582 = 94-0195). He said the following issues are "almost dead": -- templatizing "something else" -- virtual classes -- a lexical hack for >> in list> -- anything else 22 N0597 = 94-0210 Stroustrup explained that, earlier in the day, the WG discussed the pro- posal to add non-converting constructors to C++ (N0477 = 94-0090). He said that, within the first 15 minutes of discussion, he got 5 different suggestions for the syntax. So they tried to agree on some rules of thumb for the syntax: -- "Say what you mean!" -- It should be easy to retrofit existing code -- It shouldn't change destructors -- It should apply to constructors and operator functions (that is, all conversions) The WG could not agree on the desirability of new keywords, but -- a prefix keyword (if any) should appear in declarations only -- a suffix keyword (if any) must match in the declaration and the definition Myers suggested that the syntax should be easy to present to beginners, because it should be the default. Stroustrup said it never will be the default, and it's not clear even if it should be. Stroustrup presented the committee with these choices: 1. constructor{T}(int); // doesn't apply to operators destructor{T}(); // changes destructor 2. constructor T(int); // doesn't apply to operators 3. explicit T(int); explicit operator T(); 4. T(int, void); // an abomination // doesn't apply to operators 5. T(int) = 0; // doesn't apply to operators Stroustrup said all allow both converting and non-converting constructors in the same class. Straw Vote: prefer can live with over my dead body 1. 5 32 14 2. 1 31 10 3. 37 lots 1 4. 0 8 lots 5. 2 15 lots Stroustrup asked the committee to consider a prefix vs. a postfix keyword: 1. explicit T(int); explicit operator T(); 23 N0597 = 94-0210 2. T(int) explicit; operator T() explicit; A brief discussion ensued over whether derived classes inherit the explicit attribute. Winder said he understood the explicit constructors because they are more-or-less described in N0477 = 94-0090. But he did not understand the semantics of an explicit operator function (they are not in the paper). He preferred to vote only on the constructors, and wait to see a paper about explicit operator functions. Unruh agreed. Straw Vote: prefer can live with over my dead body 1. 31 lots 2 2. 13 lots 10 Straw Vote: Who favors amending the original proposal as follows: use the keyword "explicit" instead of "constructor"; delete the state- ment(s) that constructor names are optional; delete all mention of the keyword "destructor"? lots yes, 2 no, 0 abstain. (See motion 31 for the final form of the proposal.) 8.4 Environments WG 8.5 C Compatibility WG 8.6 Formal Syntax WG 9 WG sessions (if any time left) Lenkov closed the committee of the whole. The committee recessed at 17:55 on Thursday and reconvened at 08:35 on Friday. 10 Review of the meeting The WG21+X3J16 reviewed the wording of the formal motions in preparation for voting. Henderson pointed out an asymmetry between the first two bulleted items under part 2 of N0595 = 94-0208: the first bullet refers to "the con- struction of X and all of its direct or indirect bases that directly or indirectly derive from B", but the second bullet refers only to "the destruction of X" with no mention of bases. Lenkov suggested that the committee treat this as an editorial issue. No one disagreed. Some members raised concerns about the proposal to combine the various complex number types into a template (motion 22). The current proposal declared real() and imag() as members, whereas the earlier version of 24 N0597 = 94-0210 the proposal declared them as nonmembers. Some participants wanted the functions as nonmembers for compatibility with the complex types pro- posed by X3J11.1 (the numerical C extensions group). Clamage (author of the current proposal) said he hadn't realized that the functions were already declared as globals for compatibility with (possibly future) C. Lenkov asked if anyone objected to granting the editor discretion to change 'real()' and 'imag()' back to global functions. No one did. Plum noted another potential C compatibility problem: the typedefs for float_complex, double_complex, etc. were removed. Clamage said he removed them not realizing there was a C compatibility issue. The committee agreed to add an editorial box to the WP summarizing the issue. 11.1 Formal motions Lenkov counted 43 X3J16 members and 7 WG21 delegations. 1) Motion (to accept the WP) by Bruck/Tooke: Move we accept N0545 = 94-0158 as the current WP. Motion passed X3J16: lots yes, 0 no. Motion passed WG21: 7 yes, 0 no, 0 abstain. 2) Motion (to disallow addressing subobjects before construction starts) by Wilkinson/Lajoie: Move we amend the WP as suggested in the first proposal of N0595 = 94-0208. Motion passed X3J16: lots yes, 0 no. Motion passed WG21: 7 yes, 0 no, 0 abstain. 3) Motion (to describe the addressability of subobjects during con- struction) by Wilkinson/Gibbons: Move we amend the WP as suggested in the second proposal of N0595 = 94-0208. Motion passed X3J16: lots yes, 0 no. Motion passed WG21: 7 yes, 0 no, 0 abstain. 4) Motion (to describe acquisition of polymorphic behavior during construction) by Lajoie/Gibbons: Move we amend the WP as suggested in the third proposal of N0595 = 94-0208. Motion passed X3J16: lots yes, 0 no. Motion passed WG21: 6 yes, 1 no, 0 abstain. 25 N0597 = 94-0210 5) Motion (to define object types) by Winder/Anderson: Move we add to section 3 [basic], after sentence 2 of paragraph 10, the definition of object type: The type with which an object is created, including any cv-qual- ifiers, is the object's type. An object with a const-qualified object type is called a const object. For example: const int i = 0; // i's object type is "const int". Motion passed X3J16: lots yes, 1 no. Motion passed WG21: 6 yes, 0 no, 1 abstain. 6) Motion (to indicate that typeid ignores the top cv-qualifiers of its operand type) by Wilkinson/Lajoie: Move we add to section 5.2.7 [expr.typeid] the following sentence and example: Typeid ignores the top-level cv-qualifiers of its operand's type. For example, class D { ... }; D d1; const D d2; typeid(d1) == typeid(d2) typeid(D) == typeid(const D) typeid(D) == typeid(d2) Motion passed X3J16: lots yes, 0 no. Motion passed WG21: 7 yes, 0 no, 0 abstain. 7) Motion (to permit new-expressions to create cv-qualified objects) by Winder/Anderson: Move we: -- replace clause 5.3.4 [expr.new] paragraph 5 with: A type-specifier-seq shall not contain class declarations or enumeration declarations. -- remove clause 5.3.5 [expr.delete] paragraph 5, which states: A C++ program that applies delete to a pointer to constant is ill-formed. Motion passed X3J16: lots yes, 4 no. Motion passed WG21: 5 yes, 2 no, 0 abstain. 26 N0597 = 94-0210 8) Motion (to disallow binding const volatile references to rvalues) by Adamczyk/Rumsby: Move we amend the sentence after the example in clause 8.5.3 [dcl.init.ref] paragraph 6 from: Otherwise, the reference must be to a const type (i.e., cv1 must include const qualification); if not, the program is ill-formed. to: Otherwise, the reference must be to a non-volatile const type (i.e., cv1 must be const); if not, the program is ill-formed. For example, class X { ... }; volatile X f(); // ok const volatile &r = f(); // error Motion passed X3J16: lots yes, 3 no. Motion passed WG21: 7 yes, 0 no, 0 abstain. 9) Motion (to extend access privileges to entire function declarations and static member definitions) by Adamczyk/Lajoie: Move that we add text to clause 11 [class.access] to make it clear that special member and friend access privileges apply to the entire declaration of a function, or the definition of a static data member, including references to names that precede the name of the function or static data member in the declaration. For example, class A { typedef int I; I f(); friend I g(I); static I x; }; A::I A::f() { return 0; } // ok A::I g(A::I); // ok A::I g(A::I p) { return 0; } // ok A::I A::x = 0; // ok Motion passed X3J16: lots yes, 0 no. Motion passed WG21: 7 yes, 0 no, 0 abstain. 10) Motion (to make access declarations equivalent to using declara- tions) by Adamczyk/Caves: Move we amend the WP to convey that an access declaration (11.3) (_class.access.dcl_) has the same semantics as the equivalent using declaration. Motion passed X3J16: lots yes, 0 no. Motion passed WG21: 7 yes, 0 no, 0 abstain. 27 N0597 = 94-0210 11) Motion (to clarify the behavior of default arguments) by Lajoie/ Nelson: Move we: -- add to the end of 8.3.6 [dcl.fct.default] paragraph 1: A default argument expression shall be specified only in the parameter-declaration-clause of a function declaration or in a template-parameter (14.6) (_temp.param_). If it is specified in a parameter-declaration-clause, it shall not occur within a declarator or abstract-declarator of a parameter-declaration. (Footnote: This means that default arguments cannot appear, for example, in declarations of pointers to functions, references to functions, or typedefs.) -- adopt recommendations 1, 2, 3, 4, 5, 6, 7, and 11 of N0552 = 94-0165. Miller/Saks moved to table the motion. Miller said that when presenting this motion, Plum claimed that certain compilers didn't support a particular example using default arguments in a function type defined in a typedef. He (Miller) posted a small test suite to comp.lang.c++ and asked for help to see which compilers really support default arguments in various contexts. It turns out that many compilers support them. He advised tabling the motion and offered to write another analysis of the proposal for next meeting. Gibbons noted that just because compilers support a feature doesn't mean users use it. Plum explained that Miller showed these results to the Core WG on Thurs- day. The WG considered what was involved in getting these examples to "work". Plum explained that default arguments are not type information, but compilers must carry them around as such. The WG decided it wasn't worth the effort to try to get them right. Miller responded that people outside the committee will see this as a gratuitous removal. Koenig said he was initially sympathetic to Miller's position, but there are real implementation difficulties. He suggested we shouldn't pass up this opportunity to clarify the WP. We should ban default arguments (in the contexts specified in the proposal) without prejudice, and leave the burden of proof on Miller. If Miller can work out all the problems, we can always vote them back in. Ball said Sun's survey found that no two compilers handled default argu- ments the same way, and some were internally inconsistent. 28 N0597 = 94-0210 Saks/Miller withdrew the motion to table. Motion 11 passed X3J16: lots yes, 2 no. Motion 11 passed WG21: 5 yes, 1 no, 1 abstain. 12) Motion (to respecify when one user-defined conversion sequence is better than another) by Lajoie/Wilcox: Move we adopt the proposal in N0561 = 94-0174, namely, to change the text of the last sentence of clause 13.2.3.2 [over.ics.rank] para- graph 3 to the following (additions enclosed in []): User-defined conversion sequence U1 is a better conversion sequence than another user-defined conversion sequence U2 [if they contain the same user-defined conversion operator or constructor and] if the second standard conversion sequence of U1 is better than the second standard conversion sequence of U2. Motion passed X3J16: lots yes, 1 no. Motion passed WG21: 6 yes, 0 no, 1 abstain. 13) Motion (to modify header names) by Rumsby/Dodgson: Move we amend the library clauses (17 through 27) as described in section 2.1, Alternative 2 of N0565 = 94-0178. Motion passed X3J16: lots yes, 0 no. Motion passed WG21: 7 yes, 0 no, 0 abstain. 14) Motion (to make exception-safe exceptions): Move we amend clause 19.1.1 [lib.exception] as described on page 1 of N0553 = 94-0166 amended as described in N0588 = 94-0202. [Note: Withdrawn. See agenda item 8.1.] 15) Motion (to make small library changes) by Dodgson/Schwarz: Move we amend clauses 20, 21, 23, and 27, as described in Sections 1-3 of N0542 = 94-0155, with the following changes: -- Select alternative 3.1.A // STL style operator[] signatures -- Select alternative 3.2.A // operator[] not checked, at() checked -- Select alternative 3.3.A // names: at -- Add basic_string to the list of classes (vector, deque) affected by Sections 3.2 and 3.3 of the proposal. 29 N0597 = 94-0210 -- Amend the clauses 21.1.1.2 [lib.basic.string], 21.1.1.3.10 [lib.string::get.at], and 21.1.1.3.11 [lib.string::put.at] by changing the signatures of get_at() and put_at() to: charT at(size_t pos) const; // was get_at charT& at(size_t pos); // was put_at Motion passed X3J16: lots yes, 0 no. Motion passed WG21: 7 yes, 0 no, 0 abstain. 16) Motion (to make Allocators a non-template template parameter) by Myers/Rumsby: Move we amend clauses 20 [lib.utilities], 21 [lib.strings] and 23 [lib.containers] as described in N0548R1 = 94-0161R1, with the following changes: -- Eliminate the following signatures from the class allocator interface: template size_type init_page_size(); types::pointer allocate(size_type); template types::pointer allocate(); template types::pointer allocate(types::const_pointer hint); leaving only a single allocate member: template types::pointer allocate(size_type, types::const_pointer hint); where the size_type argument indicates the number of instances of type T. [Ed.: if N0592 = 94-0205 is adopted, change the declaration to: template typename types::pointer allocate(size_type, typename types::const_pointer hint); ] -- [Ed.: also change the Allocator template parameter on basic_string, vector, list, and deque to a non-template template parameter] Corfield said he was not happy about approving something that depends on a feature that might not be implementable. 30 N0597 = 94-0210 Action Item: Myers said he'd devise a version of this proposal using partial specialization in place of member class templates. Motion passed X3J16: lots yes, 4 no. Motion passed WG21: 6 yes, 0 no, 1 abstain. 17) Motion (to modify basic_string) by Swan/McKenna: Move we amend clause 21 [lib.strings] as described in N0557 = 94-0170, with the following changes: -- Remove section 3.2.2 of the proposal. -- [Ed.: sections 3.5.1-3.5.4 recommend changes to the fourth version of the functions listed.] -- Change section 3.6.1 of the proposal to be: "remove the third compare() signature." Motion to amend by Corfield/Steinmuller: Keep the length() member and add a size() member. Motion to amend passed X3J16: lots yes, 2 no. Motion to amend passed WG21: 3 yes, 1 no, 3 abstain. Motion 17 passed X3J16: lots yes, 0 no. Motion 17 passed WG21: 4 yes, 2 no, 1 abstain. 18) Motion (to modify locales) by Myers/Swan: Move we amend clause 22 [lib.localization] as described in N0575 = 94-0188 and as described in N0581R1 = 94-0194R1. Motion passed X3J16: lots yes, 0 no. Motion passed WG21: 6 yes, 0 no, 1 abstain. 19) Motion (to remove bit_string, ptr_dyn_array, and dyn_array) by Steinmuller/Dodgson: Move we amend clauses 17 [lib.library] and 23 [lib.containers] as described in N0574 = 94-0187, N0531 = 94-0144, and N0541 = 94-0154. Bruck asked the committee to recognize the effort that went into these classes. Hands clapped. Motion passed X3J16: lots yes, 0 no. Motion passed WG21: 7 yes, 0 no, 0 abstain. 20) Motion (to make minor library modifications) by Myers/McKenna: 31 N0597 = 94-0210 Move we amend clauses 23 [lib.containers] and 25 [lib.algorithms] as described in N0558 = 94-0171, with the following changes: In section 3 of the proposal, change the algorithm name from "find" to "find_first_of". In sections 5 and 6 of the proposal, add the members assign() and resize() to all three of vector, list, and deque. Motion passed X3J16: lots yes, 1 no. Motion passed WG21: 5 yes, 0 no, 2 abstain. 21) Motion (to relocate streambuf_iterators to ) by Myers/ Rumsby: Move we amend clauses 24 [lib.iterators] and 27 [lib.input.output] as described in N0567 = 94-0180. Motion passed X3J16: lots yes, 0 no. Motion passed WG21: 7 yes, 0 no, 0 abstain. 22) Motion (to templatize complex numbers) by Holly/Gibbons: Move we amend clauses 17 [lib.library] and 26 [lib.numerics] as described in N0551 = 94-0164, with the changes described in N0591 = 94-0204. Motion passed X3J16: lots yes, 0 no. Motion passed WG21: 6 yes, 0 no, 1 abstain. 23) Motion (to modify iostreams) by Schwarz/Myers: Move we amend clause 27 [lib.input.output] as described in < N0556 = 94-0169, with the changes described in > N0590 = 94-0203. Motion to amend by Schwarz/Gibbons: Remove the part of the motion enclosed in < >. Motion to amend passed X3J16: lots yes, 0 no. Motion to amend passed WG21: 7 yes, 0 no, 0 abstain. Motion 23 passed X3J16: lots yes, 0 no. Motion 23 passed WG21: 6 yes, 0 no, 1 abstain. 24) Motion (to add numeric limits) by Myers/Gibbons: Move we amend clause 18 [lib.language.support] as described in N0516R2 = 94-0129R2. Motion passed X3J16: lots yes, 0 no. Motion passed WG21: 7 yes, 0 no, 0 abstain. 32 N0597 = 94-0210 25) Motion (to add an auto_ptr template class) by Henricson/Colvin: Move we amend clause 20 [lib.utilities] as described in page 1 of N0555 = 94-0168, with the changes described on page 1 of N0589 = 94-0202. Vilot noted that this proposal is in response to concerns that some WG21 delegations expressed at the last meeting. He asked if this is an acceptable solution. Rumsby (UK) said yes. Henderson (Australia) said he's not sure it satisfies all requirements; Australia favors this proposal, but might want more in the future, such as another class. Gibbons said the class ought to have copy and assignment operators, and he will work with Colvin to add them. Stroustrup agreed there ought to be copy operations. Motion passed X3J16: lots yes, 3 no. Motion passed WG21: 7 yes, 0 no, 0 abstain. 26) Motion (to add a counted_ptr template class) by Corfield/Henricson: Move we amend clause 20 [lib.utilities] as described in page 2 of N0555 = 94-0168, with the changes described on page 2 of N0589 = 94-0202. Clamage said this is a little utility class that has little utility. He suggested that if a user wants one, he/she should write one. It need not be in the standard. Stroustrup said this worries him; being neat and useful is not sufficient reason to add something to the standard. Henderson said this is on Australia's issues list. Steinmuller said he can think of applications that need a counted_ptr, but not this counted_ptr. It's not an appropriate part of the library. Motion failed X3J16: 20 yes, 22 no. Motion passed WG21: 4 yes, 2 no, 1 abstain. Lenkov opened the committee of the whole. The committee discussed what to do about the split vote. Lajoie, acting as WG21 convener, said WG21 would be happy to see the motion withdrawn. Henderson said he objected. Saks asked X3J16 members who voted "no" to switch their votes to "yes". Plum suggested that since Australia wasn't sure this satisfied their criteria, we should wait until we see a proposal that does. Corfield/Henricson agreed to withdraw the motion. Lenkov closed the committee of the whole. 33 N0597 = 94-0210 Corfield/Henricson withdrew the motion. 27) Motion (to provide a template compilation model) by Corfield/Lajoie: Move we replace the entire clause 14.3.1 [temp.avail] with the following: 14.3.1 Template Linkage [temp.linkage] A function template has external linkage. A static member of a class template has external linkage. If a function template appears in more than one compilation unit, it must have the same definition. BeginBox This will have to be rephrased to take into account the complete ODR definition. EndBox Anderson said he was surprised that the rules for context merging were supposed to be inferred from the concept of "external linkage". Stroustrup acknowledged the concern. Motion passed X3J16: lots yes, 5 no. Motion passed WG21: 7 yes, 0 no, 0 abstain. 28) Motion (to clarify name injection) by Caves/Ball: Move we replace clause 14.2.4 [temp.inject] paragraph 1 sentence 2 with: When a template is specialized, the names declared within it are declared as if the specialization had been explicitly declared at its point of instantiation. If a template is first specialized as the result of a use within a block or a class, names declared within the template shall be used only after the template use that caused the specialization. For example: // no Y here template class X { friend class Y; }; Y* py1; // error: no Y in scope 34 N0597 = 94-0210 // point of instantiation for X void g() { X* pc; // does not cause instantiation Y* py2; // error: no Y in scope X c; // causes instantiation of X // names from X can be used // from here on Y* py3; // ok } Y* py4; // ok Motion passed X3J16: lots yes, 1 no. Motion passed WG21: 3 yes, 2 no, 2 abstain. 29) Motion (to introduce the keyword typename as a name resolution mechanism within templates) by Spicer/Gibbons: Move we amend the WP as described in N0592 = 94-0205. Motion passed X3J16: lots yes, 2 no. Motion passed WG21: 6 yes, 0 no, 1 abstain. 30) Motion (to resolve template issues) by Spicer/Corfield: Move we amend the WP according to these items from N0587 = 94-0200: 3.20 - the ambiguity between a type-id and an expression is resolved as a type-id. 6.22, alternative 3 - dependent name lookup is performed in the context of both namespaces, and overload resolution is applied to the resultant set of found names. Motion passed X3J16: lots yes, 0 no. Motion passed WG21: 5 yes, 0 no, 2 abstain. 31) Motion (to provide non-converting one-argument constructors) by Corfield/Swan: Move we amend the WP as described in N0593R1 = 94-0206R1. Motion passed X3J16: lots yes, 2 no. Motion passed WG21: 7 yes, 0 no, 0 abstain. 32) Motion (to enable some static checking of exception specifications) by Spicer/Ball: Move we amend the WP as described in N0594 = 94-0207. Motion passed X3J16: lots yes, 2 no. Motion passed WG21: 6 yes, 0 no, 1 abstain. 35 N0597 = 94-0210 33) Motion (to clarify stack unwinding when no handler is found) by Spicer/Corfield: Move we replace clause 15.3 [except.handle] paragraphs 6 and 7 with: If no match is found amongst the handlers for a try-block, the search for a matching handler continues in a dynamically surrounding try-block. An exception is considered handled upon entry to a handler. The stack will have been unwound at that point. If no matching handler is found in a program, the function terminate() (15.5.1) is called. Whether or not the stack is unwound before the call to terminate() is implementation-defined. Motion passed X3J16: lots yes, 0 no. Motion passed WG21: 6 yes, 0 no, 1 abstain. 34) Motion (to clarify that thrown objects are not cv-qualified) by Spicer/Gibbons: Move we amend clause 15.1 [except.throw] paragraph 4 sentence 1 as follows (additions enclosed in []): A throw-expression initializes a temporary object of the static type of the operand of throw[, ignoring the top level cv-qualifiers of the operand's type,] and uses that temporary to initialize the appropriately-typed variable named in the handler. Motion passed X3J16: lots yes, 0 no. Motion passed WG21: 7 yes, 0 no, 0 abstain. 35) Motion (to allow writing (p->*pm) = 0 as p->*pm = 0) by Pennello/Gibbons: Move we amend the grammar for assignment-expression in clause 5.17 [expr.ass] paragraph 1 and Annex A as specified in N0535 = 94-0148. Motion passed X3J16: lots yes, 0 no. Motion passed WG21: 7 yes, 0 no, 0 abstain. 36) Motion (to remove stdiostreams and template strstreams) by Schwarz/ Myers: Move we amend clause 27 [lib.input.output] as described on pages 2, 3, and 4 of N0550 = 94-0163 (the sections labelled "stdiostream" and "strstreams"), and place the revised description of strstreams in an Annex to the WP containing deprecated features. Motion passed X3J16: lots yes, 0 no. Motion passed WG21: 7 yes, 0 no, 0 abstain. 36 N0597 = 94-0210 10.2 Review of action items Lenkov opened the committee of the whole. The WG chairs submitted the following action items. Core WG (Lajoie): -- Anderson will coordinate the resolution of issues in clause 12.8 [class.copy]. -- Lajoie will continue to resolve issues on the memory model and the object model. -- Lajoie will assist Koenig in resolving the editorial issues regard- ing name lookup that are of concern to some national delegations. -- Lajoie will assist Koenig in incorporating the Core WG resolutions into the WP. Core WG (Plum): -- Plum will post the X3J11.1 Technical Report to the C compatibility reflector. -- Plum will write new C compatibility entries for copying of volatile PODs and for class declarations that erroneously have a storage class specifier. -- Plum will ask Gibbons to produce answers for Core issues 13, 14 and 177, and to forward the answers to Koenig. -- Adamczyk will write a paper on the ranking of promotion vs. conver- sion, and the impact of that ranking on enum arguments. -- Adamczyk will assist Koenig in describing the way that old-style cast selects the appropriate new-style cast. -- Adamczyk will assist Koenig in describing the ways that static_cast depends upon the initialization process. [Note that initialization may find a conversion sequence that is inaccessible, or ambiguous, or generates an invalid template function.] -- Wilcox will assist Koenig with the details of describing that "assignment is not inherited", and write a paper if any important substantive issues are found. -- Nelson will investigate the issue of pointer-to-function for the C library functions, including arguments for qsort, and write a paper if any important substantive issues are found. Extensions WG: -- Spicer, assisted by Stroustrup and Unruh, will write a revised paper on Template Issues and Suggested Resolutions. -- Gibbons, assisted by Corfield, will write a paper on placement new. -- Ball, assisted by Corfield, Unruh and Caves, will investigate the implementation of member templates. -- Stroustrup, assisted by Spicer, will write a paper on partial specialization and template overloading. -- Stroustrup, assisted by Ball, Spicer, Unruh and Gibbons, will write a paper on run-time access checking. 37 N0597 = 94-0210 -- Lenkov, assisted by Ball and Holaday, will write a paper on exception issues. -- Gibbons, assisted by Holaday, will write a paper on pointer-to- member issues. Library WG: -- The following members will collect and organize comments on the Library clauses: McKenna: 17. Introduction Henricson: 18. Language support Vilot: 19. Diagnostics Myers: 20. General utilities Wilhelm: 21. Strings Schwarz: 22. Localization Podmolik: 23. Containers Vilot: 24. Iterators Vilot: 25. Algorithms Ward: 26. Numerics Myers: 27. Input/output -- Myers will propose a version of runtime allocator based on partial specialization in place of member class templates. -- Myers will propose changes to library classes resulting from the addition of non-converting constructors. 10.3 Previously postponed issues None. 11 Plans for the future 11.1 Next meeting See 11.3. Lenkov said he assumed the WG21 would start at 18:00. No one objected. 11.2 Mailings Lenkov explained that we have no sponsor(s) for the North American mail- ing after this meeting. We have a volunteer for the pre-Austin mailing (Bellcore), but no others. If we don't get a volunteer, X3 will handle the North American mailings, but they will also bill us for the ser- vice. Furthermore, only paid-up principal members will get mailings from X3 (observers won't). Lajoie said the deadline for the pre-Austin meeting mailing is sometime between Jan. 28 and Jan. 31, 1995. Hartinger said Siemens-Nixdorf will continue with mailings to members outside North America. 38 N0597 = 94-0210 Nelson (Intel), Gibbons (Taligent), Lenkov (Hewlett-Packard), Myers (Rogue Wave), Caves (Microsoft), and Lajoie (IBM) offered to twist their respective company's arms to sponsor the next mailing. 11.3 Following meetings Harbison listed the meeting dates for the upcoming meetings: -- March 5-10, 1995 in Austin, TX hosted by Motorola -- July 9-14, 1995 in San Francisco, CA, hosted by Sun Microsystems -- November 5-10, 1995 in Tokyo, Japan -- March 10-15, 1996 somewhere in California, 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 Lenkov asked how many are planning to go to Tokyo. About 23 voting members of X3J16; 6 WG21 delegations; 40 members all together. Committee briefly discussed distributing documents electronically. Plum spoke with Kate McMillan at X3, who agreed to try distributing documents electronically. Plum suggested we try putting the draft in a public ftp archive to lengthen the apparent time for the public review. Rumsby offered to provide an ftp site. He also offered to make the WP avail- able on WWW. Plum reiterated that he still favors a weekend editing session after the next meeting. 12 National delegation caucuses 13 Adjournment The committees thanked Dodgson and Unisys for hosting the meeting. Applause. Lenkov closed the committee of the whole. Motion by Lajoie/Spicer: Move we adjourn. Motion passed WG21+X3J16: lots yes, 0 no. The committee adjourned at 11:20 on Friday. Appendix A - Attendance Name Affiliation Stat M Tu W Th F Motamedrasa, Saeed AMD P 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 A A A A A A 39 N0597 = 94-0210 Lettington, Drew AT&T P V V V V V Stroustrup, Bjarne AT&T Bell Labs A A A A A A Swan, Randall C-Team P V V V V V McKenna, Christine Cadence Design Systems P V V V V V Burleson, Kate Centerline Software A V V V V V Charney, Reg Charney & Day P V V V V V Druker, Samuel Cognex P V V V V V Comeau, Greg Comeau Computing P V V V Holly, Mike Cray Research P V V V V V Price, Phil CSC P V V V V V Stump, Mike Cygnus Support P V V V V V Schwarz, Jerry Declarative Systems P V V V V V Meyers, Randy Digital Equipment P V V V V Bruck, Dag Dynasim AB 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 O A A A A A Henricson, Mats Ellemtel P V V V V V Gimpel, James Gimpel Software O A A A Lenkov, Dmitry Hewlett-Packard P V V V V V Smith, Dave Hughes P V V V Lajoie, Josee IBM P V V V V V Kumoluyi, Akin Imperial College P A A A A A Colvin, Greg IMR P V V V V V Nelson, Clark Intel P V V V V V Andersson, Per Ipso Object Software P A A A A A Stuessel, Marc IST GmBH P A A A A A Ichiro Koshida Japan P V V V V V Stanberry, Linda Lawrence Livermore Lab P V V V V Munch, Max Lex Hack & Associates O A A A A A Dum, Stephen Mentor Graphics P V V V V V Shopiro, Jonathan Merrill Lynch P V Pennello, Tom MetaWare P V V V V V Caves, Jonathan Microsoft A V V V V V Eager, Michael Microtec Research A V V V Saini, Atul Modena Software P V V V V Murphy, Michael Motorola P V V V V V Howe, Barbara Novell P V V V V V Vilot, Mike Object Craft P V 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 Wilcox, Thomas R. Rational P V V V V V Myers, Nathan Rogue Wave Software P V V V V V Ward, Judy Rogue Wave Software 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 Hartinger, Roland Siemens Nixdorf P V V V V V Unruh, Erwin Siemens Nixdorf O A A A A A Steinmuller, Uwe Siemens-Nixdorf A A A A A A Wilkinson, John Silicon Graphics P V V V V V 40 N0597 = 94-0210 Miller, William M. Software Emancipation P V V V V V Henderson, Fergus Standards Australia P V V V V V Ball, Mike Sun Microsystems A V V V V V Clamage, Steve Sun Microsystems S A A A A A Landauer, Doug Sun Microsystems P A A A A A Gibbons, Bill Taligent P V V V V V Harbison, Sam Tartan P V V V Rumsby, Steve UK P V V V V V Dodgson, David Unisys P V V V V V Hendricksen, Dave Unisys A A A A A A Strickland, Henry Versant ? A A A A Knuttila, Kim Visible Decisions P V V V V V Recktenwald, Paulette Visix Software P A A A A Plauger, P. J. WG14 O A A A A Curran, James O A A A Dawes, Beman P V V V Eckel, Bruce Revolution2 P V V V V Hesse, Joseph P V V V V V Holaday, Thomas P A A A A A Musser, David O A A Total Attendance 73 74 73 68 62 Total Votes 52 53 54 50 47 41