Editor’s Report

N3126=10-0116, Working Draft, Standard for Programming Language C++, contains the working draft for the standard, with the following changes made since the Final Committee Draft, N3092:

• applied Core Issues 96, 431, 475, 508, 575, 605, 615, 619, 621, 655, 676, 678, 691, 709, 738, 741, 773, 860, 873, 892, 924, 941, 948, marked Ready in N3111
• applied Core Issues 373, 448, 458, 502, 532, 546, 674, 700, 864, marked Tentatively Ready in N3111
• applied Library Issues 1187, 1206, 1278, marked Ready in N3087
• applied the following National Body issues from N3102: US 107, GB 57, GB 68, GB 72, GB 76, US 98, US 99, US 100, GB 85, GB 87, JP3, JP4, GB 100 JP 85, DE 21, JP 6, JP 7, JP 8, JP 9, JP 10, JP 11, JP 12, JP 13, GB 112, US 117, DE 32, CH 32, US 198, US 108, US 120, ES 3, US 114, US 136
• applied N3047, which resolves DE 19
• did not apply US 122, requesting application of N2772; this paper needs more work
• applied National Body issues marked as editorial, as set out below

National Body Comments

All the changes for the comments that are marked as "Accepted" or "Accepted with Modifications" have been made in the current draft of the current working draft.

Comments marked as "Technical" are not, in the judgment of the Project Editor or one of the working groups, editorial. They need to be resolved by the appropriate working group.

A few comments, marked "Typesetting", concern typesetting issues that can't reasonably be resolved until the final document is generated. Bad line breaks, bad page breaks, etc. change as the preceding and surrounding text changes, so there's nothing to be gained by fixing them now. Eventually they'll be marked as "Accepted", but for now, treat "Accepted" as "Accepted and in the Working Draft".

Comments marked as "Unresolved" have been postponed, simply for lack of time. This does not reflect any judgment on their merits.

Note that the contents of the comments here are my own notes from the submissions by the Member Bodies; if any of them differs from what the actual comment says, believe the comment.

Table of Contents

CA: 13 14 15 16 17

CH: 4 5 8 11 12 13 14 23 31 33 34 35

DE: 5

FI: 11 13 14

FR:

GB: 1 2 3 4 5 6 16 17 19 20 23 28 33 34 35 36 42 48 54 59 66 69 77 81 82 84 90 91 94 98 101 102 104 105 114 116 130 134 135 139 140 141

ITTF: 1 2 3 4 5 6 7

JP: 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110

RU: 1 2 3 4 5

US: 4 5 6 7 20 21 43 45 58 61 81 83 86 89 94 109 116 123 125 127 128 129 130 131 132 133 142 143 144 145 146 147 148 149 150 151 152 153 155 156 157 158 159 165 166 167 168 169 170 172 173 174 175 176 177 178 180 187 192 200 206

Classifications: Accepted (164) Accepted with Modifications (9) Rejected (19) Technical (20) Typesetting (3) Unresolved (15)

Accepted (164)

National Body comments that raise editorial issues and have been resolved in the working draft in the way that's suggested in the comment.

Radioactivity Footnotes 343 and 344 from 29.1p1 and 29.3p8 read:

"Atomic objects are neither active nor radioactive" and

"Among other implications, atomic variables shall not

decay".

We suggest that these be removed - the first is pretty clearly a joke, but it's not obvious that the second doesn't have some technical meaning.

Footnotes 343 and 344 from 29.1p1 and 29.3p8 should be removed.

Change second 'if' to 'is'.

missing space between '~' and '5' in expansion

line "f(2 * (2+(3,4)-0,1)) | f(2 * (~5)) & f(2 * (0,1))^ m(0,1);" should read "f(2 * (2+(3,4)-0,1)) | f(2 * (~ 5)) & f(2 * (0,1))^ m(0,1);"

superfluous braces in source

change "int j[] = { t(1,2,3), t(,4,5), t(6,{,}7), t(8,9,)," to "int j[] = { t(1,2,3), t(,4,5), t(6,,7), t(8,9,),"

superfluous spaces after/before parentheses

change

fprintf(stderr, "Flag" );

fprintf(stderr, "X = %d\n", x );

puts( "The first, second, and third items." );

to

fprintf(stderr, "Flag");

fprintf(stderr, "X = %d\n", x);

puts("The first, second, and third items.");

Template function wait_until is missing class Clock template parameter.

Change "template " to "template ".

The paragraph is misleading and incorrect wrt to the current specification, since an async call with launch::sync will execute in the same thread.

Change the paragraph to '30.6 describes components that a C++ program can use to retrieve the result (value or exception) of a function that has run in a (potentially different) thread.'

The term "local" was changed globally to "block-scope", but this section still contains the term "local" (see also core issue 642).

Change "local" to "block-scope" in the first paragraph.

"form the unique_ptr" should be "from the unique_ptr."

"floating-point environmnet" should be "floating- point environment."

C99 supports inline functions so this should not be listed as a distinguishing feature of C++

Update reference to clause 27 to say clause 30.

The phrase "catch clause" in the 2003 standard has become "catch Clause"

Replace the entry for "ll or LL" and "Octal or hexadecimal constant" in table 5 with "long long int unsigned long long int"

All references to m1 from the beginning of 5.1.2/16 up to the last occurrence before '[Example ' to be replaced by m2, and vice versa. Rationale for suggested wording: all other examples that use the 'mN' notation for lambda expressions and which involve nesting apply increasing N (by 1, from 1) to indicate increasing nesting depth.

[expr.prim.lambda] 5.1.2/12. In the example code given the local struct s1 has a member function with signature int s1::work(int n) whose definition does not include an appropriate return statement; neither does it include the conventional "// ..." to indicate that the example is intended to be incomplete.

Suggested change: change the signature of this member function to void s1::work(int n), as the return of int does not contribute to the example.

