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