Order of initialization of arguments in a function is fundamental to the memory model of C++, and the obvious place to look for the definition is in the clause defining function call operators - which currently says nothing. The rules covering this are buried in paragraph 15 of [1.9]. A cross-reference to these words would be most helpful. In particular, it should be made clear that such initialization is indeterminately sequenced (and not unsequenced.)

Add a non-normative note with cross-reference after the first sentance of paragraph 4: "[Note - such initializations are indeterminately sequenced with respect to each other [1.9] - end note]"

Replace "Atrributes" with "Attributes"

It is confusing when a normative paragraph starts with a note. The note starting this paragraph, with its reference to 'this' relating to the previous paragraph and not the content that follows, should be moved into the first paragraph, or the rest of this paragraph after the note should start a new numbered paragraph.

The note starting this paragraph should be moved into the first paragraph, or the rest of this paragraph after the note should start a new numbered paragraph.

With the removal of the deprecated string-literal-to-non- const-char* conversion, member 'b' of struct S should be declared as a 'const' char *.

Fix struct S as: "struct S { int a; const char* b; int c; };"

The 'b' member of union u should be declared const char * to better illustrate the expected cause of failures.

Update union u as: "union u { int a; const char* b; };"

The name "eror" should probably be "error".

Replace:

Tuple<0> eror;

With:

Tuple<0> error;

This subclause is dealing exclusively with dynamic exception specifications, and should clearly say so.

Replace each italicised occurrence of 'exception- specification' with 'dynamic-exception- specification' in clause 15.5.2, [except.unexpected]

The defined terms NTC16S, NTC32S, NTWCS, char16- character sequence, null-terminated char16-character string, char32-character sequence, null-terminated char32-character string, wide-character sequence and null-terminated wide-character string do not occur at any point in the standard outside their definitional subclauses and associated footnotes.

Strike 17.5.2.1.4.3, 17.5.2.1.4.4, 17.5.2.1.4.5 and associated footnotes 170, 171, 172, 173, 174 and 175.

The syntax for attributes was altered specifically to make it legal do declare attributes on functions by making the attribute the first token in the declaration, rather than inserting it between the function name and the opening paren of the parameter list. This is much more readable, and should be the preferred style throughout the library. For example, prefer:

[[noreturn]] void exit(int status);

to

void exit [[noreturn]] (int status);

Update all function declarations throughout the library to use the preferred placement of function- level attributes.

("The function quick_exit() never returns to its caller.") should be removed as redundant. The function is already attributed with [[noreturn]].

Remove paragraph 14

The description for system_error::what (19.5.6.2/14) changed between the C++ Working Papers N2914 and N2960. The latter document indicates that the Returns clause shall read "Returns: An NTBS incorporating the arguments supplied in the constructor.". Instead, in the FCD it now reads "Returns: An NTBS incorporating and code().message() the arguments supplied in the constructor.".

Remove the extra words from 19.5.6.2 [syserr.syserr.members]/14: "Returns: A NTBS incorporating the arguments supplied in the

constructor."

make_pair should be declared in the synopsis of <utility>

add to 20.3 [utility] paragraph 1: template see below make_pair(T1&&, T2&&);

The synopsis precedes the tuple_size and tuple_element declarations with a comment saying "// 20.3.5, tuple-like access to pair:" but the sub-clause should be 20.3.5.3 and the comment should probably be below those declarations (since they, like the tuple declaration above them, are defined in and are not related to pair.)

Also, there should be a comment above piecewise_construct_t giving the sub-clause 20.3.5.5, and it should be at the end of the synopsis.

correct the sub-clause reference for tuple-like access to 20.3.5.3, move the comment after the tuple_element declaration, and add "// defined in " to the tuple_size and tuple_element declarations. Move the piecewise_construct_t and piecewise_constrct declarations to the end of the synopsis and precede them with "// 20.3.5.5 Piecewise construction"

[pairs.pair] defines the class template pair as well as related non-member functions such as comparison operators and make_pair. The related non-member functions should be in a separate sub-clause, otherwise it's not clear that paragraphs below 17 do not refer to members of pair.

Create a new "Pair specialized algorithms" section containing everything below paragraph 17 in [pairs.pair]

The first sentence of the paragraph says "Each object of a type U instantiated form the unique_ptr template..." "form" should be "from"

20.9.5.1

The ~ is missing from the invokation of the destructor of U.

The sequence container adaptors consume sequence containers, but are neither containers nor sequences themselves. While they clearly belong in clause 23, they should not interrupt the presentation of the sequence container themselves.

Move clause 23.3.5 out of clause 23.3. Recommending inserting as a 'new' 23.4 immediately following sequence containers, and before the current 23.4 (associative containers) which would be renumbered 23.5.

Some of the declarations of is_lock_free seem to be missing return types.

Replace:

A::is_lock_free() const volatile;

A::is_lock_free() const;

With:

bool A::is_lock_free() const volatile;

bool A::is_lock_free() const;

Replace "thred" with "thread"

Replace "threds" with "threads".

The links for disambiguation rules go to 6.8, 7.1 and 10.2. Section 8.2 covers ambiguity in declarators, so should be added

Added a link to 8.2 [dcl.ambig.res] to Appendix A p1

ISO/IEC headers and footers should appear on every page

Delete the current introductory text to the Normative references and replace with the following:

“The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.”

Change the title to “Terms and definitions”.

Change the introductory text to:

“For the purposes of this document, the following terms and definitions apply.”

Delete the definite or indefinite article at the beginning of each definition.

Redraft definitions 1.3.11 and 1.3.13 so that they can replace the term in context (i.e. they should not be more than one sentence).

Remove the full stops at the end of the definitions.

There is a description, "17.3 defines additional terms that are used only in Clauses 17 through 27 and Annex D.", but the terms defined in 17.3 are also used in Clauses 28 through 30, which are added recently. So the scope should be expanded to include them.

Typo, "wide-charater" should be "wide-character".

Typo, missing ",". If S contains a raw literal operator the literal L is treated as

Typo, missing ",". If S contains a raw literal operator the literal L is treated as

Change "(10)" to "(Clause 10)".

Change "(9)" to "(Clause 9)".

Change "(5)" to "(Clause 5)".

Change "(5)" to "(Clause 5)".

Change "(clause 7, clause 8)" to "(Clause 7, Clause 8)".

Change "(10)" to "(Clause 10)".

Change "(clause 7)" to "(Clause 7)".

Change "(9)" to "(Clause 9)".

Change "(25)" to "(Clause 25)".

Change "(34)" to "(Table 34)".

Change "(36)" to "(Table 36)".

Change "(section 3.9)" to "(3.9)".

Change "(37)" to "(Table 37)".

Change "(33)" to "(Table 33)".

Change "(38)" to "(Table 38)".

Change "(33)" to "(Table 33)".

Change "(34)" to "(Table 34)".

Change "(36)" to "(Table 36)".

Change "(35)" to "(Table 35)".

Change "(96)" to "(Table 96)".

Change "(table 93)" to "(Table 93)".

Change "(4)" to "(Clause 4)".

Change "(4)" to "(Clause 4)".

Change "(4)" to "(Clause 4)".

Change "(32)" to "(Table 32)".

Change "Clause 21 and 27" to "Clauses 21 and 27".

Change "(35)" to "(Table 35)".

Change "(35)" to "(Table 35)".

Change "(36)" to "(Table 36)".

Change "table 136" to "Table 136".

Change "table 137" to "Table 137".

Change "table 139" to "Table 139".

Change "table 140" to "Table 140".

Change "table 135" to "Table 135".

Change "table 142" to "Table 142".

Change "table 142 or table 143" to "Table 142 or Table 143".

Change "(29)" to "(Clause 29)".

Change "(9)" to "(Clause 9)".

Change "(9)" to "(Clause 9)".

Change "(9)" to "(Clause 9)".

Change "(9)" to "(Clause 9)".

Change "(9)" to "(Clause 9)".

Change "(clause 9)" to "(Clause 9)". Change "(clause 14)" to "(Clause 14)".

In some code examples, ellipsis(...) is used in ill-formed. In these cases, "..." represents omission of some codes like this: class A { /* ... */ } ; But in some cases, it is used without commented-out as below: class A { ... } ; It is an inconsistent usage. They all should be enclosed in a comment.

Change to: class D { /* ... */ };

In some code examples, ellipsis(...) is used in ill-formed. In these cases, "..." represents omission of some codes like this: class A { /* ... */ } ;

But in some cases, it is used without commented-out as below: class A { ... } ; It is an inconsistent usage. They all should be enclosed in a comment.

Change to:

int f (int) { /* ... */ } // definition of f(int)

int f (cInt) { /* ... */ } // error: redefinition of f(int)

Change the font for "while" to constant width type. When the condition of a while statement is a declaration, the scope of the variable that is declared extends

from its point of declaration (3.3.2) to the end of the while statement. A while statement of the form

Change the font for "std::system_error" to constant width type. Throws: system_error when an exception is required

"char*" should be "const char *". The special rule to convert character literal to pointer has been removed from "4.2 Array-to-pointer conversion [conv.array]". char * p1 = "..." ; // ill-formed.(removing const'ness)

char const *p2 = "..." ;// well-formed. There are many code fragments depending on the removed rule. They are ill-formed.

Change to:

struct S { int a; const char* b; int c; };

S ss = { 1, "asdf" };

"char*" should be "const char *". The special rule to convert character literal to pointer has been removed from "4.2 Array-to-pointer conversion [conv.array]". char * p1 = "..." ; // ill-formed.(removing const'ness) char const *p2 = "..." ;// well-formed. There are many code fragments depending on the removed rule. They are ill-formed.

Change to:

union u { int a; const char* b; };

u a = { 1 };

u b = a;

u c = 1; // error

u d = { 0, "asdf" }; // error

u e = { "asdf" }; // error

"char*" should be "const char *". The special rule to convert character literal to pointer has been removed from "4.2 Array-to-pointer conversion [conv.array]". char * p1 = "..." ; // ill-formed.(removing const'ness) char const *p2 = "..." ;// well-formed. There are many code fragments depending on the removed rule. They are ill-formed.

Change to:

struct tnode {

char tword[20];

int count;

tnode *left;

tnode *right;

void set(const char*, tnode* l, tnode* r);

};

"char*" should be "const char *". The special rule to convert character literal to pointer has been removed from "4.2 Array-to-pointer conversion [conv.array]". char * p1 = "..." ; // ill-formed.(removing const'ness) char const *p2 = "..." ;// well-formed. There are many code fragments depending on the removed rule. They are ill-formed.

Change to:

void f() {

union { int a; const char* p; };

a = 1;

p = "Jennifer";

}

"char*" should be "const char *". The special rule to convert character literal to pointer has been removed from "4.2 Array-to-pointer conversion [conv.array]". char * p1 = "..." ; // ill-formed.(removing const'ness) char const *p2 = "..." ;// well-formed. There are many code fragments depending on the removed rule. They are ill-formed.

Change to:

struct B {

int f(int);

};

struct D : B {

int f(const char*);

};

"char*" should be "const char *". The special rule to convert character literal to pointer has been removed from "4.2 Array-to-pointer conversion [conv.array]". char * p1 = "..." ; // ill-formed.(removing const'ness) char const *p2 = "..." ;// well-formed. There are many code fragments depending on the removed rule. They are ill-formed.

Change to:

void f(const char*);

void g() {

extern void f(int);

f("asdf"); // error: f(int) hides f(const char*)

// so there is no f(const char*) in this scope

}

"char*" should be "const char *". The special rule to convert character literal to pointer has been removed from "4.2 Array-to-pointer conversion [conv.array]". char * p1 = "..." ; // ill-formed.(removing const'ness) char const *p2 = "..." ;// well-formed. There are many code fragments depending on the removed rule. They are ill-formed.

Change to:

struct String {

String (const String&);

String (const char*);

operator char* ();

};

String operator + (const String&, const String&);

void f(void) {

char* p= "one" + "two"; // ill-formed because neither

// operand has user-defined type

int I = 1 + 1; // Always evaluates to 2 even if

// user-defined types exist which

// would perform the operation.

}

"char*" should be "const char *". If not corrected, type mismatch is another cause of error in the example below, which is not appropriate for an example here.

template class X {

X();

X(const char* q) { / ... / }

};

X x1; // error: string literal as template- argument

char p[] = "Vivisectionist";

X x2; // OK

Change to:

template class X {

"char*" should be "const char *". The special rule to convert character literal to pointer has been removed from "4.2 Array-to-pointer conversion [conv.array]". char * p1 = "..." ; // ill-formed.(removing const'ness) char const *p2 = "..." ;// well-formed. There are many code fragments depending on the removed rule. They are ill-formed.

Change to:

namespace N {

template class List {

public:

T* get();

};

}

template class Map {

public:

N::List lt;

V get(K);

};

void g(Map& m) {

int i = m.get("Nicholas");

}

a call of lt.get() from Map::get() would place List::get() in the namespace N rather than in the global namespace. ―end example ]

"char*" should be "const char *".

Change to:

template X f(Y,Z);

template void f2();

void g() {

f("aa",3.0);

f("aa",3.0); // Z is deduced to be double

f("aa",3.0); // Y is deduced to be const char*, and

// Z is deduced to be double

f("aa",3.0); // error: X cannot be deduced

f2(); // OK

}

Missing description of acronym "POD", which existed in C++03: The acronym POD stands for "plain old data."

Add "The acronym POD stands for "plain old data." as an annotation.

Typo, "lteral" should be "literal".

Constructors in template declaration are not essential for this example to explain string literal error use.

Delete two constructors in template declaration as follows.

template class X {

/* ... */

};

X x1; // error: string literal as template-argument

char p[] = "Vivisectionist";

X x2; // OK

Note in paragraph 5 says "the atexit() functions shall not introduce a data race" and Note in paragraph 10 says "the at_quick_exit() functions do not introduce ...". Such different expressions in similar functions are confusing.

If these notes are written for unspecified behaviors just before the sentence, "do" would be preferred.

Replace "shall" with "do".

Table numbers are listed incorrectly. "74,75. and" should be "74, 75, and".

While usage of "traits" and "Traits" are explained in 21.2 as template parameters and arguments respectively, specifying "Traits" as template parameter seems misuse. template bool operator()(const basic_string& s1,

const basic_string& s2) const;

Change "Traits" to "traits" in three places.

Typo, duplicated "ispunct" and missing "iswpunct".

Typo, "" should be "".

In Operational semantics for "a.emplace_front(args)", should be . Prepends an object of type T constructed with std::forward(args)...."

Change to .

Typo, "unodified" should be "unmodified".

Typo, missing ";". template void emplace(Args&&... args)

"see below" should be in italic and need one space between words. explicit unordered_multimap(size_type n = seebelow,

Change "(24.1.4)" to "(24.2.6)" and make it a link to section (24.2.6).

Inconsistency between 30.4 paragraph 1 and 30.4.3 paragraph 2. In 30.4 paragraph 1:

namespace std {

...

constexpr defer_lock_t defer_lock { };

constexpr try_to_lock_t try_to_lock { };

constexpr adopt_lock_t adopt_lock { };

}

In 30.4.3 paragraph 2:

namespace std {

...

extern const defer_lock_t defer_lock { };

extern const try_to_lock_t try_to_lock { };

extern const adopt_lock_t adopt_lock { };

}

The writer seems to have forgotten to rewrite latter cases, so 30.4.3 paragraph 2 should be modified as this proposal.

Change "extern const" to "constexpr".

namespace std {

...

constexpr defer_lock_t defer_lock { };

constexpr try_to_lock_t try_to_lock { };

constexpr adopt_lock_t adopt_lock { };

}

In Throw clause, both "Throws: system_error" and "Throws: std::system_error" are used. They should be in a unified way, and we propose to use system_error instead of std::system_error.

Change to:

Throws: system_error

In Throw clause, both "Throws: system_error" and "Throws: std::system_error" are used. They should be in a unified way, and we propose to use system_error instead of std::system_error.

Change to: Throws:

system_error

In Throw clause, both "Throws: system_error" and "Throws: std::system_error" are used. They should be in a unified way, and we propose to use system_error instead of std::system_error.

Change to:

Throws: system_error

In Throw clause, both "Throws: system_error" and "Throws: std::system_error" are used. They should be in a unified way, and we propose to use system_error instead of std::system_error.

Change to:

Throws: system_error

In Throw clause, both "Throws: system_error" and "Throws: std::system_error" are used. They should be in a unified way, and we propose to use system_error instead of std::system_error.

Change to:

Throws: system_error

In Throw clause, both "Throws: system_error" and "Throws: std::system_error" are used. They should be in a unified way, and we propose to use system_error instead of std::system_error.

Change to:

Throws: system_error

In Throw clause, both "Throws: system_error" and "Throws: std::system_error" are used. They should be in a unified way, and we propose to use system_error instead of std::system_error.

Change to:

Throws: system_error

Change to:

Throws: system_error

Change to:

Throws: system_error

Change to:

Throws: system_error

Typo, "." should be ">". decay_copy(std::forward JP 108 (30.6.9/3) [fixed]:

should be . launch::sync — Stores decay_copy(std::forward(f)) and decay_copy(std::forward(args))...

Although implementation limits for at_quick_exit() is mentioned in 18.5 paragraph 5, it is not on the list of Implementation quantities.

Add the following line. — Functions registered by at_quick_exit()[32].

"local scope" has been renamed to "block scope", but the reference to "local scope" still remains in Index.

block scope; see local scope, 37 "local scope" should refer to "block scope".

Change to: local scope; see block scope, 37

Insert reference "(2.3)" after "basic execution character set"

Insert reference "(3.9.1)" after "extended integer type"

Insert reference "(5.7)" after "well-define pointer arithmetic"

Insert references "(4.10, 5.4)" after "well-define pointer conversion"

~ (U_007E) is sometimes replaced with '(U+223C)

Grammatical number mismatch in "an assignment expressions".

using N::d; does not declare N::d.

using N::d; // declares d

The contexts in which an attribute-specifier can appear include statements, described in clause 6, but the cross- references to clauses describing those contexts do not include clause 6.

Add clause 6 to the list of cross-references in the first sentence.

The example includes a line reading class D [[base_check]] : public B {

However, the current syntax in 9¶1 places the attribute- specifier before the class name.

Change the example to read class [[base_check]] D : public B {

s/contructor/constructor/

In the row for X::propagate_on_container_move_assignment, the note says “copied” when it should say “moved”

Change the note as follows: true_type only if an allocator of type X should be copiedmoved

make_pair is missing from the synopsis.

Add template pair make_pair(T1&&, T2&&); to the synopsis in [utility].

Returns clause for move_if_noexcept d refers to a non-existent symbol, t, which should be x.

20.9.11.2.6 [util.smartptr.shared.create]/2 says: "the placement new expression ::new (pv) T() or ::new (pv) T(std::forward(args)...)". It should simply say "the placement new expression ::new (pv) T(std::forward(args)...)", because empty parameter packs expand to nothing. This would be consistent with the requirements in paragraph 1.

Change

"the placement new expression ::new (pv) T() or ::new (pv) T(std::forward(args)...)"

to

"the placement new expression ::new (pv) T(std::forward(args)...)"

Missing 29.8 Fences

There is no free function atomic_compare_exchange_strong for volatile atomic integral types; there is one for non-volatile types.

Add atomic_compare_exchange_strong for volatile integral types to the synopsis.

The synopsis lists the macros ATOMIC_INTEGRAL_LOCK_FREE and ATOMIC_ADDRESS_LOCK_FREE; the Lock-free Property requirements don't have ATOMIC_INTEGRAL_LOCK_FREE, but have 8 macros for the various integral types.

Change 29.2 [atomics.syn] to match 29.4 [atomics.lockfree].

missing atomic_compare_exchange_strong(volatile ....) and atomic_compare)exchange_strong_explict( ...//no volatile *?

> bool atomic_compare_exchange_weak(volatile atomic_itype*, integral*, integral); > bool atomic_compare_exchange_weak(atomic_itype*, integral*, integral); > bool atomic_compare_exchange_strong(atomic_itype*, integral*, integral); > bool atomic_compare_exchange_weak_explicit(volatile atomic_itype*, integral*, > integral, memory_order, memory_order); > bool atomic_compare_exchange_weak_explicit(atomic_itype*, integral*, > integral, memory_order, memory_order); > bool atomic_compare_exchange_strong_explicit(volatile atomic_itype*, integral*, > integral, memory_order, memory_order);

The ATOMIC_..._LOCK_FREE macros have not had changes applied.

Change to match 29.4/0.

The declaration of ATOMIC_VAR_INIT should be referenced to section 29.6 [atomics.types.operations], not 29.7.

Change it to 29.6.

The synopsis is missing the atomic_init function declarations for the bool, integral and address types.

Copy them from 29.5.1.

There are missing function prototypes bool atomic_compare_exchange_strong(volatile atomic_itype*, integral*, integral); and integral atomic_fetch_add(volatile atomic_itype*, integral);

Add them.

There is a duplicate function declaration of integral atomic_fetch_or(volatile atomic_itype*, integral);

Remove the volatile qualifier from the second declaration.

The 'via' 'by' word pairing is awkward.

Replace 'by' with 'via' in 'communication via memory ... and by memory'.

The list of member functions for atomic_bool has four versions of compare_exchange_weak taking one memory_order argument; the last two should be compare_exchange_strong.

Change the last two member functions comapare_exchange_weak taking two memory_order arguments to compare_exchange_strong.

There is a space before the second & in the declaration atomic_itype& operator=(const atomic_itype &) = delete;

Remove the space.

Last 2 should be compare_exchane_strong > bool compare_exchange_weak(bool&, bool, memory_order, memory_order) volatile; > bool compare_exchange_weak(bool&, bool, memory_order, memory_order); > bool compare_exchange_strong(bool&, bool, memory_order, memory_order) volatile; > bool compare_exchange_strong(bool&, bool, memory_order, memory_order); > bool compare_exchange_weak(bool&, bool, memory_order = memory_order_seq_cst) volatile; > bool compare_exchange_weak(bool&, bool, memory_order = memory_order_seq_cst); > bool compare_exchange_weak(bool&, bool, memory_order = memory_order_seq_cst) volatile; > bool compare_exchange_weak(bool&, bool, memory_order = memory_order_seq_cst);

Fix last 2

The first three bullets seem to be missing terminal punctuation.

Add semicolons to ends of the bullets.

Replace "operations ate atomic" with "operations are atomic".

The introductory sentence is missing futures.

Replace "communicate conditions between threads" with "communicate conditions and values between threads".

The identifier cv_status::no_timeout is not in code font.

The paragraph is missing the "Returns:" label.

The text of paragraph 27 says that reset() moves the function object, but the text of paragraph 28 talks about exceptions thrown by the copy constructor.

Change "copy constructor" to "move constructor" in 30.6.10.1/28, bullet 2.

Accepted with Modifications (9)

National Body comments that raise editorial issues and have been resolved in the working draft in a way that's different from the way suggested in the comment.

The replaceable functions in header are all described in clause 18.6 [support.dynamic], where it can be seen that all the listed functions have an exception specification which must be compatible with any replacement function.

Narrow the reference to (Clause 18) to (Clause 18.6). Add the missing exception specification on each function signature:

void* operator new(std::size_t size) throw(std::bad_alloc);

void* operator new(std::size_t size, const std::nothrow_t&) throw();

void operator delete(void* ptr) throw();

void operator delete(void* ptr, const std::nothrow_t&) throw();

void* operator new[](std::size_t size) throw(std::bad_alloc);

void* operator new[](std::size_t size, const std::nothrow_t&) throw();

void operator delete[](void* ptr) throw();

void operator delete[](void* ptr, const std::nothrow_t&) throw();

(note that other comments might further want to replace 'throw()' with 'noexcept')

Resolution comment: Cross-reference changed as suggested. Additions to namementions not done: these are not declarations.

It looks like the erase/insert effects given in p11 are intended for p12.

Move the erase/insert effects down to p12

Resolution comment: The code in question is a remnant from a previous version. It has now been removed.

Change "(31)" to "(Clause 31)".

Resolution comment: Changed to "(Table 31)"

Change "(32)" to "(Clause 32)".

Resolution comment: Changed to "(Table 32)"

In some code examples, ellipsis(...) is used in ill-formed.

Change to:

inline static constexpr float infinity() throw() {

return /* ... */;

}

inline static constexpr float quiet_NaN() throw() {

return /* ... */;

}

inline static constexpr float signaling_NaN() throw() {

return /* ... */;

}

Resolution comment: Replaced "..." by "value"

Typo, unnecessary new-line.

a_uniq.

emplace(args)

Typo, unnecessary space.

a_eq. emplace(args)

Resolution comment: The newline is needed, but the space is unnecessary. Removed the space.

International Standards do not make “statements”; they “specify” or “require” instead.

s/statements/ specifications/

Resolution comment: Removed the offending word.

The sentence "The order argument shall not be memory_order_acquire nor memory_order_acq_rel." is awkwardly phrased.

Change the sentence to "The order argument shall be neither memory_order_acquire nor memory_order_acq_rel."

Resolution comment: Changed "nor" to "or"

Paragraph mentions compare_exchange, which no longer exists.

Change “compare_exchange” to “compare_exchange_weak”.

Resolution comment: Changed "compare_exchange" to "compare and exchange"

Rejected (19)

National Body comments that raise editorial issues and have been rejected.

constant-expression as given by C++'s grammar allows far more syntactical constructs than those that are allowed in preprocessor context. The footnote 145 provides some hints on the limitations, but in our opinion it should be made more clear that the "constant-expression" allows less than a lookup of the corresponding grammar rule suggests

Add a note or extend footnote 145 with "Note that constant-expression is much more limited than the C++ grammar rule would suggest. See the following paragraphs how it is limited in the context of conditional inclusion."

Resolution comment: The current wording is the same as in C++03, and hasn't caused confusion.

The sentences contain superflous "or"s.

Change "The function will unblock when signaled by a call to notify_one() or a call to notify_all(), if abs_time <= Clock::now(), or spuriously." to "The function will unblock when signaled by a call to notify_one(), a call to notify_all(), if abs_time <= Clock::now(), or spuriously."

Resolution comment: This is correct as written. There are three conditions: "when signalled", "if", "spuriously". The first has two parts, separated by "or".

"...as defined here..." should be "...as defined below...".

Resolution comment: "As defined here" refers to this standard, which is the intention. If it were normative text the correct phrase would be "in this International Standard", but for a note, the text as written is sufficient.

type_traits is a core support facility offered by the compiler, and exposed with a library interface that is required in a free-standing implementation. It has far more in common with numeric_limits than the utility components in clause 20, and should move to clause 18.

Move clause 20.7 into clause 18.

Resolution comment: Type traits support queries about all types, not just built-in types. They do no belong in Clause 18.

It is mildly distasteful to dereference a null pointer as part of our specification, as we are playing on the edges of undefined behaviour. With the addition of the declval function template, already used in these same expressions, this is no longer necessary.

Replace the sub-expression '*(U*)0' with the sub- expression 'declval()' in the specification for has_nothrow_copy_assign and has_nothrow_move_assign type traits.

Resolution comment: There is no undefined behavior because the expression is an unevaluated operand. It's not at all clear that the proposed change would be clearer.

unique_ptr is a smart pointer so [unique.ptr] should be a sub-clause of [util.smartptr]

Resolution comment: [util.smartptr] deals with shared_ptr and weak_ptr, which work together. Adding unique_ptr would create a muddle.

20.9.6

There is a missing '_' in the piecewise-construct call for pair in the class definition.

Fix the declaration:

template

void construct(pair* p,

piecewise_construct_t, tuple x, tuple y);

Resolution comment: The declaration is identical to the proposed text.

In some code examples, ellipsis(...) is used in ill-formed.

Change to:

enum bitmask {

V0 = 1 << 0, V1 = 1 << 1, V2 = 1 << 2, V3 = 1 << 3, ... };

static const bitmask C3 (V3 );

/* ... */

Resolution comment: This is pseudo-code; okay as written

The word "object" often copies as "ob ject"

Resolution comment: Some PDF viewers do this. Don't know why, or how to avoid it.

Missing comma in "is not virtual the size might".

Resolution comment: Because of the comma later in the sentence, a comma here would be wrong.

The requirement for X(rv) that move construction of the allocator not throw can be misread as requiring that move construction of the whole container not throw.

Add non-normative note:

Requires: move construction of A shall not exit via an exception. [Note: This requirement on allocators exists so that implementations can (optionally) provide a nothrow guarantee on move construction of some containers. – end note]

Resolution comment: The text as is seems quite clear; the proposed note just muddles things.

The definition of ATOMIC_VAR_INIT should be 'implementation defined' rather than 'see below'.

Change it to 'implementation defined'.

Resolution comment: No, definitely not implementation defined. "See below "is correct.

The table shows no disinct meaning for memory_order_seq_cst.

Add another bullet: "- memory_order_seq_cst: See below."

Resolution comment: It's named in the second and fourth bullet items

The macros are all specified as "implementation-deifned"; they should be "see below", since the required values are spelled out.

Change the definitions of the macros in 29.4 [atomics.lockfree] from "implementation-defined" to "see below".

Resolution comment: Implementation defined requires that the implementation document what it does. Removing this requirement would be a technical change.

The first three bullets seem to be missing terminal punctuation.

Add semicolons to ends of the bullets.

Resolution comment: Seems to be a duplicate of US 166 but with the wrong section number

The definition of ATOMIC_VAR_INIT should be 'implementation defined' rather than 'see below'.

Change it to 'implementation defined'.

Resolution comment: No, we should not require implementors to document the details of how they do this.

The definition of atomic_init should be grouped with the value constructor.

Move the atomic_init definition to just after the constructor definition.

Resolution comment: The current order reflects the order of declarations. No need to change it.

The first note is about effects, not returns.

Move this note to just after the Effects paragraph.

Resolution comment: This would require a significant rewrite, because the Returns clause refers to the "result of the comparison" from the Effects clause. Okay as written.

Unintended paragraph break.

Proposal: Remove the paragraph break between "will be in a loop." and "When a compare-and- exchange is in a loop,".

Resolution comment: Okay as written. Two different subjects, two paragraphs.

Technical (20)

National Body comments that were classified by the National Body as editorial issues but are not considered editorial by the Project Editor, the Core Working Group, or the Library Working Group.

In 1.10p13 a coherence condition is stated on the values of atomic reads:

"Furthermore, if a value computation A of an atomic object M happens before a value computation B of M, and the value computed by A corresponds to the value stored by side effect X, then the value computed by B shall either equal the value computed by A, or be the value stored by side effect Y, where Y follows X in the modification order of M."

We suggest that this be replaced with the following:

"Furthermore, if a value computation A of an atomic object M happens before a value computation B of M, and A takes its value from the side effect X, then the value computed by B shall either be the value stored by X, or the value stored by a side effect Y, where Y follows X in the modification order

of M."

Add the following to 1.10p4: [ Note: There may be non-atomic

writes to atomic objects, for example on initialization and renitialization. - end note]

We suggest changing the definition of dependency-ordered-before in 1.10p9 to the following:

An evaluation A is dependency- ordered before an evaluation B if - A performs a release operation on an atomic object M, and on another thread, B performs a consume operation on M and reads a value written by any side effect in the release sequence headed by A, or - for some evaluation X, A is dependency-ordered before X and X carries a dependency to B.

change the rule for lambda-declarator to

lambda-declarator: ( parameter-declaration-clause ) mutableopt

exception-specificationopt attribute-specifieropt trailing-return-typeopt

'noptr-abstract-declarator:' rule misses 'opt' subscript from the constant expression within the array brackets. This seems to be an editorial oversight

change: "noptr-abstract-declaratoropt [ constant- expression ] attribute-specifieropt" to "noptr- abstract-declaratoropt [ constant-expressionopt ] attribute-specifieropt"

The first sentence has non-English syntax.

Change to "The weak compare-and-exchange operations may fail spuriously, that is, return false while leaving the contents of memory pointed to by expected unchanged."

The term "associated asynchronous state" is long, ugly and misleading terminology. When introduced we agreed upon that we should come up with a better name. Here it is: "liaison state". Since the state is hidden and provides synchronization of a future with its corresponding promise, we believe "liaison state" is a much better and shorter name (liaison ~ (typically hidden) relationship)

Change all occurrences of "associated asynchronous state" to "liaison state".

In [intro.refs] the spec references ISO/IEC 9945:2003 even though a later revision, ISO/IEC 9945:2008 has already been released: http://www.iso.org/iso/catalogue_detail.htm?csnumber=50 516

The section should be updated to reference the latest version. In addition, since POSIX is a registered trademark of the IEEE, the spec should use the registered trademark (R) symbol wherever it references it. Alternatively, it can refer to ISO/IEC 9945.

The evaluation of function arguments are now indeterminately sequenced, rather than left completely unspecified, as part of the new language describing the memory model. A clearer example of unspecified behavior should be used here.

From Clark Nelson:

Pete,

GB 5 came to my attention because it refers to evaluation order and such. At first I thought it was off-base, but then I figured the actual point of the request.

In any event, I have come up with a few possible alternative examples to substitute in 1.9p3:

the order of execution of indeterminately sequenced evaluations

the result of a relational comparison between pointers to unrelated objects

whether distinct identical string literals are distinct objects

No extra charge. :-)

Clark

There are core issues surrounding the undefined behavior of dereferencing a null pointer. It appears the intent is that dereferencing *is* well defined, but using the result of the dereference will yield undefined behavior. This topic is too confused to be the reference example of undefined behavior, or should be stated more precisely if it is to be retained.

The register keyword is deprecated, so does not make for a good example. Suggest substituting the new storage class specifier, 'thread_local', instead.

Use 'thread_local' in place of 'register' in the following sentance: "[ Example: register char* becomes char* —end example ]"

The synopsis for the header lists the macros ATOMIC_INTEGRAL_LOCK_FREE and ATOMIC_ADDRESS_LOCK_FREE. The ATOMIC_INTEGRAL_LOCK_FREE macro has been replaced with a set of macros for each integral type, as listed in 29.4

Replace "#define ATOMIC_INTEGRAL_LOCK_FREE unspecified" with #define ATOMIC_CHAR_LOCK_FREE implementation-defined

1. define ATOMIC_CHAR16_T_LOCK_FREE implementation-defined #define ATOMIC_CHAR32_T_LOCK_FREE implementation-defined
2. define ATOMIC_WCHAR_T_LOCK_FREE implementation-defined #define ATOMIC_SHORT_LOCK_FREE implementation-defined
3. define ATOMIC_INT_LOCK_FREE implementation-defined #define ATOMIC_LONG_LOCK_FREE implementation-defined
4. define ATOMIC_LLONG_LOCK_FREE implementation-defined

The first sentence of 29.6p23 was changed by n2992 but now makes no sense: "that is, return false while leaving the contents of memory pointed to by expected before the operation is the same that same as that of the object and the same as that of expected after the operation." There's a minor editorial difference between n2992 ("is that same as that" vs "is the same that same as that") but neither version makes sense.

Also, the remark talks about "object" which should probably be "object or this" to cover the member functions which have no object parameter.

Fix the Remark to say whatever was intended.

There are inconsistent definitions for allocator_arg. In 20.9 [memory] paragraph 1, constexpr allocator_arg_t allocator_arg = allocator_arg_t();

and in 20.9.1, const allocator_arg_t allocator_arg = allocator_arg_t();

Change "const" to "constexpr" in 20.9.1 as follows. constexpr allocator_arg_t allocator_arg = allocator_arg_t();

atomic_bool has a volatile assignment operator but not a non-volatile operator The other integral types have both..

Add a non-volatile assignment operator to atomic_bool.

“is the same that same as that of” is not grammatical (and is not clear)

The definition of the default constructor needs exposition.

Add a new paragraph: A::A() = default; Effects: Leaves the atomic object in an uninitialized state. [Note: These semantics ensure compatiblity with C. --end note]

The order specifications are incomplete because the non- _explicit functions do not have such parameters.

Add a new sentence: "If the program does not specify an order, it shall be memory_order_seq_cst." Or perhaps: "The non- _explicit non-member functions shall affect memory as though they were _explicit with memory_order_seq_cst."

The first sentence is grammatically incorrect.

Replace the sentence with two: "The weak compare-and-exchange operations may fail spuriously. That is, it may return false while leaving the contents of memory pointed to by expected the same as it was before the operation."

The first sentence of this paragraph doesn't make sense.

Figure out what it's supposed to say, and say it.

Typesetting (3)

National Body comments that reflect glitches in typesetting that are dependent on details of the surrounding text. For example, the placement of tables is determined by where the table occurs in the source text, where the nearest page breaks are, and where nearby titles occur. These glitches change as the surrounding words and structure change, so there is no way to fix them until the final step in creating the standard.

Move footnote 24 from page 28 to page 27

Protect all identifiers agains hyphenation

static_cast is broken across two lines

do not hyphenate static_cast

Unresolved (15)

Editorial issues that have not yet been resolved.

1.10p12 last note: "...as defined here..." should be

"...as defined below...".

Resolution comment: The reference really should be to "data races as defined in this International Standard", because the note compares this definition with the generally-understood meaning of data races in sequentially-consistent executions. That's far too stilted, and "as defined here" seems like a reasonable way to phrase it in the less formal context of a note.

We have class templates and function templates, shouldn't we call template aliases alias templates for consistency?

Change “template alias” -> “alias template” everywhere.

This subclause has grown large, with many components, and so should stand alone.

Promote 20.8 and all its contents up to a new numbered clause.

This subclause has grown large, with many components, and so should stand alone.

Promote 20.9 and all of its contents to a new, top- level, numbered clause.

Redraft the notes and examples to the terms and definitions in accordance with D.3.9 of the ISO/IEC Directives, Part 2.

' (U+0027) is sometimes replaced with '(U+2019); use U_0027 in code samples

26.5?

N3056, as adopted, calls for each use of lshift to be followed by a subscripted value.

Adjust all occurrences of the lshift notation so as to match the notation of N3056.

The synopsis for min() and max() is lacking “()” in the return statements.

return Engine::min();

return Engine::max();

Engine::min is a function and ought be invoked in the context where mentioned, as should Engine::max.

Append parentheses so as to become return Engine::min() and return Engine::max().

Engine::min is a function and ought be invoked in the context where mentioned, as should Engine::max.

Append parentheses so as to become return Engine::min() and return Engine::max().

The expression begin[x+q] is incorrect since x is unspecified .

Replace x by k so as to obtain begin[k+q].

The phrase “three more times” is misleading.

s/three more times,/again,/

Values r3 and r4 are correctly specified, but in their subsequent use they are interchanged with respect to the original algorithm by Mutso Saito.

Exchange subscripts so as to read as follows: “... update begin[k + p] by xoring it with r3, update begin[k + q] by xoring it with r4, and ...”

The last sentence includes “begin[x + q]” but “x” is non- sensical here.

Change “begin[x + q]” to “begin[k + q]”

The use of r3 and r4 is reversed in the final sentence of 8c according to the defect report on comp.std.c++ that this specification is based on: http://groups.google.com/group/comp.std.c++/browse_thre ad/thread/e34cbee1932efdb8/aad523dccec12aed?q=grou p:comp.std.c%2B%2B+insubject:seed_seq

If you follow the SFMT link to the software, the software also uses r3 and r4 in a manner inconsistent with N3092. I believe N3092 should be changed to be consistent with the defect report.

Change 8c to end:

... update begin[k + p] by xoring it with r3, update begin[k + q] by xoring it with

r4, and ...