Boost-Commit :

Date view	Thread view	Subject view	Author view

Subject: [Boost-commit] svn:boost r51561 - sandbox/committee/LWG
From: bdawes_at_[hidden]
Date: 2009-03-03 08:29:00

Next message: bdawes_at_[hidden]: "[Boost-commit] svn:boost r51562 - sandbox/committee/LWG"
Previous message: bdawes_at_[hidden]: "[Boost-commit] svn:boost r51560 - sandbox/committee/LWG"

Author: bemandawes
Date: 2009-03-03 08:28:56 EST (Tue, 03 Mar 2009)
New Revision: 51561
URL: http://svn.boost.org/trac/boost/changeset/51561

Log:
cleanup
Text files modified:
sandbox/committee/LWG/0xCD1_Comments.html | 42573 ++++++++++++++++-----------------------
1 files changed, 18088 insertions(+), 24485 deletions(-)

Modified: sandbox/committee/LWG/0xCD1_Comments.html
==============================================================================
--- sandbox/committee/LWG/0xCD1_Comments.html (original)
+++ sandbox/committee/LWG/0xCD1_Comments.html 2009-03-03 08:28:56 EST (Tue, 03 Mar 2009)
@@ -1,24486 +1,18089 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=windows-1252">
- <TITLE>C++0x CD1 NB Comments</TITLE>
- <META NAME="GENERATOR" CONTENT="Microsoft FrontPage 5.0">
- <META NAME="AUTHOR" CONTENT="dow">
- <META NAME="CREATED" CONTENT="20090221;19590000">
- <META NAME="CHANGEDBY" CONTENT=" Barry E Hedquist">
- <META NAME="CHANGED" CONTENT="20090222;18460000">
- <META NAME="DESCRIPTION" CONTENT="FORM (ISO)">
- <STYLE TYPE="text/css">
- 
- </STYLE>
-</HEAD>
-<BODY LANG="en-US" TEXT="#000000" DIR="LTR">
-<DIV TYPE=HEADER>
- <TABLE BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0 style="border-collapse: collapse">
- <TR VALIGN=TOP>
- <TD>
- 
- 1
- </TD>
- <TD>
- 
- 2
- </TD>
- <TD>
- 
- 3
- </TD>
- <TD>
- 
- 4
- </TD>
- <TD>
- 
- 5
- </TD>
- <TD>
- 
- 6
- </TD>
- <TD>
- 
- 7
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- MB1 
- 
- </TD>
- <TD>
- 
- Clause
- No./ Subclause No./ Annex (e.g.
- 3.1)
- </TD>
- <TD>
- 
- Paragraph/ Figure/Table/Note (e.g.
- Table 1)
- </TD>
- <TD>
- 
- Type
- of com-ment2
- </TD>
- <TD>
- 
- Comment (justification for
- change) by the MB
- </TD>
- <TD>
- 
- Proposed change by the MB
- </TD>
- <TD>
- 
- Disposition
- 
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 1
- </TD>
- <TD>
- General
- Comment
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ge
- </TD>
- <TD>
- 
- Interactions
- between several new features appear obscure, and very few examples
- are offered to guide understanding of the formal text on
- interaction between these new additions.
- 
- We
- worry about the complexity of the programming model so created.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US 1
- </TD>
- <TD>
- 1-16
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ge/te
- </TD>
- <TD>
- 
- The active issues identified
- in WG21 N2803, C++ Standard Core Language Active Issues, must be
- addressed and appropriate action taken.
- 
- 
- 
- 
- http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html
- 
- 
- </TD>
- <TD>
- 
- Appropriate action would
- include making changes to the CD, identifying an issue as not
- requiring a change to the CD, or deferring the issue to a later
- point in time.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- CA-1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ge
- </TD>
- <TD>
- There
- are quite a number of defects for the current CD recorded in
- SC22/WG21-N2803 and N2806
- </TD>
- <TD>
- Consider
- these comments and update ISO/IEC CD 14882 accordingly
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- DE-1
- </TD>
- <TD>
- 1
- through 16
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ge/te
- </TD>
- <TD>
- DE-1
- Consider addressing a significant part of the unresolved core
- language issues presented in WG21 document N2791 "C++
- Standard Core Language Active Issues, Revision 59", available
- at
- http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2791.html
- .
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- CH
- 2
- </TD>
- <TD>
- all
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- The
- issues on the issues lists shall be addressed before the standard
- becomes final.
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US 3
- </TD>
- <TD>
- all
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- Latin
- abbreviations are presented incorrectly.
- </TD>
- <TD>
- Italicize
- all Latin abbreviations, append commas after each occurrence of
- i.e. and e.g., and remove extraneous space after
- each such abbreviation.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 3
- </TD>
- <TD>
- 1
- [intro.scope]
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- C++
- is split at the end of line.
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US 4
- </TD>
- <TD>
- 1.1
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- There
- is a bad line break in "C++".
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK
- 1
- </TD>
- <TD>
- 1.1
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- List
- of additional facilities over C has been extended with this
- standard, so should be mentioned in the introductory material.
- </TD>
- <TD>
- Add
- the following to the list in 1.1p2: atomic operations concurrency
- alignment control user-defined literals attributes 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 4
- </TD>
- <TD>
- 1.2
- [intro.refs]
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- Is
- the lack of reference to ISO/CEI 9899/AC3:2007 voluntary?
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK
- 2
- </TD>
- <TD>
- 1.2
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- 
- We
- recommend taking the latest update to each listed standard, yet
- the C standard is quite deliberately held back to the 1990 version
- without comment.+
- 
- 
- </TD>
- <TD>
- ...
- not sure ...
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK
- 3
- </TD>
- <TD>
- 1.3.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- definition of an argument does not seem to cover many assumed use
- cases, and we believe that is not intentional.
- </TD>
- <TD>
- Revise
- the definition of argument to answer question such as: Are
- lambda-captures arguments? Are type names in a throw-spec
- arguments? 'Argument' to casts, typeid, alignof, alignas, decltype
- and sizeof? why in x[arg] : arg is not an agrument, but the value
- forwarded to operator[]() is ? Does not apply to operators as
- call-points not bounded by parenthises ? Similar for copy
- initialization and conversion? what are Deduced template
- 'arguments'? what are 'default arguments'? can attributes have
- arguments? what about concepts, requires clauses and concept_map
- instantiations? What about user-defined literals where parens are
- not used?
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK
- 4
- </TD>
- <TD>
- 1.3.3
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- This
- definition is essentially worthless, as it says nothing about what
- distinguished a diagnostic message from other output messages
- provided by the implementation
- </TD>
- <TD>
- ...
- add something about the diagnostic message being a message issues
- by the implementation when translating a program that violates the
- rules of the standard. ...
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 5
- </TD>
- <TD>
- 1.3.4
- [defns.dynamic.type]
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- "The
- dynamic type of an rvalue expression is its static type." Is
- this true with rvalue references?
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US 5
- </TD>
- <TD>
- 1.3.5
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- The
- wording is unclear as to whether it is the input or the
- implementation "that is not a well-formed program".
- </TD>
- <TD>
- Reword
- to clarify that it is the input that is here considered not
- well-formed.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 6
- </TD>
- <TD>
- 1.3.6
- [defns.impl.defined]
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- There
- is a page break between the title and the paragraph.
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 7
- </TD>
- <TD>
- 1.3.13
- [defns.undefined]
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- [intro.execution]/5
- explicitly allows non causal undefined behaviour,
- </TD>
- <TD>
- Adding
- it to the note outlying possible undefined behaviours.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US 6
- </TD>
- <TD>
- 1.3.14
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ge
- </TD>
- <TD>
- 
- Unspecified behavior does not
- clearly state whether or not undefined behavior is permitted. (The
- standard says that "usually, the range of possible behaviors
- is delineated", but what happens if the range is not
- delineated? Is a crash, or worse, allowed?)
- 
- 
- </TD>
- <TD>
- Clearly
- state whether or not Unspecified behavior includes undefined
- behavior.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 8
- </TD>
- <TD>
- 1.4
- [intro.compliance]
- </TD>
- <TD>
- 8
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- The
- paragraph as its stands seems to require that violations of the
- ODR (which make a program ill-formed) are required to be diagnosed
- if the program also uses an extension which defines some cases of
- ODR.
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK
- 5
- </TD>
- <TD>
- 1.5
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ge
- </TD>
- <TD>
- Missing
- checklist of implementation defined behaviour (see ISO/IEC TR
- 10176, 4.1.1p6)
- </TD>
- <TD>
- Provide
- a new annex with the missing checklist
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK
- 6
- </TD>
- <TD>
- 1.5
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ge
- </TD>
- <TD>
- Missing
- annex describing potential incompatibility to previous edition of
- the standard (see ISO/IEC TR 10176, 4.1.1p9)
- </TD>
- <TD>
- Provide
- a new annex with the missing documentation. See n2733(08-0243) for
- a starting point
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 7
- </TD>
- <TD>
- 1.5
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- There
- is no mention of Clause 17.
- </TD>
- <TD>
- Include
- Clause 17 among the list of Clauses that specify the Standard
- Library.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 8
- </TD>
- <TD>
- 1.5
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- te
- </TD>
- <TD>
- The
- paragraph omits to mention concepts and concept maps among its
- list of entities defined in the Standard Library.
- 
- 
- </TD>
- <TD>
- Mention
- concepts and concept maps among the list of entities.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US 9
- </TD>
- <TD>
- 1.6
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- The syntax description does
- not account for lines that wrap.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US 10
- </TD>
- <TD>
- 1.7
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- The
- term thread is used before defined.
- </TD>
- <TD>
- 
- Reference
- 1.10 [intro.multithread].
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 11
- </TD>
- <TD>
- 1.7
- </TD>
- <TD>
- ¶
- 3 last sent.
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- The
- phrase “threads of execution” should be accompanied by
- a reference to [intro.multithread].
- </TD>
- <TD>
- Insert
- the recommended reference.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 12
- </TD>
- <TD>
- 1.7
- </TD>
- <TD>
- ¶
- 3 first sent.
- </TD>
- <TD>
- te
- </TD>
- <TD>
- A
- memory location is not an object as the sentence claims.
- </TD>
- <TD>
- Clarify
- that a memory location “holds” an object rather than
- that it “is” an object.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 13
- </TD>
- <TD>
- 1.7
- </TD>
- <TD>
- ¶
- 3 last sent.
- </TD>
- <TD>
- te
- </TD>
- <TD>
- It
- is unclear what is meant by memory locations that are "separate":
- are they distinct? non-overlapping? how much "separation"
- is needed?
- </TD>
- <TD>
- Provide
- either a better definition of “separate” or reword
- (this and subsequent paragraphs) to avoid this term.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 14
- </TD>
- <TD>
- 1.7
- </TD>
- <TD>
- ¶
- 4
- </TD>
- <TD>
- te
- </TD>
- <TD>
- The
- phrase "no matter what the sizes of the intervening
- bit-fields happen to be" contradicts the claim of separation
- "by a zero-length bit-field declaration".
- </TD>
- <TD>
- Delete
- the “no matter…” phrase, or resolve the
- contradiction in a different way.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 15
- </TD>
- <TD>
- 1.7
- </TD>
- <TD>
- ¶
- 5
- </TD>
- <TD>
- te
- </TD>
- <TD>
- A
- struct does not “contain” memory locations.
- </TD>
- <TD>
- Reword
- so that a struct is “held in” one or more memory
- locations.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 16
- </TD>
- <TD>
- 1.9
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- The
- discussion of observable behavior in 1.9 is not consistent with
- the addition of threads to the language. Volatile reads and
- writes and other observable actions no longer occur in a single
- "sequence”.
- </TD>
- <TD>
- Remove/replace
- various occurrences of "sequence" in 1.9.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK
- 8
- </TD>
- <TD>
- 1.9
- </TD>
- <TD>
- 5
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- With
- parallel execution there is no longer the idea of a single
- execution sequence for a program. Instead, a program may be
- considered a set of exectution sequences.
- </TD>
- <TD>
- Update
- first sentance as: A conforming implementation executing a
- well-formed program shall produce the same observable behavior as
- one of the possible SETS OF execution sequences of the
- corresponding instance of the abstract machine CONFORMING TO THE
- MEMORY MODEL (1.10) with the same program and the same input.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK
- 7
- </TD>
- <TD>
- 1.9
- </TD>
- <TD>
- 6
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Does
- the term 'sequence' imply all reads/writes through volatile memory
- much be serialized, and cannot occur in parallel on truly parallel
- hardware? Allow for multiple concurrent sequences where each
- sequence is constrained by this observable behaviour rule, and
- multiple sequences are constrained by the memory model and
- happens-before relationships defined in 1.10
- </TD>
- <TD>
- Replace
- 'sequence' with 'sequences'.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 9
- </TD>
- <TD>
- 1.9
- [intro.execution]
- </TD>
- <TD>
- 16
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- This
- example use int *v while the other examples seems to use notation
- like int* v.
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 17
- </TD>
- <TD>
- 1.10
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Ge
- </TD>
- <TD>
- This
- definition of “thread” is poor, and assumes the user
- already knows what multi-threaded means (probably true!). In
- particular, it does not deal adequately with the concept that all
- threads share the same address space.
- </TD>
- <TD>
- Replace
- first sentence of para 1 as follows:
- 
- Under
- a hosted implementation, a C++ program can have more
- than one thread of
- execution (a.k.a. thread)
- running concurrently.
- Each thread is a single flow of control within a program.
- Anything whose address may be determined by a thread, including
- but not limited to static objects, storage obtained via new or by
- any dynamic allocator, directly addressable storage obtained
- through implementation-defined functions, and automatic variables,
- are accessible to all threads in the same program.
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK
- 9
- </TD>
- <TD>
- 2.1
- </TD>
- <TD>
- 2,
- 4
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Undefined
- behaviour is a drastic way to silently ignore minor issues. The
- cases in this paragraph could be easily defined. In this case opt
- for conditionally supported behaviour, which mandates a diagnostic
- if the compiler is not prepared to handle the syntax consistently.
- </TD>
- <TD>
- Replace
- undefined behaviour with conditionally supported behavior.
- Conditional behaviour may be implementation defined, although
- suggest there is a reasonable default in each case. For creating a
- universal-character name, splice text to create a
- universal-character. In the case of a file ending without a
- newline, treat as if the newline was implictly added, with an
- empty line to follow if the last character was a back-slash.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK
- 10
- </TD>
- <TD>
- 2.1
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Implementation
- defined seems unnecessarily burdensome for negligible gain. I am
- yet to see code that depended on whether non-empty sequences of
- whitespace were concatenated. Better left unspecified.
- 
- 
- </TD>
- <TD>
- How
- the compiler treats non-empty sequences of whitespace should be
- left unspecified, rather than implementation-defined.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 10
- </TD>
- <TD>
- 2.1
- [lex.phases]/5 and 2.2 [lex.charset]/3
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- [defns.multibyte]
- "the extended character set."
- 
- [lex.charset]/3
- cited below implies that there is an extended character set per
- locale.
- 
- [lex.phases]/5
- "Each [...] universal-character-name [...] is converted to
- the corresponding member of the execution character set"
- 
- [lex.charset]/3
- "The values of the members of the execution character sets
- are implementation defined, and any additional members are
- locale-specific."
- 
- 
- 
- Together
- they seem to imply that what is locale-specific is if a value is
- valid or not for the current locale, not the representation of a
- given universal character.
- 
- 
- 
- This
- is not the behaviour of at least some compilers I've access to
- which are allowing different codes for the same abstract character
- in different locale. During phase 5, they are using an
- implementation defined char set.
- 
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- UK 
- 
- 11
- </TD>
- <TD>
- 2.3
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Trigraphs
- are a complicated solution to an old problem, that cause more
- problems than they solve in the modern environment. Unexpected
- trigraphs in string literals and occasionally in comments can be
- very confusing for the non-expert.
- </TD>
- <TD>
- Deprecate
- the whole of 2.3 and move it to appendix D.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- UK 
- 
- 12
- </TD>
- <TD>
- 2.4,
- 2.8
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- This
- undefined behaviour in token concatenation is worrying and we
- believe hard to justify. An implementation should either support
- this in a defined way, or issue a diagnosic. Documenting existing
- practice should not break existing implementations, although
- unconditionally requiring a diagnostic would lead to more portable
- programs.
- 
- 
- </TD>
- <TD>
- Replace
- undefined behaviour with conditionally supported behaviour with
- implementation defined semantics.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 18
- </TD>
- <TD>
- 2.4
- </TD>
- <TD>
- ¶
- 2
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- The
- paragraph begins with an empty line.
- </TD>
- <TD>
- Delete
- the empty line.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 11
- </TD>
- <TD>
- 2.4
- [lex.pptokens]
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- There
- are spurious empty lines.
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 12
- </TD>
- <TD>
- 2.5
- [lex.digraph] and 2.11 [lex.key]/2
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- The
- alternative representations are reserved as such even in
- attribute. Is that what is wanted?
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FI
- 2
- </TD>
- <TD>
- 2.5
- </TD>
- <TD>
- Table
- 2
- </TD>
- <TD>
- te
- </TD>
- <TD>
- Add
- eq, for spelling out == in order to distinguish it from the
- assignment operator.
- </TD>
- <TD>
- See
- eq-keyword.doc, eq-keyword.ppt
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- UK 
- 
- 13
- </TD>
- <TD>
- 2.9
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- This
- text is confusing in isolation, as it implies pp-numbers do not
- have a value in translation phase 4 when evaluating #if
- preprocessor expressions.
- </TD>
- <TD>
- Add
- a note with a cross-refernce to 16.1 that a pp-number may briefly
- acquire a value during translation phase 4 while evaluating #if
- expressions.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- UK 
- 
- 14
- </TD>
- <TD>
- 2.11
- </TD>
- <TD>
- table
- 3
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- table is nearly sorted, but not quite. It was sorted in previous
- versions of the standard.
- 
- 
- </TD>
- <TD>
- Sort
- the table.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 1
- </TD>
- <TD>
- 2.11
- </TD>
- <TD>
- Table
- 3
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- Keywords
- in the table are listed disorderly. Also, a part of a frame of the
- table is not drawn.
- </TD>
- <TD>
- Sort
- it in alphabetical order. Complete the table frame.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 19
- </TD>
- <TD>
- 2.13.1
- </TD>
- <TD>
- Table
- 5, rows “l or L” and “ll or LL”
- </TD>
- <TD>
- te
- </TD>
- <TD>
- The
- final entry in the last column (“unsigned long int”)
- is incorrect.
- </TD>
- <TD>
- Replace
- the incorrect entries by “unsigned long long int”.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 20
- </TD>
- <TD>
- 2.13.1,
- 2.13.3
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- Long
- strings of digits in literals are a continuing problem in the
- production and maintenance of programs.
- </TD>
- <TD>
- 
- Adopt
- the 1983 technology of Ada and use underscores to separate digits.
- http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2281.html
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- UK 
- 
- 15
- </TD>
- <TD>
- 2.13.2
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Inconsistency
- between definition of a multicharacter literal and a wide
- character literal containing multiple c-chars.
- </TD>
- <TD>
- Define
- the term multicharacter wide literal for a wchar_t literal
- containing multiple elements, and specify its type is integer (or
- wider)
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- UK 
- 
- 16
- </TD>
- <TD>
- 2.13.2
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Not
- immediately clear why the question mark needs escaping. A note
- would help.
- </TD>
- <TD>
- Add
- a note explaining that the ? character may need escaping to avoid
- accidentally creating a trigraph.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 2
- </TD>
- <TD>
- 2.13.4
- </TD>
- <TD>
- 
- 1st
- paragraph, 2nd
- line
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- Typo, R"..." should
- be R"[...]"
- </TD>
- <TD>
- Correct
- typo.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 3
- </TD>
- <TD>
- 2.13.4
- </TD>
- <TD>
- 2nd
- paragraph
- </TD>
- <TD>
- te
- </TD>
- <TD>
- We
- think that the explanation of d-char-sequence is not enough.
- </TD>
- <TD>
- 
- Add the following.
- <OL>
- <LI>
- Add the following to the
- explanation of d-char-sequence, more easily to understand.
- </OL>
- 
- ...prefix is a raw string
- literal.
- 
- The d-char-sequence is used as
- delimiter. 
- 
- 
- The terminating
- d-char-sequence of ...
- <OL START=2>
- <LI>
- Add the following note that
- there are square brackets in r-char-sequence.
- </OL>
- 
- [Note:
- 
- char
- foo[] = R”delimiter[[a-z]
- specifies a range which matches any lowercase letter from "a"
- to "z".]delimiter”;
- 
- 
- 
- 
- the expression statement
- behaves exactly the same as
- 
- 
- 
- 
- char foo[]="[a-z]
- specifies a range which matches any lowercase letter from \"a\"
- to \"z\".";
- 
- - end note]
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 4
- </TD>
- <TD>
- 2.13.4
- </TD>
- <TD>
- 3rd
- paragraph, 1st line of example
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- Typo. Lack of a necessary
- backslash in the first line of the example as follows:
- 
- 
- 
- 
- const char *p = R"[a
- 
- b
- 
- c]";
- 
- 
- 
- 
- should be
- 
- 
- 
- 
- const char *p = R"[a\
- 
- b
- c]";
- </TD>
- <TD>
- Correct
- typo.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 21
- </TD>
- <TD>
- 2.13.4
- </TD>
- <TD>
- ¶
- 3
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- The
- paragraph, marked as a Note, contains an embedded example not
- marked as such.
- </TD>
- <TD>
- Denote
- the code (and perhaps also its commentary) as an Example.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 22
- </TD>
- <TD>
- 2.13.4
- </TD>
- <TD>
- ¶
- 3
- </TD>
- <TD>
- te
- </TD>
- <TD>
- The
- code does not have the effect predicted by its accompanying
- narrative.
- </TD>
- <TD>
- Append
- a backslash to the first line of the code.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 5
- </TD>
- <TD>
- 2.13.4
- </TD>
- <TD>
- 
- 11th
- paragraph, Table 7
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- It
- is not explicit how to combine raw-string and non-raw-string.
- </TD>
- <TD>
- Add
- rules containing raw-string in the table 7.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 13
- </TD>
- <TD>
- 2.13.4
- [lex.string]
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- Shouldn't
- the assert be
- assert(std::strcmp(p,
- "a\nb\nc") == 0);
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- UK 
- 
- 17
- </TD>
- <TD>
- 2.13.4
- </TD>
- <TD>
- 10
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- It
- would be preferred for attempts to modify string literals to be
- diagnosable errors. This is not possible due to the deprecated
- implicit conversion to pointer to null-terminated character
- sequence of non-const characters. If this deprecated conversion
- were remove (see other comments) then string literals are always
- accessed through const types, and the compiler can enforce the no
- modification rule. The only exception would be using const_cast to
- cast away constness, but this is already covered under the
- const_cast rules so needs no further detail here.
- 
- 
- </TD>
- <TD>
- (asssuming
- deprecated conversion to non-const array is removed or can be
- turned off) Strike the sentence on undefined behaviour.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- UK 
- 
- 18
- </TD>
- <TD>
- 2.13.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- addition of static_assert (7p4) to the language raises the need to
- concatenate string representations of integral constant
- expressions (typically from a sizeof or alignof expression) with
- narrow string literals to provide an informative error message.
- There is no need to support arbitrary constant expressions and
- especially not floating point values or formatting flags.
- Likewise, the need is purely to support static_assert so only
- narrow string literal support is required, although generalizing
- to other literal types would be useful.
- 
- 
- </TD>
- <TD>
- Define
- a syntax to support string-ization of integral constant
- expressions in a form eligible for string literal concatenation,
- 2.13.4p6. Suggested syntax: I" integral-constant-expression
- ". There is no raw variant, although it could combine with
- type specifier in the same way that the R prefix does, supporting
- u8I, uI, UI and LI.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- UK 
- 
- 19
- </TD>
- <TD>
- 2.13.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- grammar for string literal is becoming unwieldy and could easily
- be refactored into the type optional specifier and the string
- contents.
- </TD>
- <TD>
- Refactor
- string-literal grammar as: (note - current Drupal view loses
- formatting which is vital to clearly read the grammar)
- string-literal: string-literal-type-specifierOPT
- string-literal-body string-literal-type-specifier: one of u8 u U L
- string-literal-body: " s-char-sequenceOPT " R raw-string
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 14
- </TD>
- <TD>
- 3
- [basic]
- </TD>
- <TD>
- 7
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- "In
- general it is necessary to determine whether a name denotes one of
- these entities before parsing the program that contains it."
- </TD>
- <TD>
- 
- Would
- prefer
- 
- "...
- before continuing to parse the program that contains it."
- or
- even 
- 
- 
- "...
- to complete the parsing of the program that contains it."
- as
- some names denotes entities declared after the first occurrence.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 15
- </TD>
- <TD>
- 3
- [basic]
- </TD>
- <TD>
- 8
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- /operator-function-id/,
- /conversion-function-id/, /template-id/ are followed by a space
- and then a "s" while usually such production names
- aren't followed by a space when put in plural (see /identifier/).
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- UK
- 20
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ge
- </TD>
- <TD>
- Chapter
- 3 ("Basic concepts") provides common definitions used in
- the rest of the document. Now that we have concepts as a primary
- feature, the title of this chapter can be confusing as it does not
- refer to the language feature but to definitions used in the
- document.
- 
- 
- </TD>
- <TD>
- Change
- the title to "Basic definitions".
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- UK 
- 
- 21
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Concepts
- is now the name of a specific feature of the language, the term
- now risks confusion and ambiguity when used in the more general
- sense.
- </TD>
- <TD>
- Rename
- the chapter Basic ???. THe note in p2 specifically needs similar
- rewording
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- UK 
- 
- 22
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- 6
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- References
- are frequently considered variables, but this definition only
- applies to objects.
- 
- 
- </TD>
- <TD>
- Add
- "or reference" after both uses of "object"
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- UK 
- 
- 23
- </TD>
- <TD>
- 3.1
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- alias-declarations
- are not definitions and should be added to the list
- 
- 
- </TD>
- <TD>
- Add
- alias-declaration after typedef declaration.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- UK 
- 
- 24
- </TD>
- <TD>
- 3.1
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- current words suggest the declaration of a static integral
- constant data member of a class cannot be a definition. Trying to
- fix this wording in-place will be verbose and risk raising more
- confusion than it solves, so suggest a footnote to call out the
- special case
- 
- 
- </TD>
- <TD>
- Add
- a footnote attached to the static data membmer rule: *static data
- member delcarations of intergral type may also be definitions if a
- constant integral expression is provided for an initializer.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- UK 
- 
- 25
- </TD>
- <TD>
- 3.1
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Example
- is misleading as implicitly defined default constructor uses
- default initialization, not value initialization, for non-static
- data members. In the case of std::String this makes no difference,
- but it makes a big difference for fundamental types and pointers.
- 
- 
- </TD>
- <TD>
- Remove
- the : s() from the illustrated default constructor: struct C {
- std::string s; C() { } C(const C& x): s(x.s) { } C&
- operator=(const C& x) { s = x.s; return *this; } ~C() { } };
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- UK 
- 
- 26
- </TD>
- <TD>
- 3.2
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- THe
- one definition rule should cover references, and unless the term
- 'variable' is extended to cover references the list in this
- paragraph is incomplete.
- 
- 
- </TD>
- <TD>
- Either
- include references in the definition of 'variable' (see earlier
- comment) or add reference to the list in this paragraph.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- UK 
- 
- 27
- </TD>
- <TD>
- 3.2
- </TD>
- <TD>
- 4
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- A
- class type must be complete when catching exceptions, even by
- reference or pointer. See 15.3.
- 
- 
- </TD>
- <TD>
- Add
- "when used in an exception-handler (15.3)" to the list.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 16
- </TD>
- <TD>
- 3.3
- [Declarative regions and scopes.]
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- The
- scope of function parameters is defined, but what is the scope of
- template parameters?
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- UK
- 28
- </TD>
- <TD>
- 3.3.1
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Class
- templates are not classes, so we should include this case.
- 
- 
- </TD>
- <TD>
- ammend
- "class" to "class or class template"
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- UK
- 29
- </TD>
- <TD>
- 3.3.10
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- operators
- and conversion functions do not have names, yet are susceptible to
- 'name hiding' within a class - indeed we rely on this for the
- implicitly declared copy-assignment operator.
- </TD>
- <TD>
- Add
- the additional phrase "The declaration of an operator or
- conversion function in a derived class (Clause 10) hides the
- declaration of an operator or conversion function of a base class
- of the same operator or type;"
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 17
- </TD>
- <TD>
- 3.5
- [Program and linkage]
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- This
- section does not specify whether concept names have linkage.
- 
- Do
- they or not? If concept names do not have linkage, then a note is
- appropriate, and that would be a bit surprising and curious. What
- is the rationale?
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 30
- </TD>
- <TD>
- 3.5
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- This
- paragraph implies concepts have no linkage (do they need it?) and
- that the entities behind names without linkage cannot be used in
- other scopes. This maybe a bigger problem for concept maps?
- </TD>
- <TD>
- Add
- a note to clarify that concepts don't need linkage.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 31
- </TD>
- <TD>
- 3.5
- </TD>
- <TD>
- 4
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- What
- is the linkage of names declared inside a namespace, in turn
- declared inside an anonymous namespace? It is not clear why such a
- namespace has no linkage, and there is no language suggesting its
- memmbers should lose linkage with it, which we assume is the
- intended consequence.
- </TD>
- <TD>
- Clarify
- rules for namespaces inside nested namespaces, or remove the
- restriction.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 23
- </TD>
- <TD>
- 3.5
- </TD>
- <TD>
- 6
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- Bad paragraph break.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 18
- </TD>
- <TD>
- 3.5
- [basic.link]
- </TD>
- <TD>
- 6
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- The
- paragraph number is not aligned with the text.
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 19
- </TD>
- <TD>
- 3.6
- [Start and termination]
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- This
- section completely ignores the real world and practical case of
- dynamically linked or loaded libraries. In current computing
- environments, they are ubiquitous and they cannot be ignored in
- 
- practical
- C++ programs. The Standard
- 
- should
- address this aspect.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 32
- </TD>
- <TD>
- 3.6.1
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Do
- we really want to allow: constexpr int main() { return 0; } as a
- valid program?
- </TD>
- <TD>
- Add
- constexpr to the list of ill-formed things to annotate main
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 24
- </TD>
- <TD>
- 3.6.1
- </TD>
- <TD>
- 4
- </TD>
- <TD>
- te
- </TD>
- <TD>
- std::quick_exit
- is not referenced.
- </TD>
- <TD>
- 
- Reference
- std::quick_exit as well as std::exit in saying that automatic
- objects are not destroyed. It should not
- do so in saying that calling std::quick_exit is undefined from
- within destructors for static or thread duration objects.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 25
- </TD>
- <TD>
- 3.6.3
- </TD>
- <TD>
- ¶
- 2 last sent.
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- The
- parenthesized phrase, introduced via “i.e.” is in the
- nature of an example.
- </TD>
- <TD>
- Change
- “i.e.” to “e.g.”
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 6
- </TD>
- <TD>
- 3.7.4.1
- </TD>
- <TD>
- 4th
- paragraph, 4th
- line
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- Typo.
- 
- Lack of a comma right after
- “(3.7.2)” in the sentence while there are commas after
- any other recitations like “(3.7.1)”. It is just a
- unification matter.
- 
- 
- 
- 
- [ Note: in particular, a
- global allocation function is not called to allocate storage for
- objects with static storage duration (3.7.1), for objects or
- references with thread storage duration (3.7.2) for objects of
- type std::type_info (5.2.8), or for the copy of an object thrown
- by a throw expression (15.1). -end note ]
- 
- 
- 
- 
- should be
- 
- 
- 
- 
- [ Note: in particular, a
- global allocation function is not called to allocate storage for
- objects with static storage duration (3.7.1), for objects or
- references with thread storage duration (3.7.2), for objects of
- type std::type_info (5.2.8), or for the copy of an object thrown
- by a throw expression (15.1). -end note ]
- 
- 
- </TD>
- <TD>
- Correct
- typo.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- DE-3
- </TD>
- <TD>
- 3.7.4.3
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- DE-3
- It is unclear whether the following code has well-defined
- behavior; none of the bullets in the second paragraph seem to
- apply.
- 
- int&
- i = *new int(5);
- 
- delete
- &i;
- </TD>
- <TD>
- Clarify
- that &i is considered a safely-derived pointer value.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 26
- </TD>
- <TD>
- 3.8
- </TD>
- <TD>
- 1
- and 5
- </TD>
- <TD>
- te
- </TD>
- <TD>
- Use
- of object fields during destruction is excessively and erroneously
- constrained.
- </TD>
- <TD>
- 
- See the attached document
- "Issues with the C++ Standard" under Chapter 3 "Use
- of objects, especially from other threads, during destruction".
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 27
- </TD>
- <TD>
- 3.9
- </TD>
- <TD>
- ¶
- 9 first sent.
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- There
- is a superfluous/extraneous “and”.
- </TD>
- <TD>
- Delete
- “and” from the phrase “and std::nullptr_t”.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 20
- </TD>
- <TD>
- 3.9
- [Types]
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- The
- phrase 'effective type' is defined and used in a way that is
- incompatible with C99. Such a deliberate incompatible choice of
- terminology is both unfortunate and confusing, given past practice
- of the committee to maintain greater compatibility with C99. We
- strongly suggest that the phrase 'effective type' not be used in
- such an incompatible way.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 7
- </TD>
- <TD>
- 3.9.2
- </TD>
- <TD>
- 3rd
- paragraph, 13th
- line
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- over-aligned
- type was added as new notion. So it is preferable to add the link
- after that.
- </TD>
- <TD>
- 
- Add (3.11) after over-aligned
- type as the link.
- [
- Note: pointers to over-aligned types(3.11)
- have no special representation, but their range of valid values is
- restricted by the extended alignment requirement. This
- International Standard specifies only two ways of obtaining such a
- pointer: taking the address of a valid object with an over-aligned
- type(3.11),
- and using one of the runtime pointer alignment functions. An
- implementation may provide other means of obtaining a valid
- pointer value for an over-aligned type(3.11).—end
- note ]
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 28
- </TD>
- <TD>
- 3.9.3
- </TD>
- <TD>
- ¶
- 5 first sent.
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- The
- closing braces of the first two sets are preceded by extraneous
- space.
- 
- 
- </TD>
- <TD>
- Delete
- the extra spaces.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- DE
- 4
- </TD>
- <TD>
- 4.2
- </TD>
- <TD>
- p2
- </TD>
- <TD>
- te
- </TD>
- <TD>
- DE-4
- The deprecated conversion from string literals to pointer to
- non-const character types should be limited to those conversions
- and types of string literals that were already present in ISO/IEC
- 14882:2003, or the deprecated conversions should be removed
- entirely.
- </TD>
- <TD>
- Consider
- applying the proposed resolution presented in core issue 693 in
- WG21 document N2714 “C++ Standard Core Language Active
- Issues, Revision 58“, available at
- http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2714.html
- ; or remove only the conversions to "pointer to char16_t",
- "pointer to char32_t" in 4.2 paragraph 2 and 15.1
- paragraph 3.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- CH
- 1
- </TD>
- <TD>
- 4.9
- and 5.2.9
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- With
- respect to the target type, pointer to members should behave like
- normal pointers (least surprise principle).
- </TD>
- <TD>
- The
- standard should allow implicit conversions from ``pointer to
- member of <TT>T</TT> of type
- cv <TT>D</TT>'' to
- ``pointer to member of <TT>T</TT>
- of type cv B'', where D is of class type and B is a public
- base of D, It should allow explicit conversion the other way
- around.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- DE-5
- </TD>
- <TD>
- 4.11,
- 5.3.1, 5.5
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- DE-5
- Ref-qualification has not been integrated with pointer-to-members.
- </TD>
- <TD>
- Review
- implicit conversions (4.11), forming pointer-to-members (5.3.1),
- and dereferencing pointer-to-members (5.5) for type-safety
- concerns in the presence of ref-qualifiers on the member.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 33
- </TD>
- <TD>
- 4.13
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- We
- have: "No two signed integer types shall have the same rank
- ..." "the rank of char shall equal the rank of signed
- char" Can we therefore deduce that char may not be signed?
- </TD>
- <TD>
- Replace
- the first sentence with "No two signed integer types shall
- have the same rank, even if they have the same representation,
- except that signed char shall have the same rank as char even if
- char is signed (3.9.1/1)."
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 34
- </TD>
- <TD>
- 4.13
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- 6th
- bullet, "the rank of char" - first letter should be
- capitalised for consistency with the other bullets
- 
- 
- </TD>
- <TD>
- The
- rank of char
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 36
- </TD>
- <TD>
- 5.1
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Primary
- expressions are literals, names, names qualified by the scope
- resolution operator ::, and lambda expressions. The immediately
- following grammar flatly contradicts this - this and (e) are also
- lambda expressions.
- 
- 
- </TD>
- <TD>
- Delete
- this paragraph.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 37
- </TD>
- <TD>
- 5.1
- </TD>
- <TD>
- 11
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Member
- function templates are not member functions, so should also be
- listed in the 3rd bullet
- 
- 
- </TD>
- <TD>
- Add
- member function templates to the 3rd bullet
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 38
- </TD>
- <TD>
- 5.1
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- this
- might be useful in a few more places than it is permitted,
- specifically in decltype expressions within a class. Two examples
- that would be ill-formed at class scope without changes: typedef
- decltype( *this ) this_type; decltype( [this]{ return
- this->memfun(); } ) my_lambda;
- </TD>
- <TD>
- ...
- words to follow ...
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 8
- </TD>
- <TD>
- 5.1
- </TD>
- <TD>
- 7th
- paragraph, Syntax rules
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- In the current syntax
- definition, a scope operator(::) cannot be applied to decltype,
- but it should be. It would be useful in the case to obtain member
- type(nested-type) from an instance as follows:
- 
- vector<int> v;
- decltype(v)::value_type
- i = 0; // int i = 0;
- </TD>
- <TD>
- 
- Add “decltype (
- expression ) :: “ to nested-name-specifier syntax like
- below.
- 
- 
- 
- 
- nested-name-specifier:
- 
- type-name ::
- 
- namespace-name ::
- 
- nested-name-specifier
- identifier ::
- 
- nested-name-specifier
- templateopt simple-template-id ::
- 
- nested-name-specifieropt
- concept-id ::
- 
- decltype ( expression ) ::
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 9
- </TD>
- <TD>
- 5.1.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- It would be preferable that
- “&&” could be specified in a lambda expression
- to declare move capture.
- 
- 
- 
- 
- Here is an example from N2709.
- 
- 
- 
- 
- template<typename F>
- 
- std::unique_future<typename
- std::result_of<F()>::type> spawn_task(F f){
- 
- typedef typename
- std::result_of<F()>::type result_type;
- 
- 
- 
- 
- struct local_task {
- 
- std::promise<result_type>
- promise;
- 
- F func;
- 
- local_task(local_task const&
- other)=delete;
- 
- local_task(F func_):
- 
- func(func_)
- 
- {}
- 
- 
- 
- 
- local_task(local_task&&
- other):
- 
- promise(std::move(other.promise)),
- 
- f(std::move(other.f))
- 
- {}
- 
- 
- 
- 
- void operator() {
- 
- try
- 
- {
- 
- promise.set_value(f());
- 
- }
- 
- catch(...)
- 
- {
- 
- promise.set_exception(std::current_exception());
- 
- }
- 
- }
- 
- };
- 
- 
- 
- 
- local_task task(std::move(f));
- 
- 
- 
- 
- std::unique_future<result_type>
- res(task.promise.get_future());
- 
- std::thread(std::move(task));
- 
- return res;
- 
- }
- 
- 
- 
- 
- This can be rewritten simply
- as follows if move capture can be used in a lambda expression.
- 
- 
- 
- 
- template<typename F>
- 
- std::unique_future<typename
- std::result_of<F()>::type> spawn_task(F f){
- 
- typedef typename
- std::result_of<F()>::type result_type;
- 
- 
- 
- 
- std::promise<result_type>
- promise;
- 
- std::unique_future<result_type>
- res(promise.get_future());
- 
- std::thread([&&promise,
- &&f]() {
- 
- try
- 
- {
- 
- promise.set_value(f());
- 
- }
- 
- catch(...)
- 
- {
- 
- promise.set_exception(std::current_exception());
- 
- }
- 
- });
- 
- return res;
- 
- }
- 
- 
- </TD>
- <TD>
- 
- Add move capture in a lambda
- expression.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 10
- </TD>
- <TD>
- 5.1.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- In the current syntax
- definition, a returned type of a function object cannot be
- obtained by using result_of from an unnamed function object
- generated by a lambda expression because it doesn’t have
- result type.
- 
- 
- 
- 
- template <class F>
- 
- void foo(F f)
- 
- {
- 
- typedef
- std::result_of<F()>::type result; // error
- 
- }
- 
- foo([]{});
- 
- 
- 
- 
- If “Callable” or
- “Predicate” concept is specified, a returned type can
- be obtained from a function object without result_type. But it is
- preferable to be able to obtain it with template.
- 
- 
- 
- </TD>
- <TD>
- 
- Add result_type to the syntax
- of an unnamed function object generated by a lambda expression.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 29
- </TD>
- <TD>
- 5.1.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- The standard does not state
- whether or not direct recursion of lambdas is possible.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 30
- </TD>
- <TD>
- 5.1.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- 
- The
- standard does not clarify the meaning of <CODE>
- this</CODE>
- in lambdas. Does it mean this lambda, or this class within which
- the lambda is nested?
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 31
- </TD>
- <TD>
- 5.1.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- 
- The
- current wording does not specify how context capturing and name
- resolution take
- place when the inner lambda refers to the outer lambda's locals
- variables and parameters.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 45
- </TD>
- <TD>
- 5.1.1
- </TD>
- <TD>
- para
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Lambda
- is a language feature with an apparent dependency on <functional>.
- This increases dependency of language on library, and is
- inconsistent with the definition of freestanding in 17.6.2.4.
- </TD>
- <TD>
- Change
- the text "a closure object behaves as a function object"
- to "a closure object is a built-in object which behaves as a
- function object"; and after "context.", insert "
- A closure object may be used without any need for <functional>."
- This makes clear what may already be implied, namely that lambdas
- can be used in freestanding implementations and don't increase
- dependency of language on library. (Marked as technical comment
- anyway because this clarity is technically important).
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- US 32
- 
- 
- </TD>
- <TD>
- 5.1.1
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- The final italic "this"
- in the paragraph should be a teletype "this".
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 39
- </TD>
- <TD>
- 5.1.1
- </TD>
- <TD>
- 11
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- This
- paragraph lists all the special member functions for the class
- representing a lambda. But it omits the destructor, which is
- awkward.
- </TD>
- <TD>
- Add
- "F has an implicitly-declared destructor".
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 40
- </TD>
- <TD>
- 5.1.1
- </TD>
- <TD>
- 12
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- If
- one or more names in the effective capture set are preceded by &,
- the effect of invoking a closure object or a copy after the
- innermost block scope of the context of the lambda expression has
- been exited is undefined. That is too restrictive. The behaviour
- should be undefined iff the lifetime of any of the variables
- referenced has ended. This should be safe and legal; currently it
- has undefined behaviour: int i; reference_closure<void ()>
- f; if (blah) { f = [&i]() { }; } if (f) f();
- 
- 
- </TD>
- <TD>
- If
- one or more names in the effective capture set are preceded by &,
- the effect of invoking a closure object or a copy after the
- lifetime of any of the variables referenced has ended is
- undefined.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 41
- </TD>
- <TD>
- 5.1.1
- </TD>
- <TD>
- 12
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- For
- argument dependant lookup (3.4.2) the associated namespaces for a
- class include its bases, and associated namespaces of its bases.
- Requiring the result of a lambda expression *to dervide from*
- std::reference_closure means that ADL will look in namespace std
- when the lambda capture is entirely by reference, which might have
- surprising results. Also, relying on the idea of implicitly
- slicing objects is uncomfortable.
- </TD>
- <TD>
- Replace
- inheritance with implicit conversion.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 42
- </TD>
- <TD>
- 5.1.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- A
- lambda with an empty capture list has identical semantics to a
- regular function type. By requiring this mapping we get an
- efficient lambda type with a known API that is also compatible
- with existing operating system and C library functions.
- </TD>
- <TD>
- Add
- a new paragraph: "A lambda expression with an empty capture
- set shall be convertible to pointer to function type R(P), where R
- is the return type and P is the parameter-type-list of the lambda
- expression." Additionally it might be good to (a) allow
- conversion to function reference (b) allow extern "C"
- function pointer types
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 43
- </TD>
- <TD>
- 5.1.1
- </TD>
- <TD>
- 12
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- note spells out the intent that objects from lambda-expressions
- with an effective capture list of references should be implemented
- as a pair of pointers. However, nothing in the rest of 5.1.1 lifts
- the requirement of to declare a reference member for each captured
- name, and a non-normative note is not enough to relax that.
- 
- 
- </TD>
- <TD>
- ...
- provvide exceptions in the right places ...
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 44
- </TD>
- <TD>
- 5.1.1
- </TD>
- <TD>
- 12
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- There
- is a strong similarity between a [&]{} lambda capturing a
- stack frame, and a [this]{} lambda binding a member function to a
- class instance. The reference_closure requirement should be
- extended to the second case, although we need some syntax to
- create such an object that is distinct from the existing
- pointer-to-member syntax. This would be a cleaner alternative to
- the new std::mem_fn library component.
- 
- 
- </TD>
- <TD>
- Extend
- reference_closure requirement to cover [this] lambdas. Consider a
- simple syntax for creating such bound expressions.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 46
- </TD>
- <TD>
- 5.1.1
- </TD>
- <TD>
- para
- 12
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- requirement that a lambda meeting appropriate conditions be an
- object derived from reference_closure makes lambda the language
- feature dependent on <functional>, which increases
- dependency of the language on the library and bloats the
- definition of freestanding C++.
- </TD>
- <TD>
- Replace
- text "is publicly derived from" with "shall be
- implemented in a manner indistinguishable from". This places
- an ABI constraint on reference closures such that compiler and
- library implementer have to do compatible things. But it cuts the
- dependency of lambda syntax on <functional>.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- DE-6
- </TD>
- <TD>
- 5.1.1,
- 20.7.18
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- DE-6
- Some uses of lambda expressions refer to specializations of the
- unconstrained class template std::reference_closure
- (5.1.1). If the lambda expression appears in a constrained context
- and the return type or a parameter type for the lambda depend on a
- template parameter (see 14.10), such a use is ill-formed.
- </TD>
- <TD>
- In
- 20.7.18, for the class template std::reference_closure,
- require Returnable
- for R
- and VariableType
- for each of the ArgTypes.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- DE-7
- </TD>
- <TD>
- 5.1.1
- </TD>
- <TD>
- p10
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- DE-7
- The note at the end of paragraph 10 appears to be garbled.
- </TD>
- <TD>
- Remove
- "or references" in the note.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- DE-8
- </TD>
- <TD>
- 5.1.1
- </TD>
- <TD>
- p10
- </TD>
- <TD>
- te
- </TD>
- <TD>
- DE-8
- The construction of the function call operator signature is
- missing specifications for the ref-qualifier and the
- attribute-specifier.
- </TD>
- <TD>
- Add
- bullets that say that the ref-qualifier and the
- attribute-specifier are absent.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 33
- </TD>
- <TD>
- 5.1.1
- </TD>
- <TD>
- 11
- </TD>
- <TD>
- Ge
- </TD>
- <TD>
- There is no
- definition of “move constructor” or “move
- operation”
- </TD>
- <TD>
- Since
- this is the first place the terms are used, a definition should
- either be added here, or a cross reference to one.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- DE-9
- </TD>
- <TD>
- 5.1.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- DE-9
- There is not a single example of a lambda-expression in the
- standard. See also core issue 720 in WG21 document N2791 "C++
- Standard Core Language Active Issues, Revision 59", available
- at
- http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2791.html
- .
- </TD>
- <TD>
- Add
- a few well-chosen examples.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 52
- </TD>
- <TD>
- 5.2
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- This
- paragraph seens out of place, assignment expressions are covered
- in 5.17
- </TD>
- <TD>
- Move
- p3 to subsection 5.17
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 53
- </TD>
- <TD>
- 5.2.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- definition in p1 makes no allowance for overloaded operator[] that
- treats the expression as a simple function call, and does not
- support the interchangability of arguments. Howver p2 relies on
- this definition when describing the use of brace-init-lists inside
- [].
- </TD>
- <TD>
- Insert
- a new p2 describing the changed semantics for overloaded
- operator[]. This should be a note to avoid introducing normative
- text that could potentially conflict with the later definiton of
- these semantics.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 59
- </TD>
- <TD>
- 5.2.2
- </TD>
- <TD>
- 7
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- When
- there is no parameter for a given argument, the argument is passed
- in such a way that the receiving function can obtain the value of
- the argument by invoking va_arg. That shouldn't apply to parameter
- packs. template <class ... Types> void f(Types ... pack);
- f(1, 2, 3);
- </TD>
- <TD>
- Clarify
- that this sentence only applies where the ellipsis is used.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 60
- </TD>
- <TD>
- 5.2.5
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- In
- the remainder of 5.2.5, cq represents either const or the absence
- of const vq represents either volatile or the absence of volatile.
- </TD>
- <TD>
- Add
- "and" before vq
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 61
- </TD>
- <TD>
- 5.2.5
- </TD>
- <TD>
- p1
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Together
- with footnote 60 there may be confusion that the postfix
- expression is always evaluated - even when part of an unevaluated
- operand. We believe the standard does not require this, and a
- comment in the existing note would be a useful clarification.
- </TD>
- <TD>
- Clarify
- in footnote 60 that this will not happen if the whole expression
- is an unevaluated operand.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 62
- </TD>
- <TD>
- 5.2.5
- </TD>
- <TD>
- 4
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- In
- the final bullet, what does 'not an lvalue' mean? Does it imply
- rvalue, or are there other possible meanings? Should clauses that
- trigger on rvalues pick up on this?
- </TD>
- <TD>
- Replace
- 'not an lvalue' with 'is an rvalue'.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- DE-10
- </TD>
- <TD>
- 5.2.5
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- DE-10
- If E1.E2 is referring to a non-static member function, the
- potential ref-qualification on E2 should be taken into account.
- </TD>
- <TD>
- Adjust
- the presentation of the types involved as appropriate.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 63
- </TD>
- <TD>
- 5.2.6
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Paragraph
- 2 is missing its number.
- </TD>
- <TD>
- Add
- one.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 64
- </TD>
- <TD>
- 5.2.7
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- A
- new name R is introduced for use in paragraphs 3 and 4. But R is
- the same as T.
- </TD>
- <TD>
- Replace
- R with T and replace "the required result type (which, for
- convenience, will be called R in this description)" with "T".
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 65
- </TD>
- <TD>
- 5.2.7
- </TD>
- <TD>
- 8
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- In
- the first two bullets we have "the result is a pointer (an
- lvalue referring) to". But para 2 makes clear that a
- dynamic_cast of an rvalue references produces a rvalue. (Can an
- lvalue refer to anything anyway?)
- 
- 
- </TD>
- <TD>
- Replace
- "an lvalue referring to" with "reference",
- twice.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 66
- </TD>
- <TD>
- 5.2.8
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- typeid
- may return "an implementation-defined class derived from std
- :: type_info". The derivation must be public.
- 
- 
- </TD>
- <TD>
- an
- implementation-defined class publicly derived from std ::
- type_info
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 67
- </TD>
- <TD>
- 5.2.9
- </TD>
- <TD>
- 1,
- 2, 3
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Paragraph
- 1 specifies when the result of static_cast is an lvalue; repeating
- it is unnecessary.
- </TD>
- <TD>
- In
- para 2, delete "It is an lvalue if the type cast to is an
- lvalue reference; otherwise, it is an rvalue." and "The
- result is an rvalue.". In para 3, delete "The result is
- an lvalue if T is an lvalue reference type (8.3.2), and an rvalue
- otherwise."
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 54
- </TD>
- <TD>
- 5.2.10
- </TD>
- <TD>
- 3,
- 6
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Para
- 3: "The mapping performed by reinterpret_cast is
- implementation-defined.". Para 6: "... the result of
- such a pointer conversion is unspecified." Which is it?
- </TD>
- <TD>
- In
- para 6, replace unspecified with implementation-defined.
- Alternatively, delete paragraph 3, since individual cases are
- labelled appropriately.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 55
- </TD>
- <TD>
- 5.2.10
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- dynamic_cast
- and reinterpret_cast crossreference 5.2.11 without creating an
- extra note. The second half of the note is unrelated to the
- crossrefernce, and would serve as well in normative text.
- </TD>
- <TD>
- Strike
- the note about definition of casting away constness, preserve the
- cross-reference. The second sentance on reintrepret_cast to its
- own type should move out of the note into the normative text.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 56
- </TD>
- <TD>
- 5.2.10
- </TD>
- <TD>
- 5
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- notion of safely derived pointers means this conversion may not be
- as safe in the revised standard as the original. It would be good
- to call attention to the changed semantics with a note.
- 
- 
- </TD>
- <TD>
- Add:
- [Note: the result of such a conversion will not be a
- safely-derived pointer value (3.7.4.3) -- end note]
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 57
- </TD>
- <TD>
- 5.2.10
- </TD>
- <TD>
- 8
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Conditionally
- supported behaviour gives a wide range or permission, so clarify
- relationship between safely-derived object pointers and function
- pointers in a note.
- </TD>
- <TD>
- Add:
- [Note: In such cases, the implementation shall also define whether
- a safely-derived object pointer cast to a function pointer can be
- safely cast back -- end note]
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 58
- </TD>
- <TD>
- 5.2.11
- </TD>
- <TD>
- 9
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Casting
- from an lvalue of type T1 to an lvalue of type T2 using a
- reference cast casts away constness if a cast from an rvalue of
- type “pointer to T1” to the type “pointer to T2”
- casts away constness. That doesn't cover rvalue references.
- 
- 
- </TD>
- <TD>
- Replace
- lvalue with "lvalue or rvalue" twice.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- US 34
- 
- 
- </TD>
- <TD>
- 5.3
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- The
- list of unary operator should be in teletype font.
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 68
- </TD>
- <TD>
- 5.3.1
- </TD>
- <TD>
- 2-9
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- All
- the unary operands other than * return rvalues - but this is not
- stated.
- </TD>
- <TD>
- Add
- a paragraph 1a "The following unary operators all produce
- results that are rvalues."
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 69
- </TD>
- <TD>
- 5.3.1
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- If
- we cannot bind references/take address of functions in
- concept_maps, does that mean we cannot use generic bind in
- constrained templates? Launch threads with expressions found via
- concept map lookup? Hit problems creating std::function objects?
- Does the problem only occur if we use qualified lookup to
- explicitly name a concept map? Does it only kick in if we rely on
- the implicit function implementation provided by a concept_map, so
- some types will work and others won't for the same algorithm?!
- 
- 
- </TD>
- <TD>
- ...
- unknown ...
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 70
- </TD>
- <TD>
- 5.3.3
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- sizeof operator shall not be applied to ... an enumeration type
- before all its enumerators have been declared We should allow enum
- E : int; sizeof(E).
- 
- 
- </TD>
- <TD>
- Change
- "an enumeration type" to "an enumeration type whose
- underlying type is not fixed".
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 71
- </TD>
- <TD>
- 5.3.4
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- type of an allocated object wih the type specifier auto is
- determined by the rules of copy initialization, but the
- initialization applied will be direct initialization. This would
- affect classes which declare their copy constructor explicit, for
- instance. For consistency, use the same form of initiailization
- for the deduction as the new expression.
- </TD>
- <TD>
- Replace
- T x = e; with T x(e);
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 72
- </TD>
- <TD>
- 5.3.4
- </TD>
- <TD>
- 7
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- library headers have been carefully structured to limit the
- dependencies between core language and specific headers. The
- exception thrown should be catchable by a handler for a type lised
- in <exception> header in cluase 18. This might be
- accomplished by moving length_error into the <exception>
- header, but its dependency on logic_error with its std::string
- constructors suggest this is not a good idea. Prefer to pick an
- existing exception instead.
- 
- 
- </TD>
- <TD>
- Throw
- std::bad_alloc instead of std::length_error.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 73
- </TD>
- <TD>
- 5.3.4
- </TD>
- <TD>
- 6
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- A
- class type with conversion operator can only be used if the
- conversion type is constexpr and the class is a literal type.
- Adding the single word 'literal' before class type will clarify
- this.
- 
- 
- </TD>
- <TD>
- Add
- 'literal' before 'class type'
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 74
- </TD>
- <TD>
- 5.3.4
- </TD>
- <TD>
- 8
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- operators,
- like constructors and destructors, do not have names. However, in
- certain circumstances they can be treated as if they had a name,
- but usually the stanadard is very clear not to actually describe
- their name as a distinct property.
- 
- 
- </TD>
- <TD>
- Change
- "the allocation function’s name is operator new"
- to "the allocation function is named operator new" and
- similarly for operator delete.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 35
- </TD>
- <TD>
- 5.3.4
- </TD>
- <TD>
- 9
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Missing
- period in middle of paragraph between "in the scope of T"
- and "If this lookup fails"
- </TD>
- <TD>
- Add
- a period between "in the scope of T" and "If this
- lookup fails"
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 75
- </TD>
- <TD>
- 5.3.5
- </TD>
- <TD>
- 8
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- A
- paragraph strarting with [Note... is easily skipped when reading,
- missing the normative text at the end.
- 
- 
- </TD>
- <TD>
- Swap
- order of the note and normative text.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 21
- </TD>
- <TD>
- 5.3.6
- [Alignof
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- Should
- not the type of alignof-expression be of type std::max_align_t?
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 35
- </TD>
- <TD>
- 5.8
- </TD>
- <TD>
- 2
- and 3
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- There is curious spacing in
- the expressions "E1 <<E2" and "E1 >>E2".
- This is a formatting change since previous versions of the
- Standard.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 47
- </TD>
- <TD>
- 5.14
- / 5.15
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Why
- are the descriptions of order of evaluation of expressions and
- side effects different between && and || operators. The
- interaction with the memory model should be identical, so
- identical words should be used to avoid accidential
- inconsistencies in interpretation.
- 
- 
- </TD>
- <TD>
- Pick
- one form of wording as 'the best' and apply it in both places.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 48
- </TD>
- <TD>
- 5.18
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- defining feature of the comma operator is the guaranteed
- sequencing of two expressions. This guarantee is lost when
- presented with an overloaded operator, and this change is subtle
- enough to call attention to it.
- 
- 
- </TD>
- <TD>
- Add:
- [Note: There are no guarantees on the order of value computation
- for an overloaded comma operator -- end note]
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 49
- </TD>
- <TD>
- 5.19
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Is
- an implementation permitted to reject this? constexpr int f() {
- return f(); } int a[f()]; AFAICT it is well-formed; f() seems to
- satisfy all the rules to make it a constant expression. I would
- hate compilation to become a potentially non-terminating
- experience.
- </TD>
- <TD>
- Add
- an escape clause to allow the implementation to reject excessively
- deep nesting of constexpr function evaluations. (This can possibly
- be a note, since it is arguable that this point is handled by the
- general rule on resource limits in 1.4/2. A sufficiently smart
- compiler could use tail recursion above, meaning that it would
- never run out of memory given this program though.)
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 50
- </TD>
- <TD>
- 5.19
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- following should be valid: enum E { foo = 4}; const E c = foo; int
- a[c]; But currently it is not - c is not an lvalue of effective
- integral type (4th bullet). (See also 7.1.6.1/2)
- </TD>
- <TD>
- Change
- "effective integral type" to "effective integral or
- enumeration type" in the 4th bullet, 1st sub-bullet.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 51
- </TD>
- <TD>
- 5.19
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- typeid
- expressions can never be constant, whether or not the operand is a
- polymorphic class type. The result of the expression is a
- reference, and the typeinfo class that the reference refers to is
- polymorphic, with a virtual destructor - it can never be a literal
- type.
- 
- 
- </TD>
- <TD>
- Strike
- the words "whose operand is of a polymorphic class type"
- on the bullet for typeid expressions.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 76
- </TD>
- <TD>
- 6.3
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Do
- we really need two different terms that say the same thing?
- </TD>
- <TD>
- Pick
- either 'block' or 'compound statement' as the preferred term and
- use it consistently throughout the standard.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 22
- </TD>
- <TD>
- 6.4.2
- [The switch statement]
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- The
- constant-expression in
- 
- 
- 
- case
- constant-expression
- 
- 
- 
- should
- be allowed to be of any constant expression of literal type for
- which a constexpr comparison operator (operator< and
- operator==) is in scope. Now that constant expressions of other
- integral types are evaluated at compile time, the restriction for
- case-labels is at best artificial.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 77
- </TD>
- <TD>
- 6.5
- </TD>
- <TD>
- 5
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- terms i/o operation, synchronize operation and atomic operation
- have very specific meanings within the standard. The paragraph
- would be much easier to understand with the terms crossreferenced.
- 
- 
- </TD>
- <TD>
- Profide
- a cross-reference for the terms: i/o operation, synchronize
- operation and atomic operation 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 11
- </TD>
- <TD>
- 6.5.4
- </TD>
- <TD>
- 1st
- paragraph, 5th
- line
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- There
- is no _RangeT type in the equivalent code to “range-base
- for” statement. It existed in N2049.
- </TD>
- <TD>
- 
- Add a typedef for _RangeT in
- the example as follows:
- 
- 
- 
- 
- {
- 
-     typedef
- decltype( expression ) _RangeT;
- 
-     auto &&
- __range = ( expression );
- 
-     for ( auto
- __begin = std::Range<_RangeT>:: begin(__range),
- 
-            
- __end = std::Range<_RangeT>::
- end(__range);
- 
-           __begin
- != __end;
- 
-           ++__begin
- )
- 
-     {
- 
-         for-range-declaration
- = *__begin;
- 
-         statement
- 
-     }
- 
- }
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 78
- </TD>
- <TD>
- 6.5.4
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Including
- the header <iterator_concepts> is far too unwieldy to enable
- an important and (expected to be) frequently used syntax.
- </TD>
- <TD>
- Merge
- <iterator_concepts> into <concepts> and change 6.5.4p2
- to refer to <concepts>, or make the Range concept
- fundamental along with the other support concepts in 14.9.4 and
- strike any reference to including a header.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 79
- </TD>
- <TD>
- 6.5.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- definition of for (for-range-declaration : expression) statement
- is expanded in terms which require a Range concept, and the
- program is ill-formed if <iterator_concepts> isn't included.
- For users, iterating through old-fashioned arrays, this is a
- sledge-hammer to crack a nut and compares poorly with other
- languages. It's also not possible to implement this without
- adversely impacting the freestanding definition in 17.6.2.4.
- 
- 
- </TD>
- <TD>
- When
- expression is an array a of length N whose length is known at
- compile time, expand range-for as 'for (... p=a, p!=a+N, p++) ...'
- without requiring the Range concept or <iterator_concepts>.
- Also, when expression is an initializer_list, expand range-for
- similarly without requiring <iterator_concepts>.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- DE-11
- </TD>
- <TD>
- 6.9
- </TD>
- <TD>
- p1
- </TD>
- <TD>
- te
- </TD>
- <TD>
- DE-11
- A sentence in paragraph 1 reads: "Outside of a constrained
- context, the late-checked block has no effect." This, at face
- value, specifies that the compound-statement of such a
- late-checked block is never executed, which appears to be
- unintended.
- 
- 
- </TD>
- <TD>
- State
- that such a late-checked block has the same meaning as if the late_check
- keyword were absent.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 80
- </TD>
- <TD>
- 7
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Many
- of the sections and major subsections open with a sentence
- summarising the content. I'm not sure this is necessary; this
- isn't a tutorial. The problem with these summaries is that because
- they omit much of the detail, they tend to be inaccurate. This may
- not matter, but I feel the document would be improved by omitting
- them. There's a prime example here: "Declarations specify how
- names are to be interpreted." Not true for static_assert, an
- asm declaration nor an anonymous bit field.
- 
- 
- </TD>
- <TD>
- Strike
- the first sentence.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 81
- </TD>
- <TD>
- 7
- </TD>
- <TD>
- 4
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- String
- literal concatenation happens in phase 6, before parsing, so it is
- legal and useful to use it for the string literal in a
- static_assert. It would be useful to add a note mentioning this.
- 
- 
- </TD>
- <TD>
- Add
- a note: Multiple adjacent string literals may be used instead of a
- single /string-literal/; see [lex.phases].
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 82
- </TD>
- <TD>
- 7
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Paragraph
- 2 talks about declarations that can have nested declarations
- within them. It doesn't mention scoped enumerations - but
- according to 7.2/11, "Each scoped enumerator is declared in
- the scope of the enumeration."
- 
- 
- </TD>
- <TD>
- Add
- "scoped enumeration" to the list in the second sentence.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 83
- </TD>
- <TD>
- 7.1
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- longest sequence of decl-specifiers that could possibly be a type
- name is taken as the decl-specifier-seq of a declaration. But many
- sequences of decl-specifiers cannot possibly be a type name - eg
- the sequence "friend int", or "typedef int".
- 
- 
- </TD>
- <TD>
- Not
- sure. I understand the rule, just not how to say it.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 84
- </TD>
- <TD>
- 7.1
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- grammar includes alignment-specifier as a production for
- decl-specifier, but there is no production for
- alignment-specifier. I suspect this is a holdover from before
- alignment was handled as an attribute.
- 
- 
- </TD>
- <TD>
- Delete
- the production (including the duplicate in A6)
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FI
- 3
- </TD>
- <TD>
- 7.1
- </TD>
- <TD>
- [dcl.spec.auto]
- </TD>
- <TD>
- te
- </TD>
- <TD>
- While
- it’s considered too late for this standard revision,
- consider loosening the restrictions for auto specifier and making
- it more a mirror of a deduced template function parameter.
- 
- 
- </TD>
- <TD>
- See
- restricted-auto.ppt
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 85
- </TD>
- <TD>
- 7.1.1
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- ...
- the init-declarator-list of the declaration shall not be empty
- (except for global anonymous unions, which shall be declared
- static). Global here means "declared at namespace scope".
- (cf 9.5/3 "Anonymous unions declared in a named namespace or
- in the global namespace shall be declared static.").
- 
- 
- </TD>
- <TD>
- Replace
- "global" with "namespace scope".
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 86
- </TD>
- <TD>
- 7.1.1
- </TD>
- <TD>
- 2,3
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- register keyword serves very little function, offering no more
- than a hint that a note says is typically ignored. It should be
- deprecated in this version of the standard, freeing the reserved
- name up for use in a future standard, much like auto has been
- re-used this time around for being similarly useless.
- 
- 
- </TD>
- <TD>
- Deprecate
- current usage of the register keyword.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 87
- </TD>
- <TD>
- 7.1.1
- </TD>
- <TD>
- 1,
- 4, 5
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Why
- require two keywords, where one on its own becomes ill-formed?
- thread_local should imply 'static' in this case, and the
- combination of keywords should be banned rather than required.
- This would also eliminate the one of two exceptions documented in
- 7.1.1p1.
- 
- 
- </TD>
- <TD>
- Drop
- requirement to combine static keyword with thread_local at
- block-scope inside a function definition.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 36
- </TD>
- <TD>
- 7.1.1
- </TD>
- <TD>
- 4
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- The permission to use
- thread_local static data members is missing.
- 
- 
- </TD>
- <TD>
- Add
- the static members as a permitted use.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 23
- </TD>
- <TD>
- 7.1.5
- [constexpr]
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- 'constexpr'
- functions should be allowed to take const reference parameters, as
- long as their uses are in a context where a constant expression
- may be required. For example, the following should be allowed
- 
- 
- 
- template<typename
- T, int N>
- 
- int
- size(const T(&)[N]) { return N; }
- 
- 
- 
- int
- a[] = { 41,42,43,44 };
- 
- enum
- { v = size(a) };
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 12
- </TD>
- <TD>
- 7.1.5
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- It
- should be allowed to define constexpr recursively.
- 
- There is an explanation in
- N2235, Generalized Constant Expressions—Revision 5, as
- follows.
- 
- 
- 
- 
- We (still) prohibit recursion
- in all its form in constant expressions. That is not strictly
- necessary because an implementation limit on recursion depth in
- constant expression evaluation would save us from the possibility
- of the compiler recursing forever. However, until we see a
- convincing use case for recursion, we don’t propose to allow
- it.
- 
- 
- 
- 
- Then, here are the use cases
- where allowing recursion for constexpr is very useful.
- 
- 
- 
- 
- Range of problem to be handled
- with constexpr would become extended. For example, user defined
- type (e.g. Complex type) could be placed in ROM area. But with
- current specification, a function defined with constexpr cannot be
- called recursively. As a side effect is not allowed in
- compile-time, it cannot be implemented to repeat anything without
- recursion. Although it could be implemented without recursion like
- func0, func1, func2 in an example below, it is not elegant
- solution.
- 
- 
- 
- 
- constexpr double func0(double
- x) { /* ... */}
- 
- constexpr double func1(double
- x) { /* call for func0 */ }
- 
- constexpr double func2(double
- x) { /* call for func1 */ }
- 
- /* ... */
- 
- 
- 
- 
- - Compile-time and runtime
- 
- As constexpr can be also
- evaluated both in compile-time and runtime, we need to discuss
- about both cases.
- 
- 
- 
- 
- Runtime evaluation is just to
- execute it. If you eliminate constexpr keyword, it is executable
- as of now. Any modern compiler may optimize tail recursion easily.
- 
- 
- 
- 
- Compile-time evaluation is the
- same thing as template recursion. It is necessary to support
- floating point operation, but it is already possible to calculate
- it in compile-time, so it’s ok.
- 
- 
- 
- 
- - Sample
- 
- Here is an example to
- calculate a square root using constexpr recursively.
- 
- 
- 
- 
- /*constexpr*/ double
- SqrtHelper(double x, double a, int n)
- 
- {
- 
- return n == 0 ? a :
- SqrtHelper(x, (x / a + a) / 2.0, n - 1);
- 
- }
- 
- 
- 
- 
- /*constexpr*/ double
- Sqrt(double x)
- 
- {
- 
- return SqrtHelper(x, x, 20);
- 
- }
- 
- 
- 
- 
- /*constexpr*/ double root2 =
- Sqrt(2.0); // 1.41421...
- 
- 
- 
- </TD>
- <TD>
- 
- Allow constexpr recursion.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 37
- </TD>
- <TD>
- 7.1.6.1
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- There is a "Note: 3.9.3
- describes how cv-qualifiers affect object and function types."
- So far as I can see, 3.9.3 CV-qualifiers only describes
- cv-qualifiers for objects, cv-qualifiers for (member) functions
- being described in 8.3.5 Functions.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 89
- </TD>
- <TD>
- 7.1.6.1
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- two normative sentences in this paragraph appear to duplicate text
- elsewhere - but they aren't exact duplicates, which introduces
- uncertainty. 1. "An object declared in namespace scope with a
- const-qualified type has internal linkage unless it is explicitly
- declared extern or unless it was previously declared to have
- external linkage.". This nearly repeats 7.1.1/7: "Objects
- declared const and not explicitly declared extern have internal
- linkage." The former seems to allow more wiggle room - can an
- object be "previously declared to have external linkage"
- without having been "explicitly declared extern"? 2. "A
- variable of non-volatile const-qualified integral or enumeration
- type initialized by an integral constant expression can be used in
- integral constant expressions (5.19)." This nearly duplicates
- 5.19/2, bullet 4, 1st sub-bullet - "[... an integaral
- constant expression can use] an lvalue of effective integral type
- that refers to a non-volatile const variable or static data member
- initialized with constant expressions". The latter does not
- allow for lvalues of enumeration type (neither scoped not unscoped
- enumerations are integral types - 3.9.1/7, and note 44). This
- seems to be a flaw in 5.19/2.
- 
- 
- </TD>
- <TD>
- Make
- the normative text in this section into one or more notes, with
- cross references, and correct the referenced text if necessary.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 90
- </TD>
- <TD>
- 7.1.6.2
- </TD>
- <TD>
- para
- 1 and table 9
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- grammar in paragraph one makes "nested-name-specifier
- template simple-template-id" a simple-type-specifier, but
- unlike all the others it is omitted from table 9.
- 
- 
- </TD>
- <TD>
- Add
- a row to table 9 mentioning simple-template-id and punting to
- clause 14 (cf decltype(expression)).
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 91
- </TD>
- <TD>
- 7.1.6.2
- </TD>
- <TD>
- 4
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- 5.1/5
- says "[A] parenthesized expression can be used in exactly the
- same contexts as those where the enclosed expression can be used,
- and with the same meaning, except as otherwise indicated."
- When the first bullet point of this paragraph, describing the type
- denoted by decltype(e), says "if e is an id-expression ...
- decltype(e) is the type of the entity named by e", 5.1/5 is
- not excluded, which would imply that decltype((e)) was also the
- type of e. But the intention appears that it should be caught by
- the third bullet and treated as an lvalue expression, so
- decltype((e)) should be a reference to the type of e. Conversely,
- the second bullet point says "(parentheses around e are
- ignored)", which is redundant because of 5.1/5.
- 
- 
- </TD>
- <TD>
- Insert
- "unparenthised" in the first bullet point - "if e
- is an *unparenthised* id-expression ...". In the second
- bullet point, move "(parentheses around e are ignored)"
- into a note.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 92
- </TD>
- <TD>
- 7.1.6.3
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- note correctly indicates that, if T is a template type parameter,
- then "friend class T;" is ill-formed. It might be worth
- pointing out at the same time that the alternative "friend
- T;" is now allowed - see 11.4/3.
- 
- 
- </TD>
- <TD>
- Either
- strike the note or add reference to 11.4/3 and/or mention of
- "friend T;".
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 93 
- 
- </TD>
- <TD>
- 7.1.6.3
- </TD>
- <TD>
- Grammar
- before para 1
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- In
- the third production, "enum ::opt nested-name-specifieropt
- identifier", enum should not be in italics; its referring to
- the enum keyword.
- 
- 
- </TD>
- <TD>
- Change
- to keyword font
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 94
- </TD>
- <TD>
- 7.1.6.4
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- auto type-specifier signifies that the type of an object being
- declared shall be deduced from its initializer or specified
- explicitly at the end of a function declarator. A function
- declarator does not declare an object.
- </TD>
- <TD>
- The
- auto type-specifier signifies that the type of an object being
- declared shall be deduced from its initializer or that the return
- type of a function is specified explicitly at the end of a
- function declarator. 
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 95
- </TD>
- <TD>
- 7.1.6.4
- </TD>
- <TD>
- 4
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- (See
- also c++std-core-13583) This paragraph allows auto "in the
- type-specifier-seq in a new-type-id (5.3.4)" (and nowhere
- else not listed). Specifically, it isn't allowed in a type-id in a
- new-expression. That allows "new auto (42)", but not
- "new (auto)(42)". However, 5.3.4/2 suggests the latter
- should be allowed "If the auto type-specifier appears in the
- type-specifier-seq of a new-type-id or type-id of a new-expression
- ...". The inconsistency should be resolved, ideally in favour
- of allowing both forms.
- 
- 
- </TD>
- <TD>
- Change
- "in a new-type-id" to "in a new-type-id or type-id
- in a new-expression".
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 24
- </TD>
- <TD>
- 7.1.6.4
- [auto specifier]
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- Now
- that 'auto' is finally used in its most obvious sense to state
- `deduce the type of this variable from initializer', it should
- also be allowed in template parameter declarations, as in
- 
- 
- 
- template<auto
- n> struct X { /* … */ };
- 
- 
- 
- X<903>
- x;
- 
- 
- 
- X<&Widget::callback>
- y;
- 
- 
- 
- instead
- of the current, often verbose and cumbersome
- 
- 
- 
- 
- template<typename
- T, T n> struct X { /* … 
- */
- };
- 
- 
- 
- X<int,903>
- x;
- 
- X<void
- (Widget::*)(),&Widget::callback> y;
- 
- 
- 
- We
- understand that 'auto' is used in 14.1/18 in a different way (for
- constrained template), but that usable appears very strange
- syntax, unnatural and does not fit well with the usage in this
- section.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 38
- </TD>
- <TD>
- 7.2
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- The discussion of attribute
- specifiers should be a separate paragraph.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 39
- </TD>
- <TD>
- 7.2
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- The paragraph says in part "An
- opaque-enum-declaration declaring an unscoped enumeration shall
- not omit the enum-base." This statement implies that the base
- may be omitted for scoped enumerations, which is somewhat
- inconsistent with paragraph 3 and somewhat consistent with
- paragraph 5.
- 
- 
- </TD>
- <TD>
- As
- this implication leaves no representation, it should be either
- affirmed here or the statement should be expanded. Perhaps a note
- is warranted.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 13
- </TD>
- <TD>
- 7.2
- </TD>
- <TD>
- paragraph
- 3
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- In the description for an
- unscoped enumeration, enum-base in redeclaration must be the same
- underlying type as in the 1st declaration, but it is not described
- explicitly, while it is referred that all enum-bases in
- redeclarations must specify the same underlying type.
- 
- 
- </TD>
- <TD>
- Replace
- the description, "same underlying type", with "same
- as underlying type of (previous) declaration."
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 96
- </TD>
- <TD>
- 7.2
- </TD>
- <TD>
- 7
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- enum
- E { }; What are the values of E? It has neither a smallest nor
- largest enumerator, so paragraph 7 doesn't help. (Paragraph 6
- indicates that the underlying type is as if E had a single
- enumerator with value 0, but that does not define the values of
- E.)
- 
- 
- </TD>
- <TD>
- Add
- a second sentence to paragraph 7 (before "Otherwise"):
- "If the enumerator-list is empty, 0 is the only value of the
- enumeration."
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 97
- </TD>
- <TD>
- 7.2
- </TD>
- <TD>
- 9
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Missing
- punctuation after "blue" in: "The possible values
- of an object of type color are red, yellow, green, blue these
- values can be converted ..."
- 
- 
- </TD>
- <TD>
- Add
- a semicolon: "The possible values of an object of type color
- are red, yellow, green, blue; these values can be converted ..."
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 98
- </TD>
- <TD>
- 7.2
- </TD>
- <TD>
- 5
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- It
- would be useful to be able to determine the underlying type of an
- arbitrary enumeration type. This would allow safe casting to an
- integral type (especially needed for scoped enums, which do not
- promote), and would allow use of numeric_limits. In general it
- makes generic programming with enumerations easier.
- 
- 
- </TD>
- <TD>
- Add
- a TransformationTrait to 20.5.6 that returns the underlying type
- of an enumeration type.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 99
- </TD>
- <TD>
- 7.2
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- It
- is unclear whether an enumeration type is complete after an
- opaque-enum-declaration. This paragraph only says so in a note,
- and the general rule in 3.9/5 ("Incompletely-defined object
- types ... are incomplete types") is unclear in this
- situation.
- 
- 
- </TD>
- <TD>
- Move
- "an enumeration declared by an opaque-enum-declaration ... is
- a complete type" from the note to normative text.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 14
- </TD>
- <TD>
- 7.3.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- The description of the
- behavior when a member that was defined with same name in other
- namespace was referred.
- 
- - It seems that the behavior
- of the following case is not defined. So we think that it is
- necessary to define that.
- 
- namespace Q {
- 
- inline namespace V {
- 
- int g;
- 
- }
- 
- int g;
- 
- }
- 
- Q::g =1;// ill-fromed, Q::V::g
- =1;, or Q::g = 1;?
- 
- - Add that the following case
- is ill-formed to more easily to understand.
- 
- namespace Q {
- 
- inline namespace V1{
- 
- int g;
- 
- }
- 
- inline namespace V2{
- 
- int g;
- 
- }
- 
- }
- 
- Q::g =1;//ill-formed
- 
- 
- 
- </TD>
- <TD>
- 
- Add the description of the
- behavior when a member that was defined with same name in other
- namespace was referred.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 100
- </TD>
- <TD>
- 7.3.3
- </TD>
- <TD>
- 10
- and 13
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Para
- 10 says "A using-declaration is a declaration and can
- therefore be used repeatedly where (and only where) multiple
- declarations are allowed." Para 13 says "Since a
- using-declaration is a declaration, the restrictions on
- declarations of the same name in the same declarative region (3.3)
- also apply to using-declarations." These appear to be saying
- exactly the same thing.
- 
- 
- </TD>
- <TD>
- Delete
- para 10, moving its example into para 13.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 101
- </TD>
- <TD>
- 7.3.3
- </TD>
- <TD>
- 20
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- If
- a using-declaration uses the keyword typename and specifies a
- dependent name (14.6.2), the name introduced by the
- using-declaration is treated as a typedef-name (7.1.3). That
- doesn't specify at all what the effect of using typename with a
- non-dependent name is. Is it allowed? What about outside any
- template? What if the name isn't a type? (14.6/4 doesn't cover
- this, I think.)
- 
- 
- </TD>
- <TD>
- Allow
- typename for non-dependent names iff they refer to a type.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- DE-12
- </TD>
- <TD>
- 7.3.3
- </TD>
- <TD>
- p15
- </TD>
- <TD>
- te
- </TD>
- <TD>
- DE-12
- Overriding and hiding of member functions named in
- using-declarations should consider ref-qualifiers, because they
- are part of the function type.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 25
- </TD>
- <TD>
- 7.3.3
- [The using declaration]
- </TD>
- <TD>
- Paragraph
- 21
- </TD>
- <TD>
- te
- </TD>
- <TD>
- The
- syntax for concept map alias is unnecessarily both confused and
- verbose.
- </TD>
- <TD>
- 
- We
- strongly suggest simplifications, e.g.
- 
- using
- N1::C<int>;
- 
- that
- fits well with existing constructs. The syntactic complexity is
- too high for a new feature presumably designed to support sound
- programming.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 102
- </TD>
- <TD>
- 7.3.4
- </TD>
- <TD>
- 6
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- This
- paragraph says "If name lookup finds a declaration for a name
- in two different namespaces, and the declarations do not declare
- the same entity and do not declare functions, the use of the name
- is ill-formed." But the example uses declaration of
- functions, so is not covered by this paragraph.
- 
- 
- </TD>
- <TD>
- Move
- the example to paragraph 7, and/or replace it with an appropriate
- example.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 40
- </TD>
- <TD>
- 7.6
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- The
- list of attributes is missing an attribute to indicate that a
- function with a <CODE>
- throw()</CODE>
- (throws nothing) clause need not have the <CODE>
- unexpected()</CODE>
- catch clause generated. This attribute was a motivating example
- for the attribute syntax, and its omission is surprising.
- 
- 
- </TD>
- <TD>
- Add
- the attribute.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 41
- </TD>
- <TD>
- 7.6
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- A common problem is
- unintentionally declaring a new virtual member function instead of
- overriding a base virtual member function.
- 
- 
- </TD>
- <TD>
- An
- attribute stating intent to override would enable better
- diagnostics.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 26
- </TD>
- <TD>
- 7.6
- [Attributes]
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- Are
- they part of object types or not? The section does not appear to
- indicate that clearly.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FI
- 1
- </TD>
- <TD>
- 7.6
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- Add
- override-attribute for functions in order to avoid mistakes when
- overriding functions.
- </TD>
- <TD>
- See
- override-attribute.doc, override-attribute.ppt
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 27
- </TD>
- <TD>
- 7.6.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- This
- section specifies that no name lookup is performed on any
- identifier contained in an attribute-token. This in particular
- implies that, for example, it is impossible to define a template
- class parameterized by its alignment. That restriction is
- unacceptable.
- 
- The
- original alignment proposal made that useful construct possible.
- 
- Furthermore
- paragraph 7.6.1/2 appears contradictory with the rest of that
- section -- since no name lookup is performed, how a 'type-id'is
- determined?
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 103
- </TD>
- <TD>
- 7.6.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Attributes
- should support pack expansion. For example, this would be
- extremely useful with the align attribute, directly supporting the
- (removed) functionality of aligned_union. NOte that aligned_union
- was removed as varaiant-unions were considered a complete
- replacement - however this is not true for variadic templates.
- Adding this support to attributes would remove the remaining need,
- and support similar attributes in the future.
- </TD>
- <TD>
- Add:
- attribute... to the grammar for attribute-list Add to list in
- 14.5.3p4: "In an attribute-list(7.6.1); the pattern is an
- attribute." 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 104
- </TD>
- <TD>
- 7.6.1
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- It
- is helpful for each subclause to contain a short paragraph
- introducing its intent an purpose. 7.6 has such a paragraph, but
- it is nested under a more specific subsection.
- 
- 
- </TD>
- <TD>
- 7.6.1p1
- should move up one level to become 7.6p1. There grammar should
- remain under 7.6.1
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 105
- </TD>
- <TD>
- 7.6.1
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Allowing
- only one level of namespaces in attributes seems unnecessarily
- limiting.
- </TD>
- <TD>
- To:
- attribute-scoped-token: attribute-namespace :: identifier add
- attribute-namespace :: attribute-scoped-token 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 106
- </TD>
- <TD>
- 7.6.2
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Extensive
- use of alignment and related terms without cross reference.
- 
- 
- </TD>
- <TD>
- Add
- cross-reference to 3.11.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 15
- </TD>
- <TD>
- 7.6.2
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- An
- abbreviation of 7.6.2 should be “[decl.attr.align]”
- instead of “[dcl.align]”. Section name
- “[dcl.align]” is not consistent with others, because
- others in 7.6 are the form of “dcl.attr.*”. In N2761,
- the section name of 7.1.7 had been changed from “[dcl.align]”
- to “[dcl.attr.align]”, but in N2800 it was reverted to
- “[dcl.align]” along with a change of section number,
- 7.1.7 to 7.6.2.
- 
- 
- </TD>
- <TD>
- Change
- "[dcl.align]" of 7.6.2 to "[decl.attr.align]".
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 107
- </TD>
- <TD>
- 7.6.3
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- While
- undefined behaviour might be the best we can guarantee, it would
- be helpful to encourage implementations to diagnose function
- definitions that might execute a return.
- 
- 
- </TD>
- <TD>
- Adda
- a [Note : implementations are encouraged to issue a diagnostic
- where the definition of a function marked [[noreturn]] might
- execute a return statement -- end note]
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 108
- </TD>
- <TD>
- 7.6.4
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- It
- is unclear why no diagnostic is required for an easily detectable
- violation. It is even more surprising that the associated footnote
- mandates behaviour for an ill-formed program.
- 
- 
- </TD>
- <TD>
- Strike
- "no diagnostic required" and the associated footnote.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 42
- </TD>
- <TD>
- 7.6.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- The
- meaning of the <CODE>
- [[final]]</CODE>
- attribute applied to classes is inconsistent with other languages
- and not desirable in its own right.
- 
- 
- </TD>
- <TD>
- 
- Modify
- the semantics of <CODE>
- [[final]]</CODE>
- applied to classes. See the attached paper "Issues with the
- C++ Standard" under Chapter 7 "Meaning of <CODE>
- [[final]]</CODE>
- attribute applied to classes".
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 109
- </TD>
- <TD>
- 7.6.5
- </TD>
- <TD>
- 4
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- example code refers in comments to "Compilation unit" A
- and B. The term should be "Translation unit" (2/1)
- 
- 
- </TD>
- <TD>
- Replace
- "Compilation" with "Translation" in two places
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 110
- </TD>
- <TD>
- 7.6.5
- </TD>
- <TD>
- 4
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- code in the example (compilation unit A) has:
- "foo_head[i].load(memory_order_consume)". foo_head[i] is
- of type foo *, so it does not have a load member.
- 
- 
- </TD>
- <TD>
- Change
- the type of foo_head to atomic<foo *>[].
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 43
- </TD>
- <TD>
- 8
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- With
- the introduction of late-specified return types for functions and
- lambda expressions, we now have three different syntaxes for
- declaring functions. The <CODE>
- -></CODE>
- late declaration is used in two. The <CODE>
- auto</CODE>
- keyword is used in one, but also used differently in variable
- definitions.
- 
- 
- </TD>
- <TD>
- Some
- simplification is needed.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 111
- </TD>
- <TD>
- 8.3.5
- </TD>
- <TD>
- 13
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Example
- missing closing bracket in template<typename... T> void f(T
- (* ...t)(int, int);
- 
- 
- </TD>
- <TD>
- Add
- closing bracket like this: template<typename... T> void f(T
- (* ...t)(int, int));
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 44
- </TD>
- <TD>
- 8.3.5
- </TD>
- <TD>
- 13
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- In the Example, "template
- void f(T (* ...t)(int, int);" is missing a close parenthesis.
- 
- 
- </TD>
- <TD>
- It
- presumably should read: "template void f(T (* ...t))(int,
- int);".
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- US
- 45
- </TD>
- <TD>
- 
- 8.3.5
- </TD>
- <TD>
- 
- 13
- </TD>
- <TD>
- 
- te
- </TD>
- <TD>
- 
- At
- present, function parameter packs can only occur at the end of a
- parameter-declaration-list. This restriction unnecessarily
- prohibits uses of function parameter packs in cases where template
- argument deduction isn’t needed, e.g.,
- 
- 
- 
- template<class...
- T> struct X { };
- 
- template<class...
- T1, class... T2>
- 
- struct
- X<pair<T1, T2>...> {
- 
- void
- f(T1..., T2...);
- 
- };
- 
- 
- 
- More
- importantly, this restriction is inconsistent with the way pack
- expansions are handled. For example, this template is well-formed
- (but X<T..., int> is a non-deduced context):
- 
- 
- 
- template<class...
- T> void f(X<T..., int>);
- 
- 
- 
- Therefore,
- the restriction that limits function parameter packs to the end of
- the parameter-declaration-list should be removed. Instead,
- function parameter packs not at the end of the
- parameter-declaration-list should be considered non-deduced
- contexts.
- </TD>
- <TD>
- 
- 
- In
- 8.3.5p13, remove the sentence “A
- function parameter pack, if present, shall occur at the end of the
- parameter-declaration-list.”
- 
- 
- 
- 
- In
- 14.8.2.1p1, replace the phrase “For a function parameter
- pack” with “For a function parameter pack that occurs
- at the end of a 
- parameter-declaration-list”.
- 
- 
- 
- 
- Replace
- the note text “A function parameter pack can only occur at
- the end of a parameter-declaration-list
- (8.3.5).” with “A function parameter pack that does
- not occur at the end of a parameter-declaration-list is a
- non-deduced context.”
- 
- 
- 
- In
- 14.8.2.5p5, add a new bullet: “A function parameter pack
- that does not occur at the end of its parameter-declaration-list.”
- 
- 
- 
- 
- In
- 14.8.2.5p10, replace “If
- 
- the
- parameter-declaration corresponding to Pi is a function parameter
- pack” with “If
- 
- the
- parameter-declaration corresponding to Pi is a function parameter
- pack and Pi occurs at the end of the parameter-declaration-list”.
- 
- 
- 
- 
- 
- 
- Replace
- the
- note text “A function parameter pack can only occur at the
- end of a parameter-declaration-list
- (8.3.5).” with “A function parameter pack that does
- not occur at the end of a parameter-declaration-list is a
- non-deduced context.”
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- DE-13
- </TD>
- <TD>
- 8.4
- 
- 
- </TD>
- <TD>
- p2
- </TD>
- <TD>
- te
- </TD>
- <TD>
- DE-13
- The second paragraph, quoting the grammar for the declarator of a
- function declaration, is not considering late-specified return
- types and attributes.
- </TD>
- <TD>
- Properly
- quote the grammar from 8.3.5.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 16
- </TD>
- <TD>
- 8.5
- </TD>
- <TD>
- 
- 15th
- paragraph, 1st
- line
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- Typo, duplicated "in"
- "The
- initialization that occurs in in the forms"
- </TD>
- <TD>
- Remove
- one.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- US
- 46
- </TD>
- <TD>
- 
- 8.5.3
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- te
- </TD>
- <TD>
- 
- The
- ability for an rvalue reference to bind to an lvalue opens a
- type-safety hole that becomes very dangerous with concepts. For
- example, consider vector’s push_back operation:
- 
- requires
- MoveConstructible<T> void push_back(T&&);
- 
- requires
- CopyConstructible<T> void push_back(const T&);
- 
- 
- 
- For
- a copy-constructible T (which is also move-constructible),
- push_back does the right thing. However, if T is something that is
- move-constructible (e.g., unique_ptr<int>), the second
- overload is removed from considered (it is effectively SFINAE’d
- away), so only the first overload remains. Therefore, one could
- accidentally call push_back with an lvalue of type T, and
- push_back would silently move from the lvalue. The same problem
- occurs without concepts (albeit less frequently).
- 
- 
- 
- 
- </TD>
- <TD>
- 
- Prohibit
- rvalue references from binding to lvalues.
- 
- 
- 
- Unfortunately
- this change will break some current use cases of rvalue reference
- including the use of rvalue streams, and of the forward function
- itself. To resolve this we may want to consider three types of
- references:
- 
- 
- <OL>
- <LI>
- The
- current reference.
- <LI>
- A
- non-const reference that only binds to rvalues.
- <LI>
- A
- non-const reference that will bind to both lvalues and rvalues.
- </OL>
- 
- 
- 
- Still
- another solution would be to adopt the “deleted function”
- solution for all functions. This solution is described in comment
- for 12.1, 12.4, 12.8, but restricted to special functions in that
- comment. (See US NN).
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 49
- </TD>
- <TD>
- 8.5.4
- </TD>
- <TD>
- 6
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- In
- the Example, the comments could be improved.
- </TD>
- <TD>
- 
- See the attached paper "Issues
- with the C++ Standard" under "Editorial Issues" and
- "8.5.4/6".
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 112
- </TD>
- <TD>
- 9
- </TD>
- <TD>
- 4-9
- </TD>
- <TD>
- Ge
- </TD>
- <TD>
- We
- now have concepts that should (or should not?) map to the terms
- described in Clause 9 - these should be at least referenced.
- 
- 
- </TD>
- <TD>
- Add
- appropriate forward references to 14.9.4
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 113
- </TD>
- <TD>
- 9.4.2
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Mis-applied
- edit from the paper n2756
- </TD>
- <TD>
- The
- term 'constant-initializer' should have been struck out when
- replaced by brace-or-equal-initializer. There are two occurrences
- in this paragraph
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- US
- 50
- </TD>
- <TD>
- 
- 12.1,
- 12.4, 12.8
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- te
- </TD>
- <TD>
- 
- Implicitly-declared
- default constructors, destructors, copy constructors, and copy
- assignment operators are deleted when their definitions would be
- ill-formed. However, unlike with overloading and template argument
- deduction, access control is performed as part of the check for
- making one of these special function deleted. This inconsistency
- should be removed.
- 
- 
- 
- This
- change would sacrifice some backward compatibility in favor of
- consistency. With the current wording, checking that the following
- class ‘A’ is CopyConstructible would proceed without
- error (it is not CopyConstructible):
- 
- class
- A { A(const A&); };
- 
- With
- the proposed change, testing whether A is CopyConstructible would
- produce a diagnostic. To fix the problem, the user would have to
- use a deleted function:
- 
- class
- A { A(const A&) = delete; };
- 
- 
- </TD>
- <TD>
- 
- 
- In
- 12.1p5, remove the phrase “
- or inaccessible from the implicitly-declared default 
- constructor”.
- 
- 
- 
- 
- In
- 12.4p3, remove the phrase “or
- a destructor that is inaccessible from the implicitly-declared
- destructor,” and the phrase “or a destructor that is
- inaccessible from the 
- implicitly-declared
- destructor”.
- 
- 
- 
- 
- In
- 12.8p5, remove the phrase “
- or inaccessible from the implicitly-declared copy constructor”
- from the two places it occurs.
- 
- 
- 
- 
- In
- 12.8p10, remove the phrase “or
- inaccessible from the implicitly-declared copy assignment
- operator” from the two places it occurs.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 28
- </TD>
- <TD>
- 
- 12.6.1
- [Explicit initialization]
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- This
- section, in particular the example with `g' appears contradictory
- with the syntax for uniform initialization.
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 51
- </TD>
- <TD>
- 12.6.2
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- The discussion of delegating
- constructors should be in its own paragraph.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 114
- </TD>
- <TD>
- 12.6.2
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Despite
- all the attempts to unify initialization syntax, it is still not
- possible to copy-initialize base classes or non-static data
- members, which means the explicit keyword cannot have a bearing
- during evaluation of a constructor. A minimal addition to the
- grammar, allowing an optional = between the mem-initializer-id and
- braced-init-list would allow the user to choose between copy and
- direct initialization
- </TD>
- <TD>
- Ammend
- the grammar for mem-initializer: mem-initializer-id =OPT
- braced-init-list Extend p3 to allow for Copy Initialization if the
- optional = is present: 3 The expression-list or braced-init-list
- in a mem-initializer is used to initialize the base class or
- non-static data member subobject denoted by the mem-initializer-id
- according to the initialization rules of 8.5 for
- direct-initialization, OR COPY-INITIALIZATION IF THE OPTIONAL = IS
- PRESENT BETWEEN THE MEM-INITIALIZER-ID and the BRACED-INIT-LIST.
- [Example:...
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 52
- </TD>
- <TD>
- 13.5.8
- </TD>
- <TD>
- ¶
- 5
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- A
- word is misspelled.
- </TD>
- <TD>
- Change
- “shal” to “shall”.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 115
- </TD>
- <TD>
- 14
- </TD>
- <TD>
- 6-11
- </TD>
- <TD>
- Ge
- </TD>
- <TD>
- Exported
- templates were a great idea that is generally understood to have
- failed. In the decade since the standard was adopted, only one
- implementation has appeared. No current vendors appear interested
- in creating another. We tentatively suggest this makes the feature
- ripe for deprecation. Our main concern with deprecation is that it
- might turn out that exported constrained templates become an
- important compile-time optimization, as the constraints would be
- checked once in the exported definition and not in each
- translation unit consuming the exported declarations.
- 
- 
- </TD>
- <TD>
- Consider
- deprecating exported templates, but no action yet. Examine
- interaction with constrained templates, and see if other more
- appropriate mechanism will support compile-time optimization.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 116
- </TD>
- <TD>
- 14
- </TD>
- <TD>
- 6-11
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Is
- it possible to export a concept map template? The current wording
- suggests it is possible, but it is not entirely clear what it
- would mean.
- 
- 
- </TD>
- <TD>
- Either
- prohibit exporting concept map templates, or more directly address
- what it means to export a concept map.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 117
- </TD>
- <TD>
- 14
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Ge
- </TD>
- <TD>
- It
- would be nice to allow template alias within a function scope, and
- possibly a scoped concept map. As these affect name lookup and
- resolution, rather than defining new callable code, they are not
- seen to present the same problems that prevented class and
- function templates in the past.
- 
- 
- </TD>
- <TD>
- Allow
- template aliases to be declared inside a function scope, and
- consider scoped concept maps.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 118
- </TD>
- <TD>
- 14
- </TD>
- <TD>
- 6-11
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Exported
- templates are a complicated feature with surprisingly little text.
- To make this important text more visible, split it off into its
- own subclause [temp.export]
- 
- 
- </TD>
- <TD>
- Create
- a new subclause [temp.export] containing 14p6-11. Move 14p12 ahead
- of this subclause.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 119
- </TD>
- <TD>
- 14
- </TD>
- <TD>
- 4
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Does
- a concept map have linkage? Reading this paragraph and 3.5
- suggests a concept map template has external linkage, but not a
- 'regular' concept map. Believe this is an oversight that the
- linkage words were not updated to provide an exception, rather
- than linkage of concept maps is intended.
- 
- 
- </TD>
- <TD>
- Add
- an exception that concept map templates have no linkage, or add
- concept maps to the list of entities with linkage in 3.5
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 120
- </TD>
- <TD>
- 14.1
- </TD>
- <TD>
- 9
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- As
- this is the first time the phrase “parameter pack”
- appears in Ch 14 I would like to see the section 8.3.5 referenced
- here (as well as in 14.1p17).
- 
- 
- </TD>
- <TD>
- Insert
- “(8.3.5)” after “parameter pack” 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 121
- </TD>
- <TD>
- 14.1
- </TD>
- <TD>
- 18
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- example (that follows the normative text) has no begin example
- marker
- 
- 
- </TD>
- <TD>
- Prefix
- the example code with "[ Example:" 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 29
- </TD>
- <TD>
- 
- 14.3
- [Template arguments]
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- Constant
- expressions of any literal type should be allowed as template
- arguments.
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- US
- 53
- </TD>
- <TD>
- 
- 14.5.1
- </TD>
- <TD>
- 
- 5
- </TD>
- <TD>
- 
- te
- </TD>
- <TD>
- 
- 
- If
- the requirements of a constrained member that is a copy
- constructor, copy assignment operator, or destructor are not
- satisfied, then that user-declared special function will not
- exist. It appears that, in this case, the special function will
- then be 
- implicitly
- defined, which is likely to either (a) fail to compile or (b)
- produce a function with the wrong semantics. For example:
- 
- template<ObjectType
- T> class vector {
- 
- T*
- first, last, end;
- 
- public:
- 
- requires
- CopyConstructible<T> vector(const vector&);
- 
- };
- 
- 
- 
- If
- instantiated with a type that is not CopyConstructible, vector
- will get an implicitly-defined copy constructor that performs a
- copy of the pointers.
- </TD>
- <TD>
- 
- Add
- to 14.5.1p5:
- 
- If
- the constrained member is a copy constructor (12.8), destructor
- (12.4), or copy assignment operator and its template requirements
- are not satisfied, then a copy constructor, destructor, or copy
- assignment operator, respectively, with the same signature as the
- constrained member (after substituting the class template’s
- template arguments for its template parameters) will be declared
- as a deleted function (8.4).
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 122
- </TD>
- <TD>
- 14.5.3
- </TD>
- <TD>
- 4
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Variadic
- templates should be supported in axioms. There are axioms in the
- library that rely on this feature, such as the FrontEmplacement
- axiom in FrontEmplacementContainer (23.1.6.1p10)
- 
- 
- </TD>
- <TD>
- Add
- clarification in p2 that function parameter packs can be used to
- declare axioms, much like p1 clarifies they can be used to declare
- concepts as well as templates.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 30
- </TD>
- <TD>
- 14.5.7
- [Template aliases]
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- When
- are two template alias names equivalent?
- 
- 
- 
- E.g.
- given
- 
- template<template<class>
- class> struct X { };
- 
- 
- 
- template<typename,typename>
- struct Y { };
- 
- 
- 
- template<typename
- T>
- 
- using
- Z1 = Y<int,T>;
- 
- 
- 
- template<typename
- T>
- 
- using
- Z2 = Y<int,T>;
- 
- 
- 
- Are
- the types X<Z1> and X<Z2> equivalent?
- 
- We
- would suggest yes (since Z1<T> and Z2<T> are the same
- for all T), but we do not see any wording to that effect.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 17
- </TD>
- <TD>
- 14.7.2
- </TD>
- <TD>
- 2nd
- paragraph, 15th
- line
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- Typo.
- 
- if that namespace is inline,
- any namespace from its enclosing namespace set.
- 
- 
- 
- 
- should be
- 
- 
- 
- 
- if
- that namespace is inline, any namespace 
- forming
- its enclosing namespace set.
- 
- 
- </TD>
- <TD>
- Replace
- "from" with "forming"
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- DE-14
- </TD>
- <TD>
- 14.7.3
- 
- 
- </TD>
- <TD>
- p1
- </TD>
- <TD>
- te
- </TD>
- <TD>
- DE-14
- The bulleted list neither addresses "member function template
- of a class" nor "member class template of a class".
- </TD>
- <TD>
- Add
- the respective bullets.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 18
- </TD>
- <TD>
- 14.7.3
- </TD>
- <TD>
- 2nd
- paragraph, 2nd
- line
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- Typo,
- 
- any namespace from its
- enclosing namespace set
- 
- 
- 
- 
- should be
- 
- 
- 
- 
- any
- namespace 
- forming
- its enclosing namespace set
- 
- 
- </TD>
- <TD>
- Replace
- "from" with "forming"
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 19
- </TD>
- <TD>
- 14.8.2
- </TD>
- <TD>
- 6th
- paragraph, 1st
- line
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- Typo, duplicated "is"
- 
- "At
- certain points in the template argument deduction process it is
- is necessary"
- 
- 
- 
- </TD>
- <TD>
- 
- Remove one
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 54
- </TD>
- <TD>
- 14.9
- [concept],
- 14.10
- [temp.constrained]
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ge
- </TD>
- <TD>
- Concepts is
- of course the largest new feature in C++0x (in terms of new text
- inserted into the wording), and already we have found some
- significant defects with it. So far nothing devastating has been
- found, but more time is needed to shake more bugs out.
- </TD>
- <TD>
- I
- propose no specific change here. 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 55
- </TD>
- <TD>
- 14.9.1
- </TD>
- <TD>
- ¶
- 6
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- The
- paragraph number is in the wrong place, causing a grammar rule to
- be indented more than its fellows.
- </TD>
- <TD>
- Move
- the paragraph number so as to follow the grammar rules, thus
- numbering the single sentence, “The body of a concept …
- .”
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 56
- </TD>
- <TD>
- 14.9.1
- </TD>
- <TD>
- ¶
- 6
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- The
- sentence contains two references to 14.9.1.3 [concept.req].
- </TD>
- <TD>
- Change
- the second such reference (at the end of the sentence) to 14.9.1.4
- [concept.axiom].
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 57
- </TD>
- <TD>
- 14.9.1.4
- </TD>
- <TD>
- ¶
- 3
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- A
- word is misplaced, changing the intended meaning.
- </TD>
- <TD>
- Change
- “only find … if” to “find … only
- if”.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 58
- </TD>
- <TD>
- 14.9.1.4
- </TD>
- <TD>
- ¶
- 3
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- The
- listed phrases are not grammatically parallel.
- </TD>
- <TD>
- Insert
- “in” before “one” so as to obtain “...
- in the concept, in one of its less refined concepts, or in an
- associated requirement.”
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- US
- 59
- </TD>
- <TD>
- 
- 14.9.1.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- te
- </TD>
- <TD>
- 
- Axioms
- are under-specified and provide little benefit to programmers, so
- they should be removed from the working paper. The optimizations
- permitted by axioms (see 14.9.1.4p4-5) are not compulsory (and,
- therefore, programmers cannot rely on them) and the semantics
- expressed by axioms cannot be verified by any implementation. The
- resulting specification has lead to great confusion (see the
- reflector thread “Are floating point types Regular?”
- starting with c++std-lib-22717). Given the level of confusion and
- the inability to verify the correctness of axioms, it is likely
- that many axioms written by programmers (including those specified
- in the candidate draft) will be incorrect.
- </TD>
- <TD>
- 
- Remove
- clause 14.9.1.4 [concept.axiom]
- 
- In
- 2.11p1, remove “axiom” from the list of keywords.
- 
- 
- 
- In
- 14.5.8p7, remove “, or if the resulting concept map fails to
- satisfy the axioms of the corresponding concept”
- 
- 
- 
- In
- 14.9.1p6, remove axiom-definition from the list of grammar
- productions for concept-member-specifier. Remove “, and
- axioms” from the final sentence, and instead “and”
- prior to “associated requirements” in the final
- sentence.
- 
- 
- 
- 
- 
- Remove
- paragraph 14 of clause 14.9.2.
- 
- 
- 
- 
- In
- 14.10.1p6, remove the sentence, “When the
- concept-instance-alias-def appears in the optional requires-clause
- of an axiom-definition (14.9.1.4), the potential scope of the
- identifier begins at its point of declaration and terminates at
- the end of the axiom-deﬁnition.”
- 
- 
- 
- 
- In
- clauses 20.2.5, 20.2.8, 23.1.6.1, 23.1.6.2, and 24.1.4, remove the
- axiom-definitions and replace them with paragraphs (denoted
- Requires, Postconditions, or Effects, as appropriate) that
- express the intended semantics of the concepts from which the
- axiom-definitions were removed.
- 
- 
- 
- In
- 24.1.4p2, replace the word “axiom” with “condition.”
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 31
- </TD>
- <TD>
- 14.9.1.4
- [Axioms]
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- This
- section states that an axiom-definition defines a new semantics
- axiom but is unusually vague as to what those semantics might be.
- 
- 
- 
- The
- use of the '==' and '!=' with completely new semantics, unrelated
- to anything we have seen before in C++ is both unwise and
- confusing, especially if the types involved in the expressions
- happen to have operator== and operator!= defined.
- 
- 
- We
- strongly suggest use of different tokens, e.g. 
- ,
- and opposed to this obscure usage/overload.
- 
- The
- description is very vague. How many times is an implementation
- permitted to replace one expression by another one when they have
- side effects?
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- DE-15
- </TD>
- <TD>
- 14.9.1.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- DE-15
- There is no implementation experience for axioms. Use of axioms is
- an area of active scientific research. It is likely that syntax
- changes will become necessary to make good use of axioms; having
- the syntax space already crowded is unhelpful. Axioms ought to be
- useful in concepts applicable to floating-point types (such as
- EqualityComparable), but IEEE floating-point types have special
- values such as NaN violating the axioms.
- </TD>
- <TD>
- Remove
- section 14.9.1.4 and any reference to axioms in the rest of the
- proposed standard other than the keyword reservation in section
- 2.11.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 123
- </TD>
- <TD>
- 14.9.1.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- auto
- concepts and axioms are incompatible. An axiom defines the
- semantics of an operaton or set of operations that describes the
- run time behaviour. A concept describes purely syntactic
- requirements at compile time. Where an auto concept will match
- anything that meets the syntax requirements, there is no way to
- know if the axioms will be met or not, and no way to opt out via
- some kind of negative concept map.
- 
- 
- </TD>
- <TD>
- Add
- a paragraph making axioms ill-formed inside an auto concept.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- UK 124
- 
- 
- </TD>
- <TD>
- 14.9.1.4
- </TD>
- <TD>
- 6
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Spelling
- mistake, double-e in were.
- </TD>
- <TD>
- weere
- -> were
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 125
- </TD>
- <TD>
- 14.9.1.4
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- implicit equality comparison operator available to axioms has no
- semantic. It is not clear what expressing the condition if( a == b
- ) { conditional-axiom } would mean if a and b are not truly
- EqualityComparable. We suspect the intent of the 'implicit
- defefinition' is to support declaring the equivalence of
- statements, a context where the operator will not actually be
- evaluated.
- 
- 
- </TD>
- <TD>
- Define
- the semantics of the implicitly declared comparison operators, or
- restrict their usage to declaring equivalence between statements.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 126
- </TD>
- <TD>
- 14.9.4
- </TD>
- <TD>
- 41
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- This
- paragraph contains the only definition of the underlying_type
- member - but it's a note, so not normative.
- 
- 
- </TD>
- <TD>
- Move
- the second sentence to the Requires clause in paragraph 42.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 127
- </TD>
- <TD>
- 14.9.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Provide
- a diagram clearly showing refinement relationship between the
- different support concepts. Several were created during
- development of this clause and they were very helpful.
- 
- 
- </TD>
- <TD>
- Provide
- the diagram. 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 128
- </TD>
- <TD>
- 14.9.4
- </TD>
- <TD>
- 4
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- It
- is surprising for many people that non-copyable move-only types
- can be used with a return statement, and so Returnable does not
- always imply CopyConstructible.
- </TD>
- <TD>
- A
- non-normative note: [Note: 'move only' types that are
- constructible from rvalue references may be Returnable, but not
- CopyConstructible(20.1.8) - end note]
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 20
- </TD>
- <TD>
- 14.9.4
- </TD>
- <TD>
- 2nd
- paragraph
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- Trivially copyable type was
- added in “3.9 Types”, so we think that it is necessary
- to add concept to trivially copyable type like
- “TriviallyCopyableType”.
- 
- 
- 
- </TD>
- <TD>
- 
- Add TriviallyCopyableType that
- is trivially copyable type as concept.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 129
- </TD>
- <TD>
- 14.10.1,
- 20.1.2
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- It
- should be possible to support boolean constant expressions as
- requirements without resorting to defining the True concept in the
- library. Boolean expressions are very likely to be constraints
- when deadline with non-type template parameters and variadic
- templates, and constraints in these cases should feel just as
- natural as constraints on the type system.
- 
- 
- </TD>
- <TD>
- Remove
- the True concept and library subclause 20.1.2. Provide support in
- 14.10.1 for boolean constant expressions as constraints. This may
- involve overloading the true keyword to disambiguate but ideally
- would not.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- US
- 60
- </TD>
- <TD>
- 
- 14.10.1
- </TD>
- <TD>
- 
- 1
- </TD>
- <TD>
- 
- te
- </TD>
- <TD>
- 
- The
- use of && as the separator for a list of requirements has
- shown itself to be a serious teachability problem. The mental
- model behind ‘&&’ treats concepts as simple
- predicates, which ignores the role of concepts in type-checking
- templates. The more programmers read into the ‘&&’
- (and especially try to fake || with && and !), the harder
- it is for them to understand the role of concept maps. Simply
- changing the separator to ‘,’ would eliminate a
- significant source of confusion.
- </TD>
- <TD>
- 
- Replace
- 
- 
- 
- requirement-list:
- 
- requirement-list
- ... [opt] && requirement
- 
- requirement
- ... [opt]
- 
- 
- 
- with
- 
- 
- 
- requirement-list
- 
- requirement-list
- ...[opt] , requirement
- 
- requirement
- ... [opt]
- 
- 
- 
- In
- 14.5.4p6, replace the first sentence with: 
- 
- 
- The
- instantiation of an expansion produces a comma-separated list E1,
- E2, ..., EN, where N is the number of elements in the pack
- expansion parameters.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 130
- </TD>
- <TD>
- 15.1
- </TD>
- <TD>
- 4
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- With
- the new crrent_exception API it is possible to capture a reference
- to an exception that will outlive its last active handler. That is
- in conflict with the sentance "When the last remaining active
- handler for the exception exits by any means other than throw; the
- temporary object is destroyed and the implementation may
- deallocate the memory for the temporary object;"
- 
- 
- </TD>
- <TD>
- Update
- sentence to allow for exceptions held in excpetion_ptr objects. 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 131
- </TD>
- <TD>
- 15.3
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- A
- handler catching its parameter by rvalue-reference is
- syntactically valid, but will never be activated.
- 
- 
- </TD>
- <TD>
- Disallow
- handlers catching by rvalue-reference.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 132
- </TD>
- <TD>
- 15.3
- </TD>
- <TD>
- 16
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- There
- are obscure cases whrere a copy constructor is not usually the
- best match to copy-initialize an object, e.g. A converting
- constructor template taking arguments by non-const reference. A
- footnote explaining such cases would be helpful, or the sentance
- could be rewritten using copy-initialization instead of directly
- calling a copy constructor.
- 
- 
- </TD>
- <TD>
- Rewite
- using copy-initialization rather than directly invoking the copy
- constructor 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 133
- </TD>
- <TD>
- 15.4
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Template
- aliases have the same semantics as a typedef so should also be
- disallowed
- 
- 
- </TD>
- <TD>
- add
- "or alias-declaration" after "shall not appear in a
- typedef declaration". 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 134
- </TD>
- <TD>
- 15.4
- </TD>
- <TD>
- 6
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- sentance "An exception-specification can also include the
- class std::bad_exception (18.7.2.1)." is redundant.
- 
- 
- </TD>
- <TD>
- Either
- strike the quoted sentance, or add a note explaining why it is
- worth calling special attention to this class. 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 135
- </TD>
- <TD>
- 15.4
- </TD>
- <TD>
- 8
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Unclear
- if std::unexpected is called before or after the function
- arguments have been destroyed
- </TD>
- <TD>
- Clarify
- the sequence of calling unexpected with respect to interesting
- objects, such as function arguments or partially constructed bases
- and members when called from a constructor or destructor 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 136
- </TD>
- <TD>
- 15.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ge
- </TD>
- <TD>
- Exception
- specifications have proven close to worthless in practice, while
- adding a measurable overhead to programs. The feature should be
- deprecated. The one exception to the rule is the empty throw
- specification which could serve a legitimate optimizing role if
- the requirement to call the runtime unexpected mechanism was
- relaxed in this case.
- </TD>
- <TD>
- Move
- 15.4 and the parts of 15.5 that refer to it to Appendix D. Replace
- 15.4 with a simpler specification for empty throw specifications,
- where the std::unexpected call is conditionally supported allowing
- vendors to choose between optimizing and providing runtime checks.
- Ideally require vendors to provide a mode where the runtime checks
- are always disabled. 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 137
- </TD>
- <TD>
- 15.5
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- There
- is no mention of the current_exception API which can extend the
- lifetime of an exception object. There should at least be a
- forward reference to the library clause 18.7.5
- 
- 
- </TD>
- <TD>
- Add
- another paragraph outlining 18.7.5 and the ability of an
- exception_ptr to extend the lifetime of an exception object 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 138
- </TD>
- <TD>
- 15.5.1
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- third bullet is redundant with the first, as it is a subset of the
- same conditions.
- 
- 
- </TD>
- <TD>
- Merge
- the third bullet into the first bullet as a note or example. 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 139
- </TD>
- <TD>
- 15.5.1
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- According
- to the first bullet it is perfectly alright for a library function
- to exit by throwing an exception during stack unwinding, This is
- clearly not true.
- 
- 
- </TD>
- <TD>
- Strike
- the word 'user' from the first bullet point. 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 140
- </TD>
- <TD>
- 15.5.2
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- detailed specification can fool people into thinking an exception
- will automatically be translated into bad_exception, where the
- default behaviour of std::unexcepted is to immediately call
- std::terminate();
- 
- 
- </TD>
- <TD>
- Add
- a note highlighting the default behaviour of std::unexpected if
- the user does not supply a hander-function 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 141
- </TD>
- <TD>
- 15.6
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- This
- whole subclause is redundant due to 15.1p5 and 15.3p17
- 
- 
- </TD>
- <TD>
- Strike
- 15.6 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 142
- </TD>
- <TD>
- 16.3.5
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- This
- paragraph opens with "[ Note" but has no corresponding
- "end note ]"
- 
- 
- </TD>
- <TD>
- Add
- "end note ]"
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 143
- </TD>
- <TD>
- 16.3.5
- </TD>
- <TD>
- 7
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Example
- uses #define t(x,y.z) x ## y ## z
- </TD>
- <TD>
- Change
- "x,y.z" to "x,y,z"
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 2
- </TD>
- <TD>
- 17-30
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ge/te
- </TD>
- <TD>
- 
- The active issues identified
- in WG21 N2806, C++ Standard Library Active Issues, must be
- addressed and appropriate action taken.
- 
- 
- 
- 
- http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html
- 
- 
- </TD>
- <TD>
- Appropriate
- action would include making changes to the CD, identifying an
- issue as not requiring a change to the CD, or deferring the issue
- to a later point in time.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 2
- </TD>
- <TD>
- General
- Comment
- </TD>
- <TD>
- Library
- </TD>
- <TD>
- ge
- </TD>
- <TD>
- The
- adoption of the library `constexpr' proposal was not reflected in
- the draft, despite formal WG21 committee vote.
- </TD>
- <TD>
- FR
- 2
- </TD>
- <TD>
- General
- Comment
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 61
- </TD>
- <TD>
- 17
- onward
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- The
- concepts core language feature is applied to only some of the
- Standard Library clauses, and even then not always consistently.
- </TD>
- <TD>
- Review
- all clauses of the Standard Library, and consistently apply
- concept technology wherever possible and appropriate. The
- proposed wording in WG21 N2781 exemplifies the necessary level of
- detail.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- CA-2
- </TD>
- <TD>
- 17
- Library
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ge
- </TD>
- <TD>
- 
- “Concepts” are a
- significant new addition to the language, but are not exploited
- uniformly in the library as documented in CD 14882.
- </TD>
- <TD>
- 
- Fix the standard library so
- that “Concepts” are used appropriately in the library.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- US
- 62
- </TD>
- <TD>
- 
- 17-30
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- ge
- </TD>
- <TD>
- 
- Provide
- concepts and requirements clauses for all standard library
- templates
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 63
- </TD>
- <TD>
- 17-30
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- The
- behavior of the library in the presence of threads is incompletely
- specified.
- For
- example, if thread 1 assigns to X, then writes data to file f,
- which is read by thread 2, and then accesses variable X, is thread
- 2 guaranteed to be able to see the value assigned to X by thread
- 1? In other words, does the write of the data "happen before"
- the read?
- Another
- example: does simultaneous access using operator at() to different
- characters in the same non-const string really introduce a data
- race?
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- DE-2
- </TD>
- <TD>
- 17
- through 30
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- DE-2
- Marking a constructor with "explicit" has semantics even
- for a constructor with zero or several parameters: Such a
- constructor cannot be used with list-initialization in a
- copy-initialization context, see 13.3.1.7. The standard library
- apparently has not been reviewed for marking non-single-parameter
- constructors as "explicit".
- </TD>
- <TD>
- Consider
- marking zero-parameter and multi-parameter constructors "explicit"
- in classes that have at least one constructor marked "explicit"
- and that do not have an initializer-list constructor.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 21
- </TD>
- <TD>
- 
- 
- 
- 
- 17 Library
- 
- 21.2, 21.4,
- 27.2,
- 27.6, 27.7, 27.8.1, 28.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- Support of char16_t/char32_t
- is insufficient. The basic_xxx classes of <iostream>,
- <fstream>, <regex>, etc. does not have typedefs for
- char16_t/char32_t.
- 
- Functions such as stoi,
- to_string in ‘21.4 Numeric Conversion’ does not
- support char16_t/char32_t types.
- </TD>
- <TD>
- 
- Add commented lines
- corresponding to char16_t, char32_t.
- 
- 
- 
- 
- 21.2 paragraph1 
- 
- 
-  
- 
- namespace std { 
- 
- 
-  ... 
- 
- 
-  
- 
-  // 21.4: numeric
- conversions 
- 
- 
-  ... 
- 
- 
-  
- 
-  int stoi(const
- u16string& str, size_t *idx = 0, int base = 10); 
- 
- 
-  long stol(const
- u16string& str, size_t *idx = 0, int base = 10); 
- 
- 
-  unsigned long
- stoul(const u16string& str, size_t *idx = 0, int base = 10); 
- 
- 
-  long long stoll(const
- u16string& str, size_t *idx = 0, int base = 10); 
- 
- 
-  unsigned long long
- stoull(const u16string& str, size_t *idx = 0, int base = 10); 
- 
- 
-  float stof(const
- u16string& str, size_t *idx = 0); 
- 
- 
-  double stod(const
- u16string& str, size_t *idx = 0); 
- 
- 
-  long double stold(const
- u16string& str, size_t *idx = 0); 
- 
- 
-  u16string
- to_u16string(long long val); 
- 
- 
-  u16string
- to_u16string(unsigned long long val); 
- 
- 
-  u16string
- to_u16string(long double val); 
- 
- 
-  
- 
-   int stoi(const
- u32string& str, size_t *idx = 0, int base = 10); 
- 
- 
-  long stol(const
- u32string& str, size_t *idx = 0, int base = 10); 
- 
- 
-  unsigned long
- stoul(const u32string& str, size_t *idx = 0, int base = 10); 
- 
- 
-  long long stoll(const
- u32string& str, size_t *idx = 0, int base = 10); 
- 
- 
-  unsigned long long
- stoull(const u32string& str, size_t *idx = 0, int base = 10); 
- 
- 
-  float stof(const
- u32string& str, size_t *idx = 0); 
- 
- 
-  double stod(const
- u32string& str, size_t *idx = 0); 
- 
- 
-  long double stold(const
- u32string& str, size_t *idx = 0); 
- 
- 
-  u32string
- to_u32string(long long val); 
- 
- 
-  u32string
- to_u32string(unsigned long long val); 
- 
- 
-  u32string
- to_u32string(long double val); 
- 
- 
- } 
- 
- 
- 
- 
- 
- 27.2 
- 
- 
-  
- 
- namespace std { 
- 
- 
-  ... 
- 
- 
-  typedef basic_ios<char>
- ios; 
- 
- 
-  typedef
- basic_ios<wchar_t> wios; 
- 
- 
-  typedef
- basic_ios<char16_t> u16ios; 
- 
- 
-  typedef
- basic_ios<char32_t> u32ios; 
- 
- 
-  
- 
-  ... 
- 
- 
-  typedef
- basic_ifstream<wchar_t> wifstream; 
- 
- 
-  typedef
- basic_ofstream<wchar_t> wofstream; 
- 
- 
-  typedef
- basic_fstream<wchar_t> wfstream; 
- 
- 
-  
- 
-  typedef
- basic_streambuf<char16_t> u16streambuf; 
- 
- 
-  typedef
- basic_istream<char16_t> u16istream; 
- 
- 
-  typedef
- basic_ostream<char16_t> u16ostream; 
- 
- 
-  typedef
- basic_iostream<char16_t> u16iostream; 
- 
- 
-  
- 
-  typedef
- basic_stringbuf<char16_t> u16stringbuf; 
- 
- 
-  typedef
- basic_istringstream<char16_t> u16istringstream; 
- 
- 
-  typedef
- basic_ostringstream<char16_t> u16ostringstream; 
- 
- 
-  typedef
- basic_stringstream<char16_t> u16stringstream; 
- 
- 
-  typedef
- basic_filebuf<char16_t> u16filebuf; 
- 
- 
-  
- 
-  typedef
- basic_ifstream<char16_t> u16ifstream; 
- 
- 
-  typedef
- basic_ofstream<char16_t> u16ofstream; 
- 
- 
-  typedef
- basic_fstream<char16_t> u16fstream; 
- 
- 
-  
- 
-  typedef
- basic_streambuf<char32_t> u32streambuf; 
- 
- 
-  typedef
- basic_istream<char32_t> u32istream; 
- 
- 
-  typedef
- basic_ostream<char32_t> u32ostream; 
- 
- 
-  typedef
- basic_iostream<char32_t> u32iostream; 
- 
- 
-  
- 
-  typedef
- basic_stringbuf<char32_t> u32stringbuf; 
- 
- 
-  typedef
- basic_istringstream<char32_t> u32istringstream; 
- 
- 
-  typedef
- basic_ostringstream<char32_t> u32ostringstream; 
- 
- 
-  typedef
- basic_stringstream<char32_t> u32stringstream; 
- 
- 
-  typedef
- basic_filebuf<char32_t> u32filebuf; 
- 
- 
-  
- 
-  typedef
- basic_ifstream<char32_t> u32ifstream; 
- 
- 
-  typedef
- basic_ofstream<char32_t> u32ofstream; 
- 
- 
-  typedef
- basic_fstream<char32_t> u32fstream;
- 
- 
- 
-  
- 
-  ... 
- 
- 
-  template <class
- state> class fpos; 
- 
- 
-  typedef
- fpos<char_traits<char>::state_type> streampos; 
- 
- 
-  typedef
- fpos<char_traits<wchar_t>::state_type> wstreampos; 
- 
- 
-  typedef
- fpos<char_traits<char16_t>::state_type> u16streampos;
- 
-  typedef
- fpos<char_traits<char32_t>::state_type> u32streampos;
- 
- } 
- 
- 
- 
- 
- 
- 27.6
- 
-  
- 
- namespace std { 
- 
- 
-  template <class
- charT, class traits = char_traits<charT> > 
- 
- 
-  class basic_istream; 
- 
- 
-  typedef
- basic_istream<char> istream; 
- 
- 
-  typedef
- basic_istream<wchar_t> wistream; 
- 
- 
-  typedef
- basic_istream<char16_t> u16istream;
- 
-  typedef
- basic_istream<char32_t> u32istream;
- 
-  
- 
-  template <class
- charT, class traits = char_traits<charT> > 
- 
- 
-  class basic_iostream; 
- 
- 
-  typedef
- basic_iostream<char> iostream; 
- 
- 
-  typedef
- basic_iostream<wchar_t> wiostream; 
- 
- 
-  typedef
- basic_iostream<char16_t> u16iostream;
- 
-  typedef
- basic_iostream<char32_t> u32iostream;
- 
- } 
- 
- 
-  
- 
- namespace std { 
- 
- 
-  template <class
- charT, class traits = char_traits<charT> > 
- 
- 
-  class basic_ostream; 
- 
- 
-  typedef
- basic_ostream<char> ostream; 
- 
- 
-  typedef
- basic_ostream<wchar_t> wostream; 
- 
- 
-  typedef
- basic_ostream<char16_t> u16ostream;
- 
-  typedef
- basic_ostream<char32_t> u32ostream;
- 
- } 
- 
- 
- 
- 
- 
- 27.7 paragraph 1 
- 
- 
-  
- 
- namespace std { 
- 
- 
-  template <class
- charT, class traits = char_traits<charT>, 
- 
- 
-      class
- Allocator = allocator<charT> > 
- 
- 
-  class basic_stringbuf; 
- 
- 
-  
- 
-  typedef
- basic_stringbuf<char> stringbuf; 
- 
- 
-  typedef
- basic_stringbuf<wchar_t> wstringbuf; 
- 
- 
-  typedef
- basic_stringbuf<char16_t> u16stringbuf;
- 
-  typedef
- basic_stringbuf<char32_t> u32stringbuf;
- 
-  
- 
-  template <class
- charT, class traits = char_traits<charT>, 
- 
- 
-      class
- Allocator = allocator<charT> > 
- 
- 
-  class
- basic_istringstream; 
- 
- 
-  
- 
-  typedef
- basic_istringstream<char> istringstream; 
- 
- 
-  typedef
- basic_istringstream<wchar_t> wistringstream; 
- 
- 
-  typedef
- basic_istringstream<char16_t> u16istringstream;
- 
-  typedef
- basic_istringstream<char32_t> u32istringstream;
- 
-  
- 
-  template <class
- charT, class traits = char_traits<charT>, 
- 
- 
-      class
- Allocator = allocator<charT> > 
- 
- 
-  class
- basic_ostringstream; 
- 
- 
-  
- 
-  typedef
- basic_ostringstream<char> ostringstream; 
- 
- 
-  typedef
- basic_ostringstream<wchar_t> wostringstream; 
- 
- 
-  typedef
- basic_ostringstream<char16_t> u16ostringstream;
- 
-  typedef
- basic_ostringstream<char32_t> u32ostringstream;
- 
-  
- 
-  template <class
- charT, class traits = char_traits<charT>, 
- 
- 
-      class
- Allocator = allocator<charT> > 
- 
- 
-  class
- basic_stringstream; 
- 
- 
-  
- 
-  typedef
- basic_stringstream<char> stringstream; 
- 
- 
-  typedef
- basic_stringstream<wchar_t> wstringstream; 
- 
- 
-  typedef
- basic_stringstream<char16_t> u16stringstream;
- 
-  typedef
- basic_stringstream<char32_t> u32stringstream;
- 
- } 
- 
- 
- 
- 
- 
- 27.8.1 paragraph 1
- 
-
- 
- 
- namespace std { 
- 
- 
-  template <class
- charT, class traits = char_traits<charT> > 
- 
- 
-  class basic_filebuf; 
- 
- 
-  typedef
- basic_filebuf<char> filebuf; 
- 
- 
-  typedef
- basic_filebuf<wchar_t> wfilebuf; 
- 
- 
-  typedef
- basic_filebuf<char16_t> u16filebuf;
- 
-  typedef
- basic_filebuf<char32_t> u32filebuf;
- 
-  
- 
-  template <class
- charT, class traits = char_traits<charT> > 
- 
- 
-  class basic_ifstream; 
- 
- 
-  typedef
- basic_ifstream<char> ifstream; 
- 
- 
-  typedef
- basic_ifstream<wchar_t> wifstream; 
- 
- 
-  typedef
- basic_ifstream<char16_t> u16ifstream;
- 
-  typedef
- basic_ifstream<char32_t> u32ifstream;
- 
-  
- 
-  template <class
- charT, class traits = char_traits<charT> > 
- 
- 
-  class basic_ofstream; 
- 
- 
-  typedef
- basic_ofstream<char> ofstream; 
- 
- 
-  typedef
- basic_ofstream<wchar_t> wofstream; 
- 
- 
-  typedef
- basic_ofstream<char16_t> u16ofstream;
- 
-  typedef
- basic_ofstream<char32_t> u32ofstream;
- 
-  
- 
-  template <class
- charT, class traits = char_traits<charT> > 
- 
- 
-  class basic_fstream; 
- 
- 
-  typedef
- basic_fstream<char> fstream; 
- 
- 
-  typedef
- basic_fstream<wchar_t> wfstream; 
- 
- 
-  typedef
- basic_fstream<char16_t> u16fstream;
- 
-  typedef
- basic_fstream<char32_t> u32fstream;
- 
- } 
- 
- 
- 
- 
- 
- 28.4 
- 
- 
-  
- 
- namespace std { 
- 
- 
-  ... 
- 
- 
-  typedef
- basic_regex<char> regex; 
- 
- 
-  typedef
- basic_regex<wchar_t> wregex; 
- 
- 
-  typedef
- basic_regex<char16_t> u16regex;
- 
-  typedef
- basic_regex<char32_t> u32regex;
- 
-  
- 
-  ... 
- 
- 
-  typedef sub_match<const
- char*> csub_match; 
- 
- 
-  typedef sub_match<const
- wchar_t*> wcsub_match; 
- 
- 
-  typedef sub_match<const
- char16_t*> u16csub_match;
- 
-  typedef sub_match<const
- char32_t*> u16csub_match;
- 
-  typedef
- sub_match<string::const_iterator> ssub_match; 
- 
- 
-  typedef
- sub_match<wstring::const_iterator> wssub_match; 
- 
- 
-  typedef
- sub_match<u16string::const_iterator> u16ssub_match;
- 
-  typedef
- sub_match<u32string::const_iterator> u32ssub_match;
- 
-  
- 
-  ... 
- 
- 
-  typedef
- match_results<const char*> cmatch; 
- 
- 
-  typedef
- match_results<const wchar_t*> wcmatch; 
- 
- 
-  typedef
- match_results<const char16_t*> u16cmatch;
- 
-  typedef
- match_results<const char32_t*> u32cmatch;
- 
-  typedef
- match_results<string::const_iterator> smatch; 
- 
- 
-  typedef
- match_results<wstring::const_iterator> wsmatch; 
- 
- 
-  typedef
- match_results<u16string::const_iterator> u16smatch;
- 
-  typedef
- match_results<u32string::const_iterator> u32smatch;
- 
-  
- 
-  ... 
- 
- 
-  typedef
- regex_iterator<const char*> cregex_iterator; 
- 
- 
-  typedef
- regex_iterator<const wchar_t*> wcregex_iterator; 
- 
- 
-  typedef
- regex_iterator<const cha16r_t*>
- u16cregex_iterator;
- 
-  typedef
- regex_iterator<const char32_t*>
- u32cregex_iterator;
- 
-  typedef
- regex_iterator<string::const_iterator> sregex_iterator; 
- 
- 
-  typedef
- regex_iterator<wstring::const_iterator> wsregex_iterator; 
- 
- 
-  typedef
- regex_iterator<u16string::const_iterator>
- u16sregex_iterator;
- 
-  typedef
- regex_iterator<u32string::const_iterator>
- u32sregex_iterator;
- 
-  
- 
-  ... 
- 
- 
-  typedef
- regex_token_iterator<const char*>
- cregex_token_iterator; 
- 
- 
-  typedef
- regex_token_iterator<const wchar_t*>
- wcregex_token_iterator; 
- 
- 
-  typedef
- regex_token_iterator<const char16_t*>
- u16cregex_token_iterator;
- 
-  typedef
- regex_token_iterator<const char32_t*>
- u32cregex_token_iterator;
- 
-  typedef
- regex_token_iterator<string::const_iterator>
- sregex_token_iterator; 
- 
- 
-  typedef
- regex_token_iterator<wstring::const_iterator>　　　wsregex_token_iterator;
- 
- 
- 
-  typedef
- regex_token_iterator<u16string::const_iterator>
- u16sregex_token_iterator;
- 
-  typedef
- regex_token_iterator<u32string::const_iterator>　u32sregex_token_iterator;
- 
- 
- 
- } 
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 144
- </TD>
- <TD>
- 17.1
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- List
- of contents of library should be extened to cover new clauses
- </TD>
- <TD>
- Add
- "regular expressions, atomic operations and threads" 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 145
- </TD>
- <TD>
- 17.1
- </TD>
- <TD>
- 6
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- 
- Summary
- of numeric facilities should mention random numbers
- 
- 
- </TD>
- <TD>
- Add
- random number framework to the list of library facilities
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 146
- </TD>
- <TD>
- 17.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Add
- a summary paragraph for regular expressions
- </TD>
- <TD>
- Add
- a summary paragraph for regular expressions 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 147
- </TD>
- <TD>
- 17.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Add
- a summary paragraph for threads
- </TD>
- <TD>
- Add
- a summary paragraph for threads 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 148
- </TD>
- <TD>
- 17.2
- </TD>
- <TD>
- Table
- 12
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Table
- 12 is mentioned in and relates to section 17.2, but has been
- pushed down to appear directly after the title of section 17.3
- which is rather unfortunate/confusing for the reader.
- 
- 
- </TD>
- <TD>
- Make
- sure tables are rendered in the section to which they relate.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 149
- </TD>
- <TD>
- 17.3
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- For
- consistency with narrow-oriented and wide-oriented streams, we
- should add terms for streams of Unicode character sequences
- 
- 
- </TD>
- <TD>
- Define
- Utf16-oriented stream classes and Uft32-oriented stream classes
- for streams of char16_t/char32_t values.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 150
- </TD>
- <TD>
- 17.3
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- addition of move semantics to the language means that many library
- APIs leave an object in a safely-destructible state, where no
- other operations can safely be performed unless it is assigned a
- new value. Library presentation would be simplified and made more
- precise if we introduce a term for this state. By analogy with
- singular iterators suggest the term 'singular object' or 'the
- object is in a singular state'.
- </TD>
- <TD>
- Define
- 'singular state' such that an object with a singular state can
- only be assigned to or safely destroyed. Assiging a new value
- typically removes the singular state. Note that objects with a
- singular state may not be safely copied, so you cannot put an
- object into a singular state by copying another object in a
- singular state. Use this new term in the postcondition of all
- library APIs that move from an rvalue reference. It might also be
- used to simplify the definition of singular iterator to an
- iterator value with a singular state.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 151
- </TD>
- <TD>
- 17.3.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Missing
- crossreference to 17.3.17 [defns.repositional.stream]
- 
- 
- </TD>
- <TD>
- Add
- cross-reference in the existing empty brackets 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 152
- </TD>
- <TD>
- 17.3.12
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Object
- state is using a definition of object (instance of a class) from
- outside the standard, rather than the 'region of storage'
- definiton in 1.8p1
- 
- 
- </TD>
- <TD>
- Clarify
- terms and usage
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 153
- </TD>
- <TD>
- 17.3.17
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- If
- a repositional stream can only seek to a position previously
- encountered, then an arbitrary-positional-stream cannot satisfy
- this definition, as cross-referenced in 17.3.17
- 
- 
- </TD>
- <TD>
- Strike
- the word 'only'. A note might be added to reinforce the intent 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- UK 154
- 
- 
- </TD>
- <TD>
- 17.3.20
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Missing
- definition of a stable partition algorithm
- </TD>
- <TD>
- Add
- definition from 25.2.12p7 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 155
- </TD>
- <TD>
- 17.3.3
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Add
- clause 28 to list that use this definition of character
- </TD>
- <TD>
- Add
- clause 28 to list that use this definition of character 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 156
- </TD>
- <TD>
- 17.3.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Add
- regular expressions to set of templates using character container
- type
- 
- 
- </TD>
- <TD>
- Add
- regular expressions to set of templates using character container
- type 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 157
- </TD>
- <TD>
- 17.5.2.2
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Add
- concepts to the ordered list of presentation
- 
- 
- 
- 
- </TD>
- <TD>
- Add
- concepts into the sequence
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 158
- </TD>
- <TD>
- 17.5.2.2
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- templates
- are neither classes nor functions
- </TD>
- <TD>
- Replace
- 'classes' and 'functions' with 'classes and class templates' and
- 'functions and function templates' 
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 159
- </TD>
- <TD>
- 17.5.2.4
- </TD>
- <TD>
- Footnote
- 152
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- This
- informative footnote was relevant in 1998, not 2008. The term
- 'existing vendors' may imply something different now
- 
- 
- </TD>
- <TD>
- Strike
- the footnote, or replace 'existing' with 'original' or similar 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 160
- </TD>
- <TD>
- 17.5.2.4
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- requires
- is now a keyword with a specific meaning related to concepts, and
- its use in library specifcation may be confusing. Generally the
- Requires clause is used to make requirements on the caller, not
- the library, so typically providing runtime pre-conditions.
- Suggest a new name to refflect that. Note that Clause 30 already
- seems to be written to this convention.
- 
- 
- </TD>
- <TD>
- Replace
- 'Requires' with 'Preconditions' 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 161
- </TD>
- <TD>
- 17.5.2.4
- </TD>
- <TD>
- 4
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- This
- paragraph is redundant as the definition of the term 'handler
- function' is already provided in 17.3. Are we in danger of proving
- two definitions of the same terms? Which is the 'controlling'
- definition?
- 
- 
- </TD>
- <TD>
- Strike
- 17.5.2.4p4 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 162
- </TD>
- <TD>
- 17.5.2.4
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Clause
- 30 makes use of a 'Synchronization' semantic element, that
- frequently appears either between Effects: and Postconditions:, or
- between Returns: and Throws:
- 
- 
- </TD>
- <TD>
- Add
- 'Synchronization' to the list either between Effects: and
- Postconditions:, or between Returns: and Throws:.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 163
- </TD>
- <TD>
- 17.5.2.4
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Many
- functions are defined as "Effects: Equivalent to a...",
- which seems to also define the preconditions, effects, etc. But
- this is not made clear.
- 
- 
- </TD>
- <TD>
- Introduce
- an explicit "Equivalent to", which defines all of the
- properties of the function.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 164
- </TD>
- <TD>
- 17.5.3.2.1
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- This
- phrasing predates concepts. While this kind of description is
- still used, the examples provided are now all concepts, and should
- be replaced with appropriate examples
- </TD>
- <TD>
- Use
- better names for the examples. Ideally totally replace the need by
- constraining all templates in library, so that real concepts are
- all that is needed. Note if retained that CopyConstructible is
- mis-spelled.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 165
- </TD>
- <TD>
- 17.5.3.2.2,
- 17.5.3.2.3
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- constraints
- on bitmask and enumation types were supposed to be tightened up as
- part of the motivation for the constexpr feature - see paper n2235
- for deails
- 
- 
- </TD>
- <TD>
- Adopt
- wording in line with the motivation described in N2235 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 166
- </TD>
- <TD>
- 17.5.3.2.4.1,
- 17.5.3.3
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- List
- of library clauses should go up to 30, not 27
- </TD>
- <TD>
- Replace
- initial refernce to ch27 with ch30 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 167
- </TD>
- <TD>
- 17.5.3.4
- Private members
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Comment
- marker in wrong place.
- </TD>
- <TD>
- Change:
- // streambuf* sb; exposition only to streambuf* sb; // exposition
- only To reflect actual usage.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 168
- </TD>
- <TD>
- 17.6.2.2
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- We
- should make it clear (either by note or normatively) that
- namespace std may contain inline namespaces, and that entities
- specified to be defined in std may in fact be defined in one of
- these inline namespaces. (If we're going to use them for
- versioning, eg when TR2 comes along, we're going to need that.)
- 
- 
- </TD>
- <TD>
- Replace
- "namespace std or namespaces nested within namespace std"
- with "namespace std or namespaces nested within namespace std
- or inline namespaces nested directly or indirectly within
- namespace std"
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 169
- </TD>
- <TD>
- 17.6.2.2
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- This
- phrasing contradicts later freedom to implement the C standard
- library portions in the global namespace as well as std.
- (17.6.2.3p4)
- 
- 
- </TD>
- <TD>
- Resolve
- conflict in either place
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 170
- </TD>
- <TD>
- 17.6.2.3
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- One
- of goals of C++0x is to make language easier to teach and for
- 'incidental' programmers. The fine-grained headers of the C++
- library are valuable in large scale systems for managing
- dependencies and optimising build times, but overcomplicated for
- simple development and tutorials. Add additional headers to
- support the whole library through a single include statement.
- 
- 
- </TD>
- <TD>
- Add
- a new header <std> that has the effect of including
- everything in tables 13 and 14, except <iosfwd> and
- <cassert>. Add an additional header <fwd> that adds
- all declarations from <std> but no definitions. 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 171
- </TD>
- <TD>
- 17.6.2.4
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Does
- freestanding implementation require a full implementation of all
- listed headers? The reference to abort, at_exit and exit is
- confusing. Is a conforming implementation allow to deliver partial
- forms of these headers? If so which ones? Are empty versions of
- everything but <cstdlib> conforming?
- 
- 
- </TD>
- <TD>
- Either
- strike the references to abort, at_exit and exit, or clarify which
- headers only require partial support.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 172
- </TD>
- <TD>
- 17.6.2.4
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- No
- reference to new functions quick_exit and at_quick_exit
- 
- 
- </TD>
- <TD>
- Add
- reference to quick_exit and at_quick_exit 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 173
- </TD>
- <TD>
- 17.6.2.4
- </TD>
- <TD>
- table
- 15
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- <initializer_list>
- is missing from headers required in freestanding implementations.
- 
- 
- </TD>
- <TD>
- Add
- 18.8, initializer lists, <initializer_list>, to the end of
- the table.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 23
- </TD>
- <TD>
- 17.6.2.4
- </TD>
- <TD>
- 2nd
- paragraph, Table 15
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- There is a freestanding
- implementation including <type_traits>, <array>,
- <ratio>, lately added to Table 13, C++ library
- headers. Programmers think them useful and hope that these
- headers are also added to Table 15, C++ headers for freestanding
- implementations, that shows the set of headers which a
- freestanding implementation shall include at least.
- 
- 
- 
- </TD>
- <TD>
- 
- Add <type_traits>,
- <array>, <ration> to Table 15.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 174
- </TD>
- <TD>
- 17.6.3.2
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- phrasing is mildly ambiguous when using the word 'it' to refer
- back to the header - an unfotunate reading might confuse it with
- the translate unit, which is the subject of the surrounding
- clause.
- 
- 
- </TD>
- <TD>
- Replace
- 'the first reference to any of the entities declared in that
- header by the translation unit' with 'the first reference to any
- of the entities that header declares in the translation unit' 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 175
- </TD>
- <TD>
- 17.6.4.2.1
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Local
- types can now be used to instantiate templates, but don't have
- external linkage
- 
- 
- </TD>
- <TD>
- Remove
- the reference to external linkage 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 176
- </TD>
- <TD>
- 17.6.4.3.3
- </TD>
- <TD>
- Footnote
- 175
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Reference
- to namespace ::std should be 17.6.4.2
- </TD>
- <TD>
- Change
- referfence from 17.6.4.3 to 17.6.4.2 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 177
- </TD>
- <TD>
- 17.6.4.3.4
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Sentence
- is redundant as double underscores are reserved in all contexts by
- 17.6.4.3.3
- 
- 
- </TD>
- <TD>
- Strike
- the sentence 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 178
- </TD>
- <TD>
- 17.6.4.8
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- last sentence of the third bullet "Operations on such types
- can report a failure by throwing an exception unless otherwise
- specified" is redundant as behaviour is already undefined.
- </TD>
- <TD>
- Strike
- the sentence 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 179
- </TD>
- <TD>
- 17.6.4.8
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- According
- to the 4th bullet there is a problem if "if any replacement
- function or handler function or destructor operation throws an
- exception". There should be no problem throwing exceptions so
- long as they are caught within the function.
- 
- 
- </TD>
- <TD>
- Replace
- the word 'throws' with 'propogates' 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 22
- </TD>
- <TD>
- 17.6.5.7
- </TD>
- <TD>
- 4th
- paragraph, 1st
- line
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- The statement below describes
- relation among two or more threads using words “between
- threads”: [Note: This means, for example, that
- implementations can’t use a static object for internal
- purposes without synchronization because it could cause a data
- race even in programs that do not explicitly share objects between
- threads. —end note ]
- 
- In such case, “among”
- is preferred instead of “between”.
- </TD>
- <TD>
- 
- Change "between threads"
- to "among threads".
- 
- There are same cases in 17.6.1
- paragraph 2, 17.6.5.7 paragraph 6, 30.1 paragraph 1, 30.3.1
- paragraph 1 also.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 180
- </TD>
- <TD>
- 17.6.5.10
- </TD>
- <TD>
- 1,
- 4
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- It
- should not be possible to strengthen the exception specification
- for virtual functions as this could break user code. Note this is
- not a problem in practice as there are no virtual functions with
- exception specifications in the current library, other than empty
- throw specifications which it is not possible to strengthen.
- 
- 
- </TD>
- <TD>
- Add
- restriction that exception specification of virtual functions
- cannot be tightened.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 181
- </TD>
- <TD>
- 17.6.5.10
- </TD>
- <TD>
- Footnote
- 186
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- This
- footnote is wrong. C library functions do not have any exception
- specification, but might be treated as if they had an empty throw
- specification
- 
- 
- </TD>
- <TD>
- Clarify
- that this note does not mean the functions are genuinely declared
- with the specification, but are treated as-if. 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 182
- </TD>
- <TD>
- 17.6.5.10
- </TD>
- <TD>
- Footnote
- 188
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- It
- is very helpful to assume all exceptions thrown by the standard
- library derive from std::exception. The 'encouragement' of this
- note should be made normative.
- 
- 
- </TD>
- <TD>
- Make
- this footnote normative
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 184
- </TD>
- <TD>
- 18
- -> 30
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- new alias-declaration syntax is generally easier to read than a
- typedef declaration. This is especially true for complex types
- like function pointers.
- 
- 
- </TD>
- <TD>
- Replace
- all typedef declarations in the standard library with
- alias-declarations, except in the standard C library.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 24
- </TD>
- <TD>
- 18
- </TD>
- <TD>
- 2nd
- paragraph, Table 16
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- Subclauses are listed in Table
- 16 as:
- 
- "18.6 Type identification
- …"
- 
- "18.8 Initializer lists
- …"
- 
- "18.7 Exception handling
- …".
- </TD>
- <TD>
- 
- Sort them in the increasing
- order "18.6 Type identification …"
- 
- "18.7 Exception handling
- …".
- 
- "18.8 Initializer lists
- …"
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 25
- </TD>
- <TD>
- 18.1
- </TD>
- <TD>
- 
- 6th
- paragraph , last line, SEE ALSO
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- max_align_t is described in
- 18.1, so add 3.11 Alignment as the reference.
- </TD>
- <TD>
- 
- Add
- "3.11,
- Alignment"
- to SEE ALSO.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 32
- </TD>
- <TD>
- 18.2.1
- [Numeric limits]
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- The
- definition of numeric_limits<> as requiring a regular type
- is both conceptually wrong and operationally illogical. As we
- pointed before, this mistake needs to be corrected. For example,
- the template can be left unconstrained. In fact this reflects a
- much more general problem with concept_maps/axioms and their
- interpretations. It appears that the current text heavily leans
- toward experimental academic type theory.
- 
- 
- </TD>
- <TD>
- We
- suggest that a more pragmatic approach, in the spirit of C and
- C++, be taken so that calls to constrained function templates are
- interpreted as assertions on *values*, not necessarily semantics
- assertions on the carrier type.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- DE-16
- </TD>
- <TD>
- 18.2.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- DE-16
- The class template numeric_limits
- should not specify the Regular
- concept requirement for its template parameter, because it
- contains functions returning NaN values for floating-point types;
- these values violate the semantics of EqualityComparable.
- See also library issue 902 in WG21 document N2794 "C++
- Standard Library Active Issues List (Revision R60)",
- available at
- http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2794.html
- .
- 
- 
- </TD>
- <TD>
- Specify
- a concept requirement with fewer constraints as appropriate, for
- example SemiRegular.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 26
- </TD>
- <TD>
- 18.2.1.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- numeric_limits does not use
- concept.
- </TD>
- <TD>
- 
- Correct as follows.
- 
- 
- 
- 
- template<class T> class
- numeric_limits<const T>;
- 
- template<class T> class
- numeric_limits<volatile T>;
- 
- template<class T> class
- numeric_limits<const volatile T>;
- 
- 
- 
- 
- should be
- 
- 
- 
- 
- template<Regular
- T> class numeric_limits<const T>;
- 
- template<Regular
- T> class numeric_limits<volatile T>;
- 
- template<Regular
- T> class numeric_limits<const volatile T>;
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- DE-17
- </TD>
- <TD>
- 18.2.6
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- DE-17
- The class type_index
- should be removed; it provides no additional functionality beyond
- providing appropriate concept maps.
- 
- 
- </TD>
- <TD>
- Specify
- concept maps for "const type_info *" as required by the
- ordered and unordered containers and remove the class type_index.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 185
- </TD>
- <TD>
- 18.3.1
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- There
- is no header <stdint>, it should either be <stdint.h>
- or <cstdint>
- 
- 
- </TD>
- <TD>
- Replace
- <stdint> with <cstdint>
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- DE-18
- </TD>
- <TD>
- 18.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- DE-18
- The proposed C++ standard makes a considerable number of existing
- programs that have well-defined behavior according to ISO/IEC
- 14882:2003 have undefined behavior without a diagnostic hint to
- the programmer at all. This applies to the presence of threads and
- to pointer safety (the latter was introduced to support garbage
- collection). In order to avoid requiring a full code review for
- user code, facilities should be present that allow the
- compile-time detection of the advanced features of the proposed
- C++ standard. It is expected that C++ implementations will provide
- a means (for example, a command-line switch) to turn off either or
- both of threads and garbage collection support, turning
- potentially undefined programs into well-defined ones. Note:
- This issue is contributing significantly to Germany's overall
- “no” vote.
- 
- 
- </TD>
- <TD>
- Consider
- applying the changes proposed in WG21 document N2693 "Requirements
- on programs and backwards compatibility", available at
- http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2693.html
- .
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 186
- </TD>
- <TD>
- 18.4
- </TD>
- <TD>
- Footnote
- 221
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- What
- is the purpose of this comment? The standard stream objects (cin,
- cerr etc.) have a peculiar lifetime that extends beyond the
- program. They may never be destroyed so will not be responsible
- for flushing buffers at the stated time.
- 
- 
- </TD>
- <TD>
- Remove
- the footnote
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 187
- </TD>
- <TD>
- 18.4
- </TD>
- <TD>
- 9
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- term "thread safe" is not defined nor used in this
- context anywhere else in the standard.
- 
- 
- </TD>
- <TD>
- Clarify
- the intended meaing of "thread safe"
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 188
- </TD>
- <TD>
- 18.4
- </TD>
- <TD>
- 12
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- function _Exit does not appear to be defined in this standard.
- Should it be added to the table of functions included-by-reference
- to the C standard?
- 
- 
- </TD>
- <TD>
- Depends
- on where _Exit comes from
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 189
- </TD>
- <TD>
- 18.4,
- 18.7
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- addition of the [[noreturn]] attribute to the language will be an
- important aid for static analysis tools.
- </TD>
- <TD>
- The
- following functions should be declared in C++ with the
- [[noreturn]] attribute: abort exit quick_exit terminate unexpected
- rethrow_exception throw_with_nested
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 27
- </TD>
- <TD>
- 18.4,
- 18.9, 18.7.2.2, 18.7.3.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- There are Standard library
- functions that never return to the caller. They are explained so
- in the Standard but not declared explicitly.
- </TD>
- <TD>
- 
- Consider to add the attribute
- [[noreturn]] to such functions, 
- 
- 
- 
- 
- 
- 15.5.2 unexpected 18.4:
- abort(), exit(), quick_exit, 18.7.2.2: unexpected_handler, 
- 18.7.3.1: terminate_handler, 
- 
- 
- 18.7.6 rethrow_nested
- 
- 18.7.6 throw_with_nested 
- 18.9: longjmp.
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 190
- </TD>
- <TD>
- 18.5.1
- </TD>
- <TD>
- various
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- It
- is not entirely clear how the current specification acts in the
- presence of a garbage collected implementation.
- </TD>
- <TD>
- All
- deallocation functions taking a pointer parameter should have a
- Precondition : ptr is a safely-derived pointer value.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 191
- </TD>
- <TD>
- 18.5.1.1
- </TD>
- <TD>
- 4
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- According
- to the second bullet, behaviour becomes undefined (for lack of a
- specification) if the user has not yet called set_new_handler.
- </TD>
- <TD>
- Rephrase
- the second bullet in terms of a new handler being installed, and
- update any definition of handler function necessary to be sure the
- term 'installed' is defined.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 192
- </TD>
- <TD>
- 18.5.1.2
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- declared signature is not compatible with the current requirement
- to throw std::length_error. It is too late to weaken the exception
- specification, so the only other change is to preserve new
- (improved) behaviour is to throw std::bad_alloc, or something
- derived from std::bad_alloc.
- 
- 
- </TD>
- <TD>
- Fix
- 5.3.4p7 by required std::bad_alloc rather than std::length_error
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 193
- </TD>
- <TD>
- 18.5.2.2
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- quick_exit
- has been added as a new valid way to terminate a program in a well
- defined way
- 
- 
- </TD>
- <TD>
- Change
- 3rd bullet: call either abort(), exit() or quick_exit();
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 194
- </TD>
- <TD>
- 18.6
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- inclusion of type_index and hash<type_index> in <typeinfo>
- brings dependencies into <typeinfo> which are inconsistent
- with the definition of freestanding C++ in 17.6.2.4.
- 
- 
- </TD>
- <TD>
- Move
- type_index and hash<type_index> out of <typeinfo> and
- into a new header, <typeindex>.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 28
- </TD>
- <TD>
- 18.6,
- 18.7, 19.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- Errors
- reported by Exception classes are of types char or std::string
- only. For
- example, std::exception is declared with char, std::string types,
- therefore types wchar_t/wstring, char16_t/u16string, or
- char32_t/u32string can not be used.
- 
- 
- </TD>
- <TD>
- 
- Consider other types.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 29
- </TD>
- <TD>
- 18.7.6
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- throw_with_nested does not use
- concept.
- </TD>
- <TD>
- 
- Correct as follows.
- 
- template<class T> void
- throw_with_nested(T&& t); // [[noreturn]]
- 
- 
- 
- 
- should be
- 
- 
- 
- 
- template<CopyConstructible
- T> void throw_with_nested(T&& t); // [[noreturn]]
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 30
- </TD>
- <TD>
- 18.7.6
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- To handle nested exceptions
- strictly, error information of tree structure will be required
- though, the nested_exception does not support tree structure. It
- is insufficient as error handling.
- </TD>
- <TD>
- 
- Consider nested_exception to
- support tree structure.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 31
- </TD>
- <TD>
- 18.7.6
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- It is difficult to understand
- in which case nested_exception is applied.
- </TD>
- <TD>
- 
- Consider to add a sample
- program which rethrows exception.
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 195
- </TD>
- <TD>
- 18.8
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- class definition of std::initializer_list contains concept-maps to
- Range which should be out of the class, and in <iterator_concepts>
- instead. Otherwise, it's not possible to use initializer_lists in
- a freestanding C++ implementation.
- 
- 
- </TD>
- <TD>
- Delete
- the two concept maps from std::initializer_list.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 196
- </TD>
- <TD>
- 18.8.3
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Concept
- maps for initializer_list to Range should not be in language
- support headers, but instead in iterator concepts.
- </TD>
- <TD>
- Remove
- section 18.8.3 and put it in 24.1.8.1 instead, so that the
- concept_maps from initializer_list to Range are specified under
- Range instead of under initializer lists; also, so that they're
- implemented in <iterator_concepts> instead of
- <initializer_list>.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 197
- </TD>
- <TD>
- 19
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- All
- the exception classes in this clause take a std::string argument
- by const reference. They should all be overloaded to accept
- std::string by rvalue rerefence for an efficient move as well.
- </TD>
- <TD>
- Provide
- a constructor for every exception class in clause 19 accepting a
- std::string by rvalue reference, with the semantics that the
- passed string may be moved.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 32
- </TD>
- <TD>
- 19.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- Messages returned by the
- member function what() of standard exception classes seem
- difficult to judge.
- 
- For example, following
- messages are returned by what() of std::bad_alloc of existing
- implementations:
- 
- 
- 
- 
- Compiler: Message
- returned by what()
- 
- ---------------------------------------------
- 
- Borland C++ 5.6.4: no named
- exception thrown
- 
- Visual C++ 8.0: bad
- allocation
- 
- Code Warrior 8.0: exception
- 
- g++ 3.4.4:
- St9exception
- 
- 
- 
- 
- It is difficult to recognize
- what exception was thrown when using those compilers except Visual
- C++.
- 
- 
- 
- </TD>
- <TD>
- 
- Consider to add footnote that
- recommends what() returns message easy to recognize what exception
- was thrown.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 64
- </TD>
- <TD>
- 19.3
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Ge
- </TD>
- <TD>
- “ See
- also: ISO C 7.1.4, 7.2,
- Amendment 1 4.3.”
- It is unclear why this cross reference is here. Amendment 1 was to
- C89, not C99.
- </TD>
- <TD>
- Delete
- this cross reference. If necessary, expand the main text to
- include the relevant referenced text
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 65
- </TD>
- <TD>
- 20
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- Scoped
- allocators and allocator propagation traits add a small amount of
- utility at the cost of a great deal of machinery. The machinery is
- user visible, and it extends to library components that don't have
- any obvious connection to allocators, including basic concepts and
- simple components like pair and tuple.
- </TD>
- <TD>
- 
- Sketch of proposed resolution:
- Eliminate scoped allocators, replace allocator propagation traits
- with a simple uniform rule (e.g. always propagate on copy and
- move), remove all mention of allocators from components that don't
- explicitly allocate memory (e.g. pair), and adjust container
- interfaces to reflect this simplification. 
- 
- 
- Components
- that I propose eliminating include 
- HasAllocatorType?,
- is_scoped_allocator, allocator_propagation_map,
- scoped_allocator_adaptor, and 
- ConstructibleAsElement?.
- 
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 198
- </TD>
- <TD>
- 20
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- organization of clause 20 could be improved to better group
- related items, making the standard easier to navigate.
- </TD>
- <TD>
- 20.6.7,
- 20.6.8, 20.6.9 and 20.6.10 should be grouped under a section
- called "operator wrappers" or similar. The goal of all 4
- subsections combined is to provide a functor for every operator in
- the language. 20.6.17 class template hash should numerically
- appear immediately after the operator wrappers, as they are
- functors that are used in similar ways 20.6.11, 20.6.12, 20.6.13,
- 20.6.14, 20.6.15 are strongly related to 20.6.3, and to an extent
- 20.6.2. These should all come under a subheading of "function
- adapters" 20.7.1, 20.7.3, 20.7.4, 20.7.5, 20.7.6, 20.7.7 and
- 20.7.10 should all be grouped as subclauses under [20.7.2
- Allocators] [20.7.12 unique_ptr] should be a sub-section of
- [20.7.13 smart pointers] [20.7.13 smart pointers] is important
- enough to have a high level bullet after [20.7 memory], suggest
- renumbering as [20.8 smart pointers] [20.7.13.7 Pointer safety] is
- nothing to do with smart pointers and should become its own
- subclause [20.7.14 Pointer safety] [20.9 date and time functions]
- should be moved under [20.8 time utilities] and retitled [20.8.6 C
- Library] (as per memory management/C Library) [20.6.18
- reference_closure] is fundamentally a language support feature and
- should move to clause 18, see separate comment [20.6.5
- reference_wrapper] should be simplified and moved into [2.2
- utility components], see separate comment [20.6.4 result_of]
- should be reorganised as a type trait - see separate comment
- Tuples and pairs are closely related so merge tuple and pair into
- the same subclause - see more general comment on this 
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 199
- </TD>
- <TD>
- 20.1.1,
- 20.1.2
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- requirement that programs do not supply concept_maps should
- probably be users do not supply their own concept_map
- specializations. THe program will almost certainly supply
- concept_maps - the standard itself supplies a specialization for
- RvalueOf? references. Note that the term _program_ is defined in
- 3.5p1 and makes no account of the standard library being treated
- differently to user written code.
- 
- 
- </TD>
- <TD>
- Replace
- the term 'program' with 'user'.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 200
- </TD>
- <TD>
- 20.1.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- All
- standard library use expects Predicates to be CopyConstructible,
- and this should be recognised easily without reatedly stating on
- every use-case.
- </TD>
- <TD>
- Either
- require CopyConstructible<F> as part of Predicate, or create
- a refined concept, StdPredicate, used throughout the library that
- requires CopyConstructible as well as Callable. Consider making
- (Std)Predicate SemiRegular.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 201
- </TD>
- <TD>
- 20.1.5
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- Consistency axiom for LessThanComparable will not compile.
- </TD>
- <TD>
- Add
- a requires clause to the Consistency axiomL requires
- HasLessEquals<T> && HasGreaterEquals<T>, or
- split the Consistency axiom into two so that 'basic' consistency
- can be asserted regardless of the <=/>= requirement.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 33
- </TD>
- <TD>
- 20.1.5
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- LessThanComparable and
- EqualityComparable don't correspond to NaN.
- </TD>
- <TD>
- 
- Apply concept_map to these
- concepts at FloatingPointType
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 66
- </TD>
- <TD>
- 20.1.10
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- Application
- of the "Regular" concept to floating-point types appears
- to be controversial (see long discussion on std-lib reflector).
- </TD>
- <TD>
- State
- that the “Regular” concept does not apply to
- floating-point types.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 34
- </TD>
- <TD>
- 20.2
- </TD>
- <TD>
- 
- 1st
- paragraph, 4th
- line
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- Though N2672 pointed at adding
- "#include<initializer_list>", it isn't reflected.
- </TD>
- <TD>
- 
- add followings
- 
- #include <initializer_list>
- // for concept_map
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 67
- </TD>
- <TD>
- 20.2.1
- </TD>
- <TD>
- ¶
- 5 first sent.
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- Some
- connective words are missing.
- </TD>
- <TD>
- Insert
- “corresponding to” before “an lvalue reference
- type.”
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 35
- </TD>
- <TD>
- 20.2.3
- </TD>
- <TD>
- 
- 6th
- paragraph, 1st
- line
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- Typo,
- "stdforward"
- should be "std::forward"
- </TD>
- <TD>
- Correct
- typo.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 202
- </TD>
- <TD>
- 20.2.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- references to pair in the tuple-like access to pair functions
- qualify pair with std::pair even though they are in a namespace
- std block.
- 
- 
- </TD>
- <TD>
- Remove
- the std:: qualification from these references to pair.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 68
- </TD>
- <TD>
- 20.2.12
- </TD>
- <TD>
- IntegralLike
- </TD>
- <TD>
- te/ed
- </TD>
- <TD>
- The
- code defining the context is syntactically incorrect.
- </TD>
- <TD>
- Insert
- a comma in two places: at the end of the third line of
- refinements, and at the end of the fourth line of refinements.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 203
- </TD>
- <TD>
- 20.3.2
- </TD>
- <TD>
- 1-4
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- ratio_xyz types have a misplaced '}'. For example: template <class
- R1, class R2> struct ratio_add { typedef see below} type; ;
- 
- 
- </TD>
- <TD>
- Move
- the '}' to after the typedef: template <class R1, class R2>
- struct ratio_add { typedef see below type; };
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 36
- </TD>
- <TD>
- 20.4.2.1
- </TD>
- <TD>
- 
- 19th
- paragraph, 6th
- line
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- Typo.
- 
- "it it" should be
- "it is"
- </TD>
- <TD>
- 
- Correct typo.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 204
- </TD>
- <TD>
- 20.5
- </TD>
- <TD>
- Table
- 41
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- It
- is not possible to create a variant union based on a parameter
- pack expansion, e.g. to implement a classic discriminated union
- template.
- 
- 
- </TD>
- <TD>
- Restore
- aligned_union template that was removed by LWG issue 856.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 69
- </TD>
- <TD>
- 20.5
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- This
- section, dealing with tuple<>, should be in the same section
- as the similar utility pair<>.
- </TD>
- <TD>
- Restructure
- Clause 20 so as to bring these similar components together.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 205
- </TD>
- <TD>
- 20.5.3
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- integral_constant
- objects should be usable in integral-constant-expressions. The
- addition to the language of literal types and the enhanced rules
- for constant expressions make this possible.
- 
- 
- </TD>
- <TD>
- Add
- a constexpr conversion operator to class tempalate
- integral_constant: constexpr operator value_type() { return value;
- }
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 206
- </TD>
- <TD>
- 20.5.5
- </TD>
- <TD>
- para
- 4
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Currently
- the std says: "In order to instantiate the template
- is_convertible<From, To>, the following code shall be well
- formed:" But the code shown is the requirement for the result
- of is_convertible to be a true_type, not a precondition on whether
- the template can be instantiated.
- 
- 
- </TD>
- <TD>
- Change:
- "In order to instantiate the template is_convertible<From,
- To>, the following code shall be well formed:" To: "The
- template is_convertible<From, To> inherits either directly
- or indirectly from true_type if the following code is well
- formed:"
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 207
- </TD>
- <TD>
- 20.5.6.1
- </TD>
- <TD>
- Table
- 36
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- suffix
- "::type" is missing from the some of the examples.
- </TD>
- <TD>
- Change:
- Example:remove_const<const volatile int>::type evaluates to
- volatile int, whereas remove_const<const int*> is const
- int*. —end example To: Example:remove_const<const
- volatile int>::type evaluates to volatile int, whereas
- remove_const<const int*>::type is const int*. —end
- example And change: Example:remove_volatile<const volatile
- int>::type evaluates to const int, whereas
- remove_volatile<volatile int*> is volatile int*. —end
- example To: Example:remove_volatile<const volatile int>::type
- evaluates to const int, whereas remove_volatile<volatile
- int*>::type is volatile int*. —end example And change:
- Example:remove_cv<const volatile int>::type evaluates to
- int, whereas remove_cv<const volatile int*> is const
- volatile int*. —end example To: Example:remove_cv<const
- volatile int>::type evaluates to int, whereas remove_cv<const
- volatile int*>::type is const volatile int*. —end example
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 37
- </TD>
- <TD>
- 20.5.7
- </TD>
- <TD>
- Table
- 41
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- Typo.
- 
- There isn't a period at the
- end of enable_if's comments.
- 
- 
- 
- 
- If B is true, the member
- typedef type shall equal T; otherwise, there shall be no member
- typedef type
- 
- 
- 
- 
- should be
- 
- 
- 
- 
- If B is true, the member
- typedef type shall equal T; otherwise, there shall be no member
- typedef type.
- 
- 
- </TD>
- <TD>
- 
- Add ”.”
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 70
- </TD>
- <TD>
- 20.6
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- Specifications
- now expressed via narrative text are more accurately and clearly
- expressed via executable code.
- </TD>
- <TD>
- Wherever
- concepts are available that directly match this section’s
- type traits, express the traits in terms of the concepts instead
- of via narrative text. Where the type traits do not quite match
- the corresponding concepts, bring the two into alignment so as to
- avoid two nearly-identical notions.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 71
- </TD>
- <TD>
- 20.6.7
- </TD>
- <TD>
- Table
- 51, last row, column 3
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- The
- grammar is incorrect.
- </TD>
- <TD>
- Change
- “conversion are” to “conversion is”.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 38
- </TD>
- <TD>
- 20.6.12.1.3
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- add the move requirement for
- bind's return type. 
- 
- 
- For example, assume following
- th1 and th2,
- 
- void f(vector<int>
- v) { } vector<int> v{ ... }; thread th1([v]{ f(v);
- }); thread th2(bind(f, v)); When function object are set
- to thread, v is moved to th1's lambda expression in a Move
- Constructor of lambda expression becuase th1's lambda expression
- has a Move Constructor. But bind of th2's return type doesn't have
- the requirement of Move, so it may not moved but copied.
- 
- Add the requirement of move to
- get rid of this useless copy.
- 
- And also, add the
- MoveConstructible as well as CopyConstructible.
- 
- 
- 
- </TD>
- <TD>
- 
- Add
- the following requirements. "it
- has a public move constructor that performs a member-wise move."
- 
- Add the MoveConstructible.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 39
- </TD>
- <TD>
- 20.6.16.2
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- There are no requires
- corresponding to F of std::function.
- </TD>
- <TD>
- 
- Correct as follows.
- 
- template<class F, Allocator
- A> function(allocator_arg_t, const A&, F);
- 
- template<class F, Allocator
- A> function(allocator_arg_t, const A&, F&&);
- 
- 
- 
- 
- should be
- 
- 
- 
- 
- template<class F, Allocator
- A>
- 
- requires
- CopyConstructible<F> && Callable<F, ArgTypes...>
- 
- &&
- Convertible<Callable<F, ArgTypes...>::result_type, R>
- 
- function(allocator_arg_t,
- const A&, F);
- 
- template<class F, Allocator
- A>
- 
- requires
- CopyConstructible<F> && Callable<F, ArgTypes...>
- 
- &&
- Convertible<Callable<F, ArgTypes...>::result_type, R>
- 
- function(allocator_arg_t,
- const A&, F&&);
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 40
- </TD>
- <TD>
- 20.6.16.2
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- Thougn it's "Allocator
- Aloc" at other places, it's "Allocator A" only
- std::function constructor template parameter.
- </TD>
- <TD>
- 
- Correct as follows.
- 
- template<class F, Allocator
- A> function(allocator_arg_t, const A&, F);
- 
- template<class F, Allocator
- A> function(allocator_arg_t, const A&, F&&);
- 
- 
- 
- 
- should be
- 
- 
- 
- 
- template<class
- F, Allocator Alloc>
- function(allocator_arg_t, const Alloc
- &, F);
- 
- template<class
- F, Allocator Alloc>
- function(allocator_arg_t, const Alloc
- &, F&&);
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 41
- </TD>
- <TD>
- 20.6.16.2
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- There are no requires
- corresponding to R and Args of UsesAllocator.
- </TD>
- <TD>
- 
- Correct as follows.
- 
- template <class R, class...
- Args>
- 
- concept_map
- UsesAllocator<function<R(Args...)>, Alloc> {
- 
- typedef Alloc
- allocator_type;
- 
- }
- 
- 
- 
- 
- should be
- 
- 
- 
- 
- template
- <Returnable
- R, CopyConstructible...
- Args>
- 
- concept_map
- UsesAllocator<function<R(Args...)>, Alloc> {
- 
- typedef Alloc
- allocator_type;
- 
- }
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 42
- </TD>
- <TD>
- 20.6.16.2
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- The requires are wrong.
- 
- R require Returnable, and
- ArgTypes requires CopyConstructible by a definition of function,
- then it's a mistake to designate followings by MoveConstructible.
- </TD>
- <TD>
- 
- Correct as follows.
- 
- 
- 
- 
- template <MoveConstructible
- R, MoveConstructible... ArgTypes>
- 
- bool operator==(const
- function<R(ArgTypes...)>&, nullptr_t);
- 
- template <MoveConstructible
- R, MoveConstructible... ArgTypes>
- 
- bool operator==(nullptr_t,
- const function<R(ArgTypes...)>&);
- 
- template <MoveConstructible
- R, MoveConstructible... ArgTypes>
- 
- bool operator!=(const
- function<R(ArgTypes...)>&, nullptr_t);
- 
- template <MoveConstructible
- R, MoveConstructible... ArgTypes>
- 
- bool operator!=(nullptr_t,
- const function<R(ArgTypes...)>&);
- 
- template <MoveConstructible
- R, MoveConstructible... ArgTypes>
- 
- void
- swap(function<R(ArgTypes...)>&,
- function<R(ArgTypes...)>&);
- 
- 
- 
- 
- should be
- 
- 
- 
- 
- template
- <Returnable
- R, CopyConstructible...
- ArgTypes>
- 
- bool operator==(const
- function<R(ArgTypes...)>&, nullptr_t);
- 
- template
- <Returnable
- R, CopyConstructible...
- ArgTypes>
- 
- bool operator==(nullptr_t,
- const function<R(ArgTypes...)>&);
- 
- template
- <Returnable
- R, CopyConstructible...
- ArgTypes>
- 
- bool operator!=(const
- function<R(ArgTypes...)>&, nullptr_t);
- 
- template
- <Returnable
- R, CopyConstructible...
- ArgTypes>
- 
- bool operator!=(nullptr_t,
- const function<R(ArgTypes...)>&);
- 
- template
- <Returnable
- R, CopyConstructible...
- ArgTypes>
- 
- void
- swap(function<R(ArgTypes...)>&,
- function<R(ArgTypes...)>&);
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 208
- </TD>
- <TD>
- 20.6.17
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- std::hash
- should be implemented for much more of the standard library. In
- particular for pair, tuple and all the standard containers.
- 
- 
- </TD>
- <TD>
- .
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 209
- </TD>
- <TD>
- 20.7
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Smart
- pointers cannot be used in constrained templates
- </TD>
- <TD>
- Provide
- constraints for smart pointers 
- 
- 
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 213
- </TD>
- <TD>
- 20.7.6
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- std::allocator
- should be constrained to simplify its use on constrained contexts.
- This library component models allocation from free store via the
- new operator so choose constraints to match. The Allocator concept
- allows for a wider variety of allocators that users may choose to
- supply if their allocation model does not require operator new,
- without impacting the requirements of this template.
- 
- 
- </TD>
- <TD>
- The
- primary allocator template should be constrained to require
- ObjectType<T> and FreeStoreAllocatable<T>. Further
- operations to be constrained as required.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 214
- </TD>
- <TD>
- 20.7.8
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- raw_storage_iterator
- needs constraining as an iterator adaptor to be safely used in
- constrained templates
- 
- 
- </TD>
- <TD>
- Constrain
- the raw_storage_iterator template
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 210
- </TD>
- <TD>
- 20.7.11
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Specialized
- algorithms for memory managenment need requirements to be easily
- usable in constrained templates
- </TD>
- <TD>
- Provide
- constraints for all algorithms in 20.7.11
- 
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- DE-20
- </TD>
- <TD>
- 20.7.12
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- DE-20
- The section heading and the first sentence use the term "template
- function", which is undefined.
- </TD>
- <TD>
- Replace
- "template function" by "function template". 
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- US
- 72
- </TD>
- <TD>
- 20.7.12
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- te
- </TD>
- <TD>
- 
- bind should support move-only
- functors and bound arguments.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- DE-21
- </TD>
- <TD>
- 20.7.12.1.3
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- DE-21
- The specification for bind claims twice that "the values and
- types for the bound arguments v1, v2, ..., vN are determined as
- specified below". No such specification appears to exist.
- </TD>
- <TD>
- Add
- the missing specification in the same section, or add a
- cross-reference indicating the section where the specification
- appears.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 211
- </TD>
- <TD>
- 20.7.12.2.3
- </TD>
- <TD>
- 11
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- nullptr_t type was introduced to resolve the null pointer literal
- problem. It should be used for the assignemnt operator, as with
- the constructor and elsewhere through the library.
- 
- 
- </TD>
- <TD>
- Change
- signature here and in the synopsis to: unique_ptr&
- operator=(nullptr_t); Strike the sentance an note before the
- Effects clause.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 212
- </TD>
- <TD>
- 20.7.13.7
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- pointer-safety API is nothing to do with smart pointers, so does
- not belong in 20.7.13. In fact it is a set of language support
- features are really belongs in clause 18, with the contents
- declared in a header that deals with language-support of memory
- management.
- 
- 
- </TD>
- <TD>
- Move
- this specification to 18.5. Move the declarations into the header
- <new>.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- DE-22
- </TD>
- <TD>
- 20.7.16.2
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- DE-22
- The conditions for deriving from std::unary_function and
- std::binary_function are unclear: The condition would also be
- satisfied if ArgTypes were std::vector<T1>, because it
- (arguably) "contains" T1.
- </TD>
- <TD>
- Consider
- stating the conditions in normative prose instead of in comments
- in the class definition. Use "consists of" instead of
- "contains". Consider using "if and only if"
- instead of "iff".
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- US
- 73
- </TD>
- <TD>
- 
- 20.7.18
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- te
- </TD>
- <TD>
- 
- The
- std::reference_closure template is redundant with std::function
- and should be removed.
- 
- 
- 
- std::reference_closure
- is a premature optimization that provides a limited subset of the
- functionality of std::function intended to improve performance in
- a narrow use case. However, the “parallel application
- performance” benchmark used to motivate the inclusion of
- std::reference_closure was flawed in several ways:
- <OL START=3>
- <LI>
- it
- failed to enable a common optimization in std::function
- (implemented by all vendors), exacting a large and unrealistic
- penalty for copying std::function instances, and
- <LI>
- it
- failed to account for parallel scheduler overhead or
- realistically-sized work units, both of which would dominate the
- costs measured by the benchmark in any realistic application.
- </OL>
- 
- 
- </TD>
- <TD>
- 
- Remove
- 20.7.18 [func.referenceclosure].
- 
- 
- 
- Remove
- 5.1.1 paragraph 12.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- US
- 74
- </TD>
- <TD>
- 
- 20.8
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- te
- </TD>
- <TD>
- 
- Scoped
- allocators represent a poor trade-off for standardization, since
- (1) scoped-allocator--aware containers can be implemented outside
- the C++ standard library but used with its algorithms, (2) scoped
- allocators only benefit a tiny proportion of the C++ community
- (since few C++ programmers even use today’s allocators), and
- (3) all C++ users, especially the vast majority of the C++
- community that won’t ever use scoped allocators are forced
- to cope with the interface complexity introduced by scoped
- allocators. In essence, the larger community will suffer to
- support a very small subset of the community who can already
- implement their own data structures outside of the standard
- library. Therefore, scoped allocators should be removed from the
- working paper.
- 
- Some
- evidence of the complexity introduced by scoped allocators:
- 
- 20.3.3,
- 20.5: large increase in the number of pair and tuple constructors
- 
- 23:
- confusing “AllocatableElement” requirements
- throughout.
- 
- 
- </TD>
- <TD>
- 
- Remove
- support for scoped allocators from the working paper. This
- includes at least the following changes:
- 
- 
- 
- Remove
- 20.8.3 [allocator.element.concepts]
- 
- 
- 
- Remove
- 20.8.7 [allocator.adaptor]
- 
- 
- 
- Remove
- 20.8.10 [construct.element]
- 
- 
- 
- In
- Clause 23: replace requirements naming the AllocatableElement
- concept with requirements naming CopyConstructible,
- MoveConstructible, DefaultConstructible, or Constructible, as
- appropriate.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 74
- </TD>
- <TD>
- 20.8.2.2
- </TD>
- <TD>
- (a)
- synopsis (b) after ¶ 14
- </TD>
- <TD>
- te/ed
- </TD>
- <TD>
- A
- concept name is twice misspelled.
- </TD>
- <TD>
- Change
- “Hasconstructor” to “HasConstructor”
- (twice).
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 75
- </TD>
- <TD>
- 20.8.2.2
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- Allocator
- concepts are incomplete
- </TD>
- <TD>
- See
- paper:
- http://www.halpernwightsoftware.com/WG21/n2810_allocator_defects.pdf>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 43
- </TD>
- <TD>
- 20.8.3
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- Typo.
- 
- "alloc" should be
- "Alloc"
- </TD>
- <TD>
- 
- Correct as follows.
- 
- 
- 
- 
- auto concept
- UsesAllocator<typename T, typename Alloc> {
- 
- requires Allocator<alloc>;
- 
- typename allocator_type =
- T::allocator_type;
- 
-  
- 
- should be
- 
-  
- 
- auto concept
- UsesAllocator<typename T, typename Alloc> {
- 
- requires
- Allocator<Alloc>;
- 
- typename allocator_type =
- T::allocator_type;
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 215
- </TD>
- <TD>
- 20.8.3.3
- </TD>
- <TD>
- 6,8
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Extra
- pair of {}, presumably some formatting code gone awry : duration&
- operator-{-}();
- 
- 
- </TD>
- <TD>
- Remove
- the {} or fix formatting
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- US
- 77
- </TD>
- <TD>
- 
- 20.8.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- te
- </TD>
- <TD>
- 
- Allocator-specific
- move and copy behavior for containers (N2525) complicates a
- little-used and already-complicated portion of the standard
- library (allocators), and breaks the conceptual model of
- move-constructor and move-assignment operations on standard
- containers being efficient operations. The extensions for
- allocator-specific move and copy behavior should be removed from
- the working paper.
- 
- With
- the introduction of rvalue references, we are teaching programmers
- that moving from a standard container (e.g., a vector<string>)
- is an efficient, constant-time operation. The introduction of
- N2525 removed that guarantee; depending on the behavior of four
- different traits (20.8.4), the complexity of copy and move
- operations can be constant or linear time. This level of
- customization greatly increases the complexity of standard
- containers, and benefits only a tiny fraction of the C++
- community.
- 
- 
- </TD>
- <TD>
- 
- Remove
- 20.8.4.
- 
- 
- 
- Remove
- 20.8.5.
- 
- 
- 
- Remove
- all references to the facilities in 20.8.4 and 20.8.5 from clause
- 23.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 78
- </TD>
- <TD>
- 20.8.12,
- 20.8.13.2
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- There
- is presently no way to convert directly from a <CODE>
- shared_ptr</CODE>
- to a <CODE>
- unique_ptr</CODE>.
- </TD>
- <TD>
- 
- Add
- an interface that performs the conversion. See the attached,
- Issues with the C++ Standard" paper under Chapter 20,
- "Conversion from <CODE>
- shared_ptr</CODE>
- to <CODE>
- unique_ptr".</CODE>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- US
- 79
- </TD>
- <TD>
- 20.8.12.2.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- te
- </TD>
- <TD>
- 
- [unique.ptr.single.ctor]/5 no
- longer requires for D not to be a pointer type.  This
- restriction needs to be put back in.  Otherwise we have a run
- time failure that could have been caught at compile time:
- 
- 
- 
- 
- unique_ptr<int,
- void(*)(void*)> p(malloc(sizeof(int)));  // should not
- compile
- 
- 
- 
- 
- unique_ptr<int,
- void(*)(void*)> p(malloc(sizeof(int)), free);  // ok
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 44
- </TD>
- <TD>
- 20.8.13.6
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- The 1st parameter p and 2nd
- parameter v is now shared_ptr<T> *.
- 
- It should be shared_ptr<T>&,
- or if these are shared_ptr<T>* then add the "p shall
- not be a null pointer" at the requires.
- </TD>
- <TD>
- 
- Change shared_ptr<T>&
- or add the "p shall not be a null pionter" at the
- requires.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 45
- </TD>
- <TD>
- 20.9
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- Rep, Period, Clock and
- Duration don't correspond to concept.
- 
- template <class Rep, class
- Period = ratio<1>> class duration;
- 
- template <class Clock,
- class Duration = typename Clock::duration> class time_point;
- 
- 
- 
- </TD>
- <TD>
- 
- Make concept for Rep, Period,
- Clock and Duration, and fix 20.9 and wait_until and wait_for's
- template parameter at 30.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 80
- </TD>
- <TD>
- 20.9.2.1
- </TD>
- <TD>
- Heading
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- The
- section heading does not describe the contents.
- </TD>
- <TD>
- Change
- the heading “is_floating_point”
- to “treat_as_floating_point”.
- Optionally adjust the section’s label similarly.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- US
- 81
- </TD>
- <TD>
- 20.9.3
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- te
- </TD>
- <TD>
- 
- chrono::duration is missing
- the modulous operator for both member and non-member arithmetic.
- This operator is useful for finding the position of a duration
- within a bounded time frame. Having it be built in to duration is
- safer than requiring the client to extract and operate directly on
- the duration’s representation as the latter will not enforce
- the correct units of the operation.
- 
- 
- 
- 
- Ex:
- 
- 
- 
- 
- milliseconds ms(...);
- 
- microseconds us(...);
- 
- 
- 
- 
- ms % us; // microseconds
- 
- us % ms; // microseconds
- 
- ms % 5; // milliseconds
- 
- 5 % ms; // does not compile
- 
- 
- </TD>
- <TD>
- 
- Add:
- 
- 
- 
- template <class Rep, class
- Period = ratio<1>> 
- 
- 
- class duration { 
- 
- 
- public: 
- 
- 
- ...
- 
- duration&
- operator%(const rep&);
- 
- duration&
- operator%(const duration&);
- 
- ..
- 
- };
- 
- 
- 
- template
- <class Rep1, class Period,
- 
- class
- Rep2> 
- 
- 
- duration<typename
- common_type<
- 
- Rep1,
- Rep2>::type, Period> 
- 
- 
- operator%(const
- duration<Rep1, Period>& d, const Rep2& s); 
- 
- 
- 
- 
- template
- <class Rep1, class Period1,
- 
- class
- Rep2, class Period2> 
- 
- 
- typename
- common_type<duration<Rep1, Period1>, duration<Rep2,
- Period2>>::type 
- 
- 
- operator%(const
- duration<Rep1, Period1>& lhs, const duration<Rep2,
- Period2>& rhs); 
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 82
- </TD>
- <TD>
- 20.9.5.3
- </TD>
- <TD>
- after
- ¶ 1
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- The
- code synopsis has a minor alignment error.
- </TD>
- <TD>
- Align
- “rep” with the other symbols defined in this synopsis.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 216
- </TD>
- <TD>
- 21
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- All
- the containers use concepts for their iterator usage, exect for
- basic_string. This needs fixing.
- </TD>
- <TD>
- Use
- concepts for iterator template parameters throughout the chapter.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 46
- </TD>
- <TD>
- 21.2,
- 21.3
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- The basic_string does not use
- concept.
- </TD>
- <TD>
- 
- The "class Alloc" is
- changed to "Allocator Alloc".
- 
- The "class
- InputIterator" is changed to "InputIterator Iter".
- 
- 
- 
- 
- // 21.3, basic_string:
- 
- template<class charT, class
- traits = char_traits<charT>,
- 
- Allocator
- Alloc = allocator<charT> >
- 
- class basic_string;
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- basic_string<charT,traits,Alloc>
- 
- operator+(const
- basic_string<charT,traits,Alloc>&
- lhs,
- 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- basic_string<charT,traits,Alloc>&&
- 
- operator+(basic_string<charT,traits,Alloc>&&
- lhs,
- 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- basic_string<charT,traits,Alloc>&&
- 
- operator+(const
- basic_string<charT,traits,Alloc>&
- lhs,
- 
- basic_string<charT,traits,Alloc>&&
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- basic_string<charT,traits,Alloc>&&
- 
- operator+(basic_string<charT,traits,Alloc>&&
- lhs,
- 
- basic_string<charT,traits,Alloc>&&
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- basic_string<charT,traits,Alloc>
- 
- operator+(const charT*
- lhs,
- 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- basic_string<charT,traits,Alloc>&&
- 
- operator+(const charT*
- lhs,
- 
- basic_string<charT,traits,Alloc>&&
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- basic_string<charT,traits,Alloc>
- 
- operator+(charT
- lhs, const basic_string<charT,traits,Alloc>&
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- basic_string<charT,traits,Alloc>&&
- 
- operator+(charT
- lhs, basic_string<charT,traits,Alloc>&&
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- basic_string<charT,traits,Alloc>
- 
- operator+(const
- basic_string<charT,traits,Alloc>&
- lhs,
- 
- const charT*
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- basic_string<charT,traits,Alloc>&&
- 
- operator+(basic_string<charT,traits,Alloc>&&
- lhs,
- 
- const charT*
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- basic_string<charT,traits,Alloc>
- 
- operator+(const
- basic_string<charT,traits,Alloc>&
- lhs, charT rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- basic_string<charT,traits,Alloc>&&
- 
- operator+(basic_string<charT,traits,Alloc>&&
- lhs, charT rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- bool
- operator==(const basic_string<charT,traits,Alloc>&
- lhs,
- 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- bool operator==(const charT*
- lhs,
- 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- bool
- operator==(const basic_string<charT,traits,Alloc>&
- lhs,
- 
- const charT*
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- bool
- operator!=(const basic_string<charT,traits,Alloc>&
- lhs,
- 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- bool operator!=(const charT*
- lhs,
- 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- bool
- operator!=(const basic_string<charT,traits,Alloc>&
- lhs,
- 
- const charT*
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- bool
- operator< (const basic_string<charT,traits,Alloc>&
- lhs,
- 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- bool
- operator< (const basic_string<charT,traits,Alloc>&
- lhs,
- 
- const charT*
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- bool operator< (const
- charT* lhs,
- 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- bool
- operator> (const basic_string<charT,traits,Alloc>&
- lhs,
- 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- bool
- operator> (const basic_string<charT,traits,Alloc>&
- lhs,
- 
- const charT*
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- bool operator> (const
- charT* lhs,
- 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- bool
- operator<=(const basic_string<charT,traits,Alloc>&
- lhs,
- 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- bool
- operator<=(const basic_string<charT,traits,Alloc>&
- lhs,
- 
- const charT*
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- bool operator<=(const
- charT* lhs,
- 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- bool
- operator>=(const basic_string<charT,traits,Alloc>&
- lhs,
- 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- bool
- operator>=(const basic_string<charT,traits,Alloc>&
- lhs,
- 
- const charT*
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- bool operator>=(const
- charT* lhs,
- 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
- 
-  
- 
- // 21.3.8.8: swap
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- void
- swap(basic_string<charT,traits,Alloc>& lhs,
- 
- basic_string<charT,traits,Alloc>&
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- void
- swap(basic_string<charT,traits,Alloc>&& lhs,
- 
- basic_string<charT,traits,Alloc>&
- rhs);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- void
- swap(basic_string<charT,traits,Alloc>& lhs,
- 
- basic_string<charT,traits,Alloc>&&
- rhs);
- 
-  
- 
- // 21.3.8.9: inserters and
- extractors
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- basic_istream<charT,traits>&
- 
- operator>>(basic_istream<charT,traits>&&
- is,
- 
- basic_string<charT,traits,Alloc>&
- str);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- basic_ostream<charT,
- traits>&
- 
- operator<<(basic_ostream<charT,
- traits>&& os,
- 
- const
- basic_string<charT,traits,Alloc>&
- str);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- basic_istream<charT,traits>&
- 
- getline(basic_istream<charT,traits>&&
- is,
- 
- basic_string<charT,traits,Alloc>&
- str,
- 
- charT delim);
- 
-  
- 
- template<class
- charT, class traits, Allocator Alloc>
- 
- basic_istream<charT,traits>&
- 
- getline(basic_istream<charT,traits>&&
- is,
- 
- basic_string<charT,traits,Alloc>&
- str);
- 
-  
- 
- 
- 
- 
- // 21.3 Class template
- basic_string
- 
- namespace std {
- 
- template<class charT,
- class traits = char_traits<charT>,
- 
- Allocator
- Alloc =
- allocator<charT> >
- 
- class basic_string {
- 
- public:
- 
- // types:
- 
- typedef traits traits_type;
- 
- typedef typename
- traits::char_type value_type;
- 
- typedef Alloc
- allocator_type;
- 
- typedef
- typename Alloc::size_type
- size_type;
- 
- typedef
- typename Alloc::difference_type
- difference_type;
- 
- typedef
- typename Alloc::reference
- reference;
- 
- typedef
- typename Alloc::const_reference
- const_reference;
- 
- typedef
- typename Alloc::pointer
- pointer;
- 
- typedef
- typename Alloc::const_pointer
- const_pointer;
- 
- typedef
- implementation-defined iterator; // See 23.1
- 
- typedef
- implementation-defined const_iterator; // See 23.1
- 
- typedef
- std::reverse_iterator<iterator> reverse_iterator;
- 
- typedef
- std::reverse_iterator<const_iterator>
- const_reverse_iterator;
- 
- static const size_type npos
- = -1;
- 
-  
- 
- // 21.3.2
- construct/copy/destroy:
- 
- explicit
- basic_string(const Alloc&
- a = Alloc());
- 
- basic_string(const
- basic_string& str);
- 
- basic_string(basic_string&&
- str);
- 
- basic_string(const
- basic_string& str, size_type pos, size_type n = npos,
- 
- const Alloc&
- a = Alloc());
- 
- basic_string(const charT* s,
- 
- size_type
- n, const Alloc&
- a = Alloc());
- 
- basic_string(const
- charT* s, const Alloc&
- a = Alloc());
- 
- basic_string(size_type
- n, charT c, const Alloc&
- a = Alloc());
- 
- template<InputIterator Iter>
- 
- basic_string(Iter
- begin, Iter
- end,
- 
- const Alloc&
- a = Alloc());
- 
- basic_string(initializer_list<charT>,
- const Alloc&
- = Alloc());
- 
- basic_string(const
- basic_string&, const Alloc&);
- 
- basic_string(basic_string&&,
- const Alloc&);
- 
- ~basic_string();
- 
- basic_string&
- operator=(const basic_string& str);
- 
- basic_string&
- operator=(basic_string&& str);
- 
- basic_string&
- operator=(const charT* s);
- 
- basic_string&
- operator=(charT c);
- 
- basic_string&
- operator=(initializer_list<charT>);
- 
-  
- 
- // 21.3.3 iterators:
- 
- ...
- 
-  
- 
- // 21.3.4 capacity:
- 
- ...
- 
-  
- 
- // 21.3.5 element access:
- 
- ...
- 
-  
- 
- // 21.3.6 modifiers:
- 
- ...
- 
-  
- 
- basic_string&
- append(const basic_string& str);
- 
- basic_string&
- append(const basic_string& str, size_type pos,
- 
- size_type
- n);
- 
- basic_string&
- append(const charT* s, size_type n);
- 
- basic_string&
- append(const charT* s);
- 
- basic_string&
- append(size_type n, charT c);
- 
- template<InputIterator Iter>
- 
- basic_string&
- append(Iter
- first, Iter
- last);
- 
- basic_string&
- append(initializer_list<charT>);
- 
- void push_back(charT c);
- 
-  
- 
- basic_string&
- assign(const basic_string& str);
- 
- basic_string&
- assign(basic_string&& str);
- 
- basic_string&
- assign(const basic_string& str, size_type pos,
- 
- size_type
- n);
- 
- basic_string&
- assign(const charT* s, size_type n);
- 
- basic_string&
- assign(const charT* s);
- 
- basic_string&
- assign(size_type n, charT c);
- 
- template<InputIterator Iter>
- 
- basic_string&
- assign(Iter
- first, Iter
- last);
- 
- basic_string&
- assign(initializer_list<charT>);
- 
-  
- 
- basic_string&
- insert(size_type pos1, const basic_string& str);
- 
- basic_string&
- insert(size_type pos1, const basic_string& str,
- 
- size_type
- pos2, size_type n);
- 
- basic_string&
- insert(size_type pos, const charT* s, size_type n);
- 
- basic_string&
- insert(size_type pos, const charT* s);
- 
- basic_string&
- insert(size_type pos, size_type n, charT c);
- 
- iterator
- insert(const_iterator p, charT c);
- 
- void insert(const_iterator
- p, size_type n, charT c);
- 
- template<InputIterator Iter>
- 
- void
- insert(const_iterator p, Iter
- first, Iter
- last);
- 
- void insert(const_iterator
- p, initializer_list<charT>);
- 
-  
- 
- ...
- 
- basic_string&
- replace(size_type pos1, size_type n1,
- 
- const
- basic_string& str);
- 
- basic_string&
- replace(size_type pos1, size_type n1,
- 
- const
- basic_string& str,
- 
- size_type
- pos2, size_type n2);
- 
- basic_string&
- replace(size_type pos, size_type n1, const charT* s,
- 
- size_type
- n2);
- 
- basic_string&
- replace(size_type pos, size_type n1, const charT* s);
- 
- basic_string&
- replace(size_type pos, size_type n1, size_type n2,
- 
- charT
- c);
- 
- basic_string&
- replace(iterator i1, iterator i2,
- 
- const
- basic_string& str);
- 
- basic_string&
- replace(iterator i1, iterator i2, const charT* s,
- 
- size_type
- n);
- 
- basic_string&
- replace(iterator i1, iterator i2, const charT* s);
- 
- basic_string&
- replace(iterator i1, iterator i2,
- 
- size_type
- n, charT c);
- 
- template<InputIterator Iter>
- 
- basic_string&
- replace(iterator i1, iterator i2,
- 
- Iter
- j1, Iter
- j2);
- 
- basic_string&
- replace(iterator, iterator, initializer_list<charT>);
- 
-  
- 
- ...
- 
-  
- 
- // 21.3.7 string operations:
- 
- ...
- 
-  
- 
- template
- <class charT, class traits, Allocator Alloc>
- 
- struct
- constructible_with_allocator_suffix<
- 
- basic_string<charT,
- traits, Alloc>
- > : true_type { };
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 47
- </TD>
- <TD>
- 21.3
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- Typo. Missing ”>”
- 
- template <class charT,
- class traits, Allocator Alloc
- 
- 
- 
- 
- should be
- 
- 
- 
- 
- template <class charT,
- class traits, Allocator Alloc>
- 
- 
- </TD>
- <TD>
- 
- Correct typo.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 48
- </TD>
- <TD>
- 21.3
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- char_traits does not use
- concept.
- 
- For example, create CharTraits
- concept and change as follows:
- 
- 
- 
- 
- template<class
- charT, CharTraits
- traits = char_traits<charT>,
- 
- class Allocator =
- allocator<charT> >
- 
- class basic_string {
- 
- 
- 
- </TD>
- <TD>
- 
- Add a concept for char_traits.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 217
- </TD>
- <TD>
- 21.3
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- basic_string
- refers to constructible_with_allocator_suffix, which I thought was
- removed?
- </TD>
- <TD>
- Remove
- the lines: template <class charT, class traits, class Alloc
- struct constructible_with_allocator_suffix< basic_string<charT,
- traits, Alloc> > : true_type { };
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 218
- </TD>
- <TD>
- 21.3.1
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- identity "&*(s.begin() + n) == &*s.begin() + n"
- relies on operator& doing the "right thing", which
- (AFAICS) there is no requirement for. See my comment under clauses
- "23.2.1, 23.2.6" (p1 in both cases) - this is the same
- issue, but I've created a separate comment for basic_string
- because it is in a different chapter.
- 
- 
- </TD>
- <TD>
- See
- my recommendations for "23.2.1, 23.2.6".
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 219
- </TD>
- <TD>
- 21.3.6.6
- [string.replace]
- </TD>
- <TD>
- 11
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Effects
- refers to "whose first begin() - i1 elements" However i1
- is greater than begin()...
- </TD>
- <TD>
- Effects
- refers to "whose first i1 - begin() elements" 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 220
- </TD>
- <TD>
- 21.3.8.9
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- operator<< for basic_string takes the output stream by
- r-value reference. This is different from the same operator for
- error_code (19.4.2.6), bitset (20.2.6.3), shared_ptr
- (20.7.13.2.8), complex (26.3.6) and sub_match (28.4)
- 
- 
- </TD>
- <TD>
- Use
- the same reference type for the all the library types. This should
- be the r-value reference. There are other places in the standard
- where TR1, and new classes, did not receive an 'R-value' update. 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 33
- </TD>
- <TD>
- 22.1.1
- [locale]
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- ios_base::iostate
- err = 0;
- 
- 
- 
- iostate
- is a bitmask type and so could be an enumeration. Probably using
- goodbit
- is the solution.
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 49
- </TD>
- <TD>
- 22.1.3.2.2
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- codecvt
- does not use concept. For example, create
- CodeConvert concept and change as follows.
- 
- template<CodeConvert
- Codecvt, class Elem = wchar_t> class wstring_convert {
- </TD>
- <TD>
- 
- Add a concept for codecvt.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 50
- </TD>
- <TD>
- 22.1.3.2.2
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- Add custom allocator parameter
- to wstring_convert, since we cannot allocate memory for strings
- from a custom allocator.
- </TD>
- <TD>
- 
- Correct as follows.
- 
- template<class Codecvt,
- class Elem = wchar_t> class wstring_convert {
- 
- public:
- 
- typedef
- std::basic_string<char> byte_string;
- 
- typedef
- std::basic_string<Elem> wide_string;
- 
-  
- 
- should be
- 
-  
- 
- template<class
- Codecvt, class Elem = wchar_t,
- 
- Allocator
- WideAllocator = allocator<Elem>,
- 
- Allocator
- ByteAllocator = allocator<char>>
- 
- class wstring_convert {
- 
- public:
- 
- typedef
- std::basic_string<char, char_traits<char>,
- ByteAllocator>
- byte_string;
- 
- typedef
- std::basic_string<Elem, char_traits<Elem>,
- WideAllocator>
- wide_string;
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FI
- 4
- </TD>
- <TD>
- 22.2.1.4.1
- 22.2.1.4.2
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- <TT>to_end
- and to_limit are both used. Only one is needed.</TT>
- </TD>
- <TD>
- Change
- to_limit to to_end.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FI
- 5
- </TD>
- <TD>
- <TT>22.2.1.4.2
- </TT>
- 
- </TD>
- <TD>
- #3
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- <TT>[
- Note: As a result of operations on state, it can return ok or
- partial and set next == from and to_next != to. —end note ]</TT> 
- 
- <TT>"next"
- should be "from_next."</TT>
- <TT>Also,
- the sentence applies to all the examples, including do_in and
- do_out.</TT>
- <TT>Reasoning:
- When reading one element of multibyte source data such as UTF-8,
- it is possible that from_next is incremented, to_next is
- unaltered, state is altered and return value is partial. When
- reading one element of wide character data, the output can be
- several multibyte characters, so it is possible that from_next is
- unaltered, to_next is advanced, state is altered and return value
- is partial.</TT>
- </TD>
- <TD>
- <TT>[
- Note: As a result of operations on state, do_in and do_out can
- return</TT> <TT>ok or
- partial and set from_next == from and/or to_next != to. —end</TT> <TT>note
- ]</TT>
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FI
- 6
- </TD>
- <TD>
- 22.2.1.5
- See
- also 22.2.1.4 (1,2,3)
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- <TT>codecvt_byname
- is only specified to work with locale names. There is no built-in
- means to find a codecvt with a character set's name. A locale and
- a character set are not the same. If the user has data which is
- encoded in a certain character set and she wants to create a
- codecvt which can convert from that character set to another one,
- she must iterate through locales to find one, or use external
- means (iconv, ICU's uconv). Specifying a locale with the character
- set is not a suitable solution, since there is no built-in mapping
- from character sets to locales. It is only possible to inquire the
- character set once the locale is known.</TT>
- 
- 
- </TD>
- <TD>
- <TT>There
- should be a built-in means to find a codecvt with a pair of
- character set names. </TT>
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FI
- 7
- </TD>
- <TD>
- 22.2.1.4
- </TD>
- <TD>
- 1,2,3
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- The
- word "codeset" is used, whereas the word "character
- set" is used elsewhere in the text. The words are intended to
- convey the same concept, so only one should be used (or always
- both together).
- 
- 
- </TD>
- <TD>
- Change
- "codeset" to "character set."
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 51
- </TD>
- <TD>
- 22.2.5.1.1
- </TD>
- <TD>
- 7th
- paragraph, 1st
- line
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- A parameter `end’ should
- be `fmtend’. get() function had two `end’
- parameters at N2321.
- 
- iter_type get (iter_type s,
- iter_type end, ios_base& f, ios_base::iostate& err, tm* t,
- const char_type* fmt, const char_type *end) const;
- 
- The function prototype of
- get() has been corrected at N2800, but a Requires statement still
- refers `end’ parameter.
- 
- 
- 
- </TD>
- <TD>
- 
- Correct as follows.
- 
- Requires: [fmt,end) shall be
- a valid range.
- 
- 
- 
- 
- should be
- 
- 
- 
- 
- Requires: [fmt,fmtend) shall
- be a valid range.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 52
- </TD>
- <TD>
- 22.2.5.1,
- 22.2.5.2, 22.2.6.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- InputIterator does not use
- concept.
- </TD>
- <TD>
- 
- Correct as follows.
- 
- 
- 
- 
- 22.2.5.1
- 
-  
- 
- template <class charT,
- class InputIterator = istreambuf_iterator<charT> >
- 
- class time_get : public
- locale::facet, public time_base {
- 
- public:
- 
- typedef charT
- char_type;
- 
- typedef InputIterator
- iter_type;
- 
-  
- 
- should be
- 
-  
- 
- template
- <class charT, InputIterator
- InputIter =
- istreambuf_iterator<charT> >
- 
- class time_get : public
- locale::facet, public time_base {
- 
- public:
- 
- typedef charT
- char_type;
- 
- typedef InputIter
- iter_type;
- 
-  
- 
-  
- 
- 22.2.5.2
- 
-  
- 
- template <class charT,
- class InputIterator = istreambuf_iterator<charT> >
- 
- class time_get_byname : public
- time_get<charT, InputIterator> {
- 
- public:
- 
- typedef time_base::dateorder
- dateorder;
- 
- typedef InputIterator
- iter_type;
- 
-  
- 
- should be
- 
-  
- 
- template
- <class charT, InputIterator
- InputIter =
- istreambuf_iterator<charT> >
- 
- class time_get_byname : public
- time_get<charT, InputIter> {
- 
- public:
- 
- typedef time_base::dateorder
- dateorder;
- 
- typedef InputIter
- iter_type;
- 
-  
- 
-  
- 
- 22.2.6.1
- 
-  
- 
- template <class charT,
- 
- class InputIterator
- = istreambuf_iterator<charT> >
- 
- class money_get : public
- locale::facet {
- 
- public:
- 
- typedef charT
- char_type;
- 
- typedef InputIterator
- iter_type;
- 
-  
- 
- should be
- 
-  
- 
- template <class charT,
- 
- InputIterator
- InputIter =
- istreambuf_iterator<charT> >
- 
- class money_get : public
- locale::facet {
- 
- public:
- 
- typedef charT
- char_type;
- 
- typedef InputIter
- iter_type;
- 
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 53
- </TD>
- <TD>
- 22.2.5.3
- , 22.2.5.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- OutputIterator does not use
- concept.
- </TD>
- <TD>
- 
- Correct as follows.
- 
-  
- 
- 22.2.5.3
- 
-  
- 
- template <class charT,
- class OutputIterator = ostreambuf_iterator<charT> >
- 
- class
- time_put : public locale::facet {
- 
- public:
- 
- typedef charT
- char_type;
- 
- typedef OutputIterator
- iter_type;
- 
-  
- 
- 　should
- be
- 
-  
- 
- template
- <class charT, OutputIterator
- OutputIter =
- ostreambuf_iterator<charT> >
- 
- class time_put : public
- locale::facet {
- 
- public:
- 
- typedef
- charT char_type;
- 
- typedef OutputIter
- iter_type;
- 
-  
- 
-  
- 
- 22.2.5.4
- 
-  
- 
- template <class charT,
- class OutputIterator = ostreambuf_iterator<charT> >
- 
- class time_put_byname : public
- time_put<charT, OutputIterator>
- 
- {
- 
- public:
- 
- typedef charT
- char_type;
- 
- typedef OutputIterator
- iter_type;
- 
-  
- 
- should be
- 
-  
- 
- template
- <class charT, OutputIterator
- OutputIter =
- ostreambuf_iterator<charT> >
- 
- class time_put_byname : public
- time_put<charT, OutputIter>
- 
- {
- 
- public:
- 
- typedef charT
- char_type;
- typedef OutputIter
- iter_type;
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 54
- </TD>
- <TD>
- 23
- </TD>
- <TD>
- 
- 2nd
- paragraph, Table 79
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- There is not <forward_list>
- in Table 79.
- </TD>
- <TD>
- 
- Add <forward_list>
- between <deque> and <list>.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 221
- </TD>
- <TD>
- 23
- </TD>
- <TD>
- Table
- 79
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- table is missing the new <forward_list> header.
- </TD>
- <TD>
- Add
- <forward_list> to the table for sequence containers.
- Alternative (technical) solution might be to merge <forward_list>
- into <list>.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 222
- </TD>
- <TD>
- 23
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- It
- is not clear what purpose the Requirement tables serve in the
- Containers clause. Are they the definition of a library Container?
- Or simply a conventient shorthand to factor common semantics into
- a single place, simplifying the description of each subsequent
- container? This becomes an issue for 'containers' like array,
- which does not meet the default-construct-to-empty requirement, or
- forward_list which does not support the size operation. Are these
- components no longer containers? Does that mean the remaining
- requirements don't apply? Or are these contradictions that need
- fixing, despite being a clear design decision?
- 
- 
- </TD>
- <TD>
- Clarify
- all the tables in 23.1 are there as a convenience for
- documentation, rather than a strict set of requirements.
- Containers should be allowed to relax specific requirements if
- they call attention to them in their documentation. The
- introductory text for array should be expanded to mention a
- default constructed array is not empty, and forward_list
- introduction should mention it does not provide the required size
- operation as it cannot be implemented efficiently.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 55
- </TD>
- <TD>
- 23.1.1
- </TD>
- <TD>
- 
- 3rd
- paragraph, 4th
- line
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- It seems that “the
- MinimalAllocator concep” is the typo of “the
- MinimalAllocator concept”.
- </TD>
- <TD>
- 
- Change
- to … models the MinimalAllocator concept.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 223
- </TD>
- <TD>
- 23.1.1
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- library does not define the MinimalAllocator or ScopedAllocator
- concepts, these were part of an earlier Allocators proposal that
- was rejected.
- 
- 
- </TD>
- <TD>
- Remove
- the references to MinimalAllocator and ScopedAllocator, or add
- definitions for these concepts to clause 20.7.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 224
- </TD>
- <TD>
- 23.1.1
- </TD>
- <TD>
- 8
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- This
- paragraph implicitly requires all containers in clause 23 to
- support allocators, which std::array does not.
- </TD>
- <TD>
- Add
- an 'unless otherwise specified' rider somewhere in p8, or move the
- whole array container from clause 23 [containers] to clause 20
- [utilies] to accompany bitset, pair and tuple.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 225
- </TD>
- <TD>
- 23.1.1
- </TD>
- <TD>
- Table
- 81
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Inconsistent
- words used to say the same thing. Table 80 describes
- iterator/const_iterator typedef as returning an "iterator
- type whose value type is T". Table 81 expresses the same idea
- as an "iterator type pointing to T". Express identical
- ideas with the same words to avoid accidentally introducing
- subtlety and confusion
- 
- 
- </TD>
- <TD>
- Change
- return types for X::(const)_reverse_iterator to say "iterator
- type whose value type is (const) T". 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 226
- </TD>
- <TD>
- 23.1.1
- </TD>
- <TD>
- 10
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- <array>
- must be added to this list. In particular it doesn't satisfy: - no
- swap() function invalidates any references, pointers, or iterators
- referring to the elements of the containers being swapped. and
- probably doesn't satisfy: — no swap() function throws an
- exception.
- 
- 
- </TD>
- <TD>
- If
- <array> remains a container, this will have to also
- reference array, which will then have to say which of these points
- it satisfies.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 227
- </TD>
- <TD>
- 23.1.1
- </TD>
- <TD>
- Table
- 80
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- post-condition for a = rv uses the word “construction”
- when it means “assignment”
- </TD>
- <TD>
- Replace
- the word “construction” with the word “assignment”
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 228
- </TD>
- <TD>
- 23.1.1
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Line
- 4 contains a spelling mistake in the fragment "MinimalAllocator
- concep."
- 
- 
- </TD>
- <TD>
- Replace
- "concep" with "concept"
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 229
- </TD>
- <TD>
- 23.1.1
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- fragment "A container may directly call constructors" is
- not technically correct as constructors are not callable.
- </TD>
- <TD>
- Replace
- "A container may directly call constructors and destructors
- for its stored objects" with something similar to "A
- container may directly construct its stored objects and call
- destructors for its stored objects"
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 230
- </TD>
- <TD>
- 23.1.2
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- “implementations
- shall consider the following functions to be const” - what
- does this mean? I don't understand what it means by
- implementations considering the functions to be const –
- surely they are either declared const or not?
- 
- 
- </TD>
- <TD>
- Clarify
- what is meant and what requirements an implementation must
- satisfy.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 56
- </TD>
- <TD>
- 23.1.3
- </TD>
- <TD>
- 12th
- paragraph, Table 84
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- `array’ is unstated in
- Table 84 - Optional sequence container operations.
- </TD>
- <TD>
- 
- Add `array’ to Container
- field for the following Expression.
- 
- a.front()
- 
- a.back()
- 
- a[n]
- 
- a.at(n)
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 231
- </TD>
- <TD>
- 23.1.3
- </TD>
- <TD>
- 9-11
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- These
- paragraphs are redundant now that Concepts define what it means to
- be an Iterator and guide overload resolution accordingly.
- 
- 
- </TD>
- <TD>
- Strike
- 23.1.3p9-11. Make sure std::basic_string has constraints similar
- to std::vector to meet this old guarantee.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 232
- </TD>
- <TD>
- 23.1.3
- </TD>
- <TD>
- Table
- 84
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- match_results
- may follow the requirements but is not listed a general purpose
- library container.
- 
- 
- </TD>
- <TD>
- Remove
- reference to match_results against a[n] operation
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 233
- </TD>
- <TD>
- 23.1.3
- </TD>
- <TD>
- Table
- 84
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Add
- references to the new containers.
- </TD>
- <TD>
- Add
- reference to array to the rows for: a.front(), a. back(), a[n]
- a.at(n). Add reference to forward_list to the rows for: a.front(),
- a.emplace_front(args), a.push_front(t), a.push_front(rv),
- a.pop_front(). Add reference to basic_string to the row for:
- a.at(n). 
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 234
- </TD>
- <TD>
- 23.1.3
- </TD>
- <TD>
- Table
- 84
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Ther
- reference to iterator in semantics for back should also allow for
- const_iterator when called on a const-qualified container. This
- would be ugly to specify in the 03 standard, but is quite easy
- with the addition of auto in this new standard.
- 
- 
- </TD>
- <TD>
- Replace
- iterator with auto in semantics for back: { auto tmp = a.end();
- --tmp; return *tmp; }
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 235
- </TD>
- <TD>
- 23.1.3
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- “The
- library provides three basic kinds of sequence containers: vector,
- list, and deque” - text appears to be out of date re
- addition of array and forward_list
- </TD>
- <TD>
- Change
- the text to read: “The library provides five basic kinds of
- sequence containers: array, deque, forward_list, list and vector”.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 236
- </TD>
- <TD>
- 23.1.3
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- [
- I've moved (1) into a separate comment because I believe it is
- editorial in the simple sense, whereas (2) and (3) are not so
- straight forward ] (2) “vector is the type of sequence
- container that should be used by default” -- As I understand
- it vector was considered first port of call because the things it
- has in common with the native array make programmers (especially
- those new to the container library) feel like they are on familiar
- territory. However, we now have the array container, so I think
- this should be recommended as the first port of call. (3) This
- paragraph is actually giving guidance on the use of the containers
- and should not be normative text
- 
- 
- </TD>
- <TD>
- Remove
- this paragraph
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 237
- </TD>
- <TD>
- 23.1.3
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- vector,
- list, and deque offer the programmer different complexity
- trade-offs and should be used accordingly - this ignores array and
- forward_list
- </TD>
- <TD>
- Modify
- the text to read: "array, deque, forward_list, list and
- vector offer the programmer different complexity trade-offs and
- should be used accordingly"
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 238
- </TD>
- <TD>
- 23.1.4
- </TD>
- <TD>
- 6
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Leaving
- it unspecified whether or not iterator and const_iterator are the
- same type is dangerous, as user code may or may not violate the
- One Definition Rule by providing overloads for both types. It is
- probably too late to specify a single behaviour, but implementors
- should document what to expect. Observing that problems can be
- avoided by users restricting themselves to using const_iterator,
- add a note to that effect.
- 
- 
- </TD>
- <TD>
- Change
- 'unspecified' to 'implementation defined'. Add "[Note: As
- itererator and const_iterator have identical semantics in this
- case, and iterator is convertible to const_iterator, users can
- avoid violating the One Definition Rule by always using
- const_iterator in their function parameter lists -- end note]
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 239
- </TD>
- <TD>
- 23.1.4
- </TD>
- <TD>
- 85
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- It
- is not possible to take a move-only key out of an unordered
- container, such as (multi)set or (multi)map, or the new hashed
- containers.
- </TD>
- <TD>
- Add
- below a.erase(q), a.extract(q), with the following notation:
- a.extract(q), Return type pair<key, iterator> Extracts the
- element pointed to by q and erases it from the set. Returns a pair
- containing the value pointed to by q and an iterator pointing to
- the element immediately following q prior to the element being
- erased. If no such element exists,returns a.end().
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 240
- </TD>
- <TD>
- 23.1.6.1
- </TD>
- <TD>
- 12
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- axiom EmplacePushEquivalence should be asserting the stronger
- contract that emplace and insert return the same iterator value,
- not just iterators that dereference to the same value. This is a
- similar statement that is easier to express and should be
- equivalent - the idea that insert and emplace might return
- iterator values that do not compare equal but point to the same
- element should fail somewhere in the iterator concepts. Also, this
- axiom should be renamed to reflect its connection with insert,
- rather than push_front/push_back,
- 
- 
- </TD>
- <TD>
- Remove
- the * to deference the returned iterator either side of the == in
- the EmplacePushEquivalence axiom, rename the axiom
- EmplacementInsertionEquivalence : requires InsertionContainer<C>
- && Constructible<value_type, Args...> axiom
- EmplacementInsertionEquivalence(C c, const_iterator position,
- Args... args) { emplace(c, position, args...) == insert(c,
- position, value_type(args...)); }
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 57
- </TD>
- <TD>
- 23.1.6.3
- </TD>
- <TD>
- 
- 1st
- paragraph, 4th
- line
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- Typo, duplicated "to"
- 
- "to
- to model insertion
- container concepts."
- </TD>
- <TD>
- 
- Remove one.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 241
- </TD>
- <TD>
- 23.2.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- std::array
- does not have an allocator, so need to document an exception to
- the requirements of 23.1.1p3
- 
- 
- </TD>
- <TD>
- add
- exception to 23.1.1p3
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 242
- </TD>
- <TD>
- 23.2.1
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- std::
- qualification no longer needed for reverse_iterator.
- </TD>
- <TD>
- remove
- std:: qualification from std::reverse_iterator<iterator> and
- std::reverse_iterator<const_iterator>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 243
- </TD>
- <TD>
- 23.2.1
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Most
- containers, and types in general have 3 swaps: swap(T&, T&)
- swap(T&&, T&) swap(T&, T&&) But array only
- has swap(T&, T&).
- 
- 
- </TD>
- <TD>
- add
- the other two swaps.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 244
- </TD>
- <TD>
- 23.2.1,
- 23.2.6
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- validity of the expression &a[n] == &a[0] + n is
- contingent on operator& doing the “right thing”
- (as captured by the CopyConstructible requirements in table 30 in
- C++2003). However this constraint has been lost in the Concepts of
- C++0x. This applies to vector and array (it actually applies to
- string also, but that's a different chapter, so I'll file a
- separate comment there and cross-reference).
- 
- 
- </TD>
- <TD>
- Define
- a ContiguousStrorage and apply it to vector,array and string. The
- Concept (supplied by Alisdair M) looks like this: Concept<
- typename C > ContiguousStrorage { requires Container<C>;
- typename value_type = C::value_type; value_type * data( C ); axiom
- Contiguous { C c; true = equal_ranges( data( c), data(c) +
- size(c), begin(c)); } };
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 245
- </TD>
- <TD>
- 23.2.3
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- predicate types used in special member function of forward_list
- should be CopyConstructible, as per the algorithms of the same
- name. Note: an alternate solution would be to require these
- callable concepts to be CopyConstructible in clause 20, which
- would simplify the library specification in general. See earlier
- comment for details, that would render this one redundant.
- </TD>
- <TD>
- Add
- CopyConstructible requirement to the following signatures:
- template <Predicate<auto, T> Pred> requires
- CopyConstructible<Pred> void remove_if(Pred pred); template
- <EquivalenceRelation<auto, T> BinaryPredicate>
- requires CopyConstructible<BinaryPredicate> void
- unique(BinaryPredicate binary_pred); template
- <StrictWeakOrder<auto, T> Compare> requires
- CopyConstructible<Compare> void
- merge(forward_list<T,Alloc>&& x, Compare comp);
- template <StrictWeakOrder<auto, T> Compare> requires
- CopyConstructible<Compare> void sort(Compare comp); 
- 
- 
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 58
- </TD>
- <TD>
- 23.2.3.2
- </TD>
- <TD>
- 
- 1st
- line before 1st
- paragraph 
- 
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- Unnecessary "{"
- exists before a word iterator like "{iterator
- before_begin()".
- </TD>
- <TD>
- 
- Remove "{"
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 59
- </TD>
- <TD>
- 23.2.4.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- Types of the third and forth
- parameter of splice() are iterator at 23.2.4.4, though types of
- them are const_iterator at 23.2.4. (They are both const_iterator
- on N2350)
- </TD>
- <TD>
- 
- Correct as follows.
- 
- void splice(const_iterator
- position, list<T,Allocator>&& x, iterator i);
- 
- void splice(const_iterator
- position, list<T,Allocator>&& x,
- 
- iterator first,
- iterator last);
- 
- 
- 
- 
- should be
- 
- 
- 
- 
- void splice(const_iterator
- position, list<T,Allocator>&& x, const_iterator i);
- 
- void splice(const_iterator
- position, list<T,Allocator>&& x,
- 
- const_iterator
- first, const_iterator last);
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 83
- </TD>
- <TD>
- 23.2.6.2
- </TD>
- <TD>
- 7
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- "shrink_to_fint"
- should be "shrink_to_fit".
- 
- 
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 246
- </TD>
- <TD>
- 23.3.2.2
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- content of this sub-clause is purely trying to describe in words
- the effect of the requires clauses on these operations, now that
- we have Concepts. As such, the desctiption is more confusing than
- the signature itself. The semantic for these functions is
- adequately covered in the requirements tables in 23.1.4.
- 
- 
- </TD>
- <TD>
- Strike
- 23.3.2.2 entirely. (but do NOT strike these signatures from the
- class template definition!)
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 247
- </TD>
- <TD>
- 24.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ge
- </TD>
- <TD>
- Iterator
- concepts are not extensive enough to merit a whole new header, and
- should be merged into <concpts>. This is particularly
- important for supporting the new for loop syntax which requires
- access to the Range concept. The required header to enable this
- syntax shoud have a simple name, like <concepts>, rather
- than something awkward to type like <iterator_concepts>.
- 
- 
- </TD>
- <TD>
- Move
- the concepts of <iterator_concepts> into the <concepts>
- header. We take no position on moving the text from Clause 24 to
- Clause 20 though. 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 248
- </TD>
- <TD>
- 24.1
- </TD>
- <TD>
- 6
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- text "so for any iterator type there is an iterator value
- that points past the last element of a corresponding container"
- is slightly misleading. Iterators can refer into generalised
- ranges and sequences, not just containers. A broader term than
- 'container' should be used.
- 
- 
- </TD>
- <TD>
- Replace
- the reference to container with a more appropriate concept 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 250
- </TD>
- <TD>
- 24.1.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- A
- default implementation should be supplied for the post-increment
- operator to simplify implementation of iterators by users.
- </TD>
- <TD>
- Copy
- the Effects clause into the concept description as the default
- implementation. Assumes a default value for postincrement_result 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 251
- </TD>
- <TD>
- 24.1.1
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- post-increment operator is dangerous for a general InputIterator.
- The multi-pass guarantees that make it meaningful are defined as
- part of the ForwardIterator refinement. Any change will affect
- only constrained templates that have not yet been written, so
- should not break existing user iterators which remain free to add
- these operations. This change will also affect the generalised
- OutputIterator, although there is no percieved need for the
- post-increment operator in this case either.
- 
- 
- </TD>
- <TD>
- Move
- declaration of postincrement operator and postincrement_result
- type from Interator concept to the ForwardIterator concept
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- UK 252
- 
- 
- </TD>
- <TD>
- 24.1.2
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- istream_iterator
- is not a class, but a class template
- </TD>
- <TD>
- Change
- 'class' to 'class template' in the note. 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 253
- </TD>
- <TD>
- 24.1.3
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- First
- sentance does not make gramatical sense, Seems to be missing the
- words 'if it' by comparison with similar sentance in other
- subsections
- 
- 
- </TD>
- <TD>
- Add
- the words 'if it' : "X satisfies the requirements of an
- output iterator IF IT meets the syntactic and semantic
- requirements" 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 254
- </TD>
- <TD>
- 24.1.3
- </TD>
- <TD>
- 5
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- This
- postcondition for pre-increment operator should be written as an
- axiom
- 
- 
- </TD>
- <TD>
- Move
- the postcondition into the concept definition as an axiom 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 255
- </TD>
- <TD>
- 24.1.4
- </TD>
- <TD>
- 4
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- This
- postcondition for pre-increment operator should be written as an
- axiom
- 
- 
- </TD>
- <TD>
- Move
- the postcondition into the concept definition as an axiom 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 256
- </TD>
- <TD>
- 24.1.5
- </TD>
- <TD>
- 3,
- 4, 5
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- relationship between pre- and post- decrement should be expressed
- as an axiom.
- </TD>
- <TD>
- Move
- the text specification of pre/post-conditions and behaviour into
- an axiom within the BidirectionalIterator concept 
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 257
- </TD>
- <TD>
- 24.1.5
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- There
- is a reasonable default for postdecrement_result type, which is X.
- X is required to be regular, therefore CopyConstructible and a
- valid ResultType. Together with the next comment this simplifies
- user defined iterator implentations
- 
- 
- </TD>
- <TD>
- Add
- the default : typename postincrement_result = X; 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 258
- </TD>
- <TD>
- 24.1.5
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- A
- default implementation should be supplied for the post-decrement
- operator to simplify implementation of iterators by users.
- 
- 
- </TD>
- <TD>
- Copy
- the Effects clause into the concept description as the default
- implementation. Assumes a default value for postincrement_result 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 259
- </TD>
- <TD>
- 24.1.5
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- postdecrement_result
- is effectively returning a copy of the original iterator value, so
- should have similar constraints, rather than just HasDereference.
- If Concepts do not support this circularity of definition suggest
- that concepts feature may want a little more work
- 
- 
- </TD>
- <TD>
- Add
- the requirement: requires Iterator< postdecrement_result >; 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 260
- </TD>
- <TD>
- 24.1.5
- </TD>
- <TD>
- 6
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- effects clause for post-decrement iterator should be available as
- an axiom and a default implementation, where the compiler can make
- better use of it.
- </TD>
- <TD>
- Move
- the Effects clause into the BidirectionalIterator concept
- definition as an axiom, and as the default implementation for the
- operation.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 249
- </TD>
- <TD>
- 24.1.6
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- semantic for operator+= should also be provided as a default
- implementation to simplify implementation of user-defined
- iterators
- 
- 
- </TD>
- <TD>
- Copy
- the text from the effects clause into the RandomAccessIterator
- concept as the default implementaiton.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 261
- </TD>
- <TD>
- 24.1.6
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- To
- simplify user defined random access iterator types, the
- subscript_reference type should default to reference
- 
- 
- </TD>
- <TD>
- typename
- subscript_reference = reference; 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 262
- </TD>
- <TD>
- 24.1.6
- </TD>
- <TD>
- 3,
- 4
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Effects
- and post-conditions for operator+ are more useful if expressed as
- axioms, and supplied as default implementations.
- </TD>
- <TD>
- Move
- the effects and Postcondition definitions into the
- RandomAccessIterator concept and copy the code in the
- specification as the default implementation of these operations.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 263
- </TD>
- <TD>
- 24.1.6
- </TD>
- <TD>
- 5
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- This
- requirement on operator-= would be better expressed as a default
- implementation in the concept, with a matching axiom
- </TD>
- <TD>
- Move
- the specification for operator-= from the returns clause into an
- axiom and default implementation within the RandomAccessIterator
- concept
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 264
- </TD>
- <TD>
- 24.1.6
- </TD>
- <TD>
- 6
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Effects
- clauses are better expressed as axioms where possible.
- </TD>
- <TD>
- Move
- code in operator- effects clause into RandomAccessIterator concept
- as both a default implementation and an axiom
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 265
- </TD>
- <TD>
- 24.1.6
- </TD>
- <TD>
- 8
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- This
- effects clause is nonesense. It looks more like an axiom stating
- equivalence, and certainly an effects clause cannot change the
- state of two arguments passed by const reference
- 
- 
- </TD>
- <TD>
- Strike
- the Effects clause
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 266
- </TD>
- <TD>
- 24.1.6
- </TD>
- <TD>
- 9
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- This
- sentance should be provided as a default definition, along with a
- matching axiom
- </TD>
- <TD>
- Move
- the Returns clause into the spefication for RandomAccessIterator
- operator- as a default implementation. Move the Effects clause as
- the matching axiom.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 267
- </TD>
- <TD>
- 24.1.6
- </TD>
- <TD>
- 24.1.6
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- code in the Requires clause for RandomAccessIterator operator[]
- would be better expressed as an axiom.
- 
- 
- </TD>
- <TD>
- Rewrite
- the Requires clause as an axiom in the RandomAccessIterator
- concept
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 268
- </TD>
- <TD>
- 24.1.6
- </TD>
- <TD>
- 12
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- This
- note is potentialy confusing as __far enters the syntax as a clear
- language extension, but the note treats it as a regular part of
- the grammar. It might be better expressed using attributes in the
- current wording.
- 
- 
- </TD>
- <TD>
- Clean
- up the note to either avoid using language extension, or spell out
- this is a constraint to support extensions.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 60
- </TD>
- <TD>
- 24.1.8
- </TD>
- <TD>
- 1st
- paragraph
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- Capability of an iterator is
- too much restricted by concept.
- 
- 
- 
- 
- Concept of std::Range is
- defined as:
- 
- 
- 
- 
- concept Range<typename T>
- {
- 
- InputIterator iterator;
- 
- iterator begin(T&);
- 
- iterator end(T&);
- 
- }
- 
- 
- 
- 
- So the following code
- generates an error.
- 
- 
- 
- 
- template <std::Range Rng>
- 
- void sort(Rng& r)
- 
- {
- 
- // error! Rng::iterator does
- not satisfy requirements of a random
- 
- // access iterator.
- 
- std::sort(begin(r), end(r));
- 
- }
- 
- 
- 
- 
- std::vector<int> v; //
- vector::iterator is a random access iterator.
- 
- sort(v);
- 
- 
- 
- 
- This is because the concept of
- an iterator of std::Range is InputIterator. For this reason, a
- random access iterator loses its capability when passed to a
- std::Range parameter.
- 
- 
- 
- 
- To be able to work the above
- code, we need to write as follows:
- 
- 
- 
- 
- template <std::Range T>
- 
- requires
- std::RandomAccessIterator<T::iterator> &&
- 
- std::ShuffleIterator<T::iterator>
- &&
- 
- std::LessThanComparable<T::iterator::value_type>
- 
- void sort(T& r)
- 
- {
- 
- sort(begin(r), end(r));
- 
- }
- 
- 
- 
- 
- std::vector<int> v;
- 
- sort(v);
- 
- 
- 
- 
- It needs quiet a few amount of
- codes like this only to recover random access capability from
- InputIterator concept.
- 
- 
- 
- 
- We can write the following
- valid code with Boost.Range, which is implemented with using C++03
- SFINAE.
- 
- 
- 
- 
- template <class Range>
- 
- void sort(Range& r)
- 
- {
- 
- std::sort(boost::begin(r),
- boost::end(r));
- 
- }
- 
- 
- 
- 
- std::vector<int> v;
- 
- sort(v); // OK
- 
- 
- 
- 
- One of the motivation to
- introduce concepts are supporting template programming techniques
- by language directly to eliminate hacky techniques such as
- tag-dispatch, SFINAE and Type Traints. But SFINAE will be kept
- using because it needs quite a few amount of codes without using
- SFAINAE.
- 
- 
- 
- </TD>
- <TD>
- 
- Add InputRange, OutputRange,
- ForwardRange, BidirectionalRange and RandomAccessRange.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 269
- </TD>
- <TD>
- 24.3
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- 'decrements
- for negative n' seems to imply a negative number of decrement
- operations, which is odd.
- 
- 
- </TD>
- <TD>
- Need
- simple, clearer wording
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 270
- </TD>
- <TD>
- 24.3
- </TD>
- <TD>
- 4
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- reachability constraint in p5 means that a negavite result,
- implying decrements operations in p4, is not possible
- 
- 
- </TD>
- <TD>
- Split
- the two overloads into separate descriptions, where reachability
- is permitted to be in either direction for RandomAccessIterator
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 271
- </TD>
- <TD>
- 24.3
- </TD>
- <TD>
- 6,7
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- next/prev
- return an incremented iterator without changing the value of the
- original iterator. However, even this may invalidate an
- InputIterator. A ForwardIterator is required to guarantee the
- 'multipass' property.
- 
- 
- </TD>
- <TD>
- Replace
- InputIterator constraint with FOrwardIterator in next and prev
- function templates.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 272
- </TD>
- <TD>
- 24.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- reverse_iterator
- and move_iterator use different formulations for their comparison
- operations. move_iterator merely requires the minimal set of
- operations, < and ==, from its underlying iterator and
- synthesizes all oprations from these two. reverse_iterator relies
- on the undelying iterator to support all comparision operations
- directly. In practice, move_iterator can only be implemented this
- way as it must support iterator types that are merely
- InputIterators, and so SemiRegular and not Regular. However,
- reserse_iterator has an existing specification and any change of
- semantic could change behaviour of conforming programs today -
- although an iterator that yields different results for (a > b)
- than (b < a) may fall foul of some semantic consistency
- requirements, even if the syntax is met.
- 
- 
- </TD>
- <TD>
- Rephrase
- the reverse_iterator comparison operations using only operators <
- and ==, as per the move_iterator specification.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 274
- </TD>
- <TD>
- 24.4,
- 24.5
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- subclauses for standard iterator adaptors could be better
- organised. There are essentially 3 kinds of iterator wrappers
- provided, stream iterators adapt streams and get their own
- subsection. insert iterators adapt containers, and get their own
- subsection but it is inserted into the middle of 24.4 Predifined
- iterators. reverse_iterator and move_iterator adpat other
- iterators, but their presentation is split by insert iterators
- 
- 
- </TD>
- <TD>
- Promote
- 24.4.2 [insert.iterators] up one level to 24.6. Emphasize that
- insert iterators adapt containers Retarget 24.4 [predef.iterators]
- as iterator adapters for iterator templates that wrap other
- iterators.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 275
- </TD>
- <TD>
- 24.4.1.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- constructor template taking a single Iterator argument will be
- selected for Copy Initialization instead of the non-template
- constructor taking a single Iterator argument selected by Direct
- Initialization.
- 
- 
- </TD>
- <TD>
- The
- reverse_iterator template constructor taking a single Iterator
- argument should be explicit.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 276
- </TD>
- <TD>
- 24.4.1.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- It
- is odd to have a mix of declaration stlyes for operator+
- overloads. Prefer if either all are member functions, or all are
- 'free' functions.
- 
- 
- </TD>
- <TD>
- Make
- the member operators taking a difference_type argument non-member
- operators
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 277
- </TD>
- <TD>
- 24.4.1.2.1
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- default constructor default-initializes current, rather than
- value-initializes. This means that when Iterator corresponds to a
- trivial type, the current member is left un-initialized, even when
- the user explictly requests value intialization! At this point, it
- is not safe to perform any operations on the reverse_iterator
- other than assign it a new value or destroy it. Note that this
- does correspond to the basic definition of a singular iterator.
- 
- 
- </TD>
- <TD>
- i/
- Specify value initialization rather than default intialization or
- ii/ specify = default; rather than spell out the semantic. This
- will at least allow users to select value initialization and copy
- the iterator value. or iii/ Add a note to the description
- emphasizing the singular nature of a value-initialized reserve
- iterator.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 278
- </TD>
- <TD>
- 24.4.1.2.1
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- There
- is an inconsistency between the constructor taking an iterator and
- the constructor template taking a reverse_iterator where one
- passes by value, and the other by const reference. The by-value
- form is preferred as it allows for efficient moving when copy
- elision fails to kick in.
- 
- 
- </TD>
- <TD>
- Change
- the const reverse_iterator & parameter to
- pass-by-value
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 279
- </TD>
- <TD>
- 24.4.1.2.12,
- 24.4.3.2.12
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- reason the return type became unspecified is LWG issue 386. This
- reasoning no longer applies as there are at least two ways to get
- the right return type with the new language facilities added since
- the previous standard.
- 
- 
- </TD>
- <TD>
- Specify
- the return type using either decltype or the Iter concept map
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 280
- </TD>
- <TD>
- 24.4.1.2.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- presence of the second iterator value is surprising for many
- readers who underestimate the size of a reverse_iterator object.
- Adding the exposition only member that is required by the semantic
- will reduce confusion.
- 
- 
- </TD>
- <TD>
- Add
- reverse_iterator expsoition only member tmp as a comment to class
- declaration, as a private member
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 281
- </TD>
- <TD>
- 24.4.1.2.5
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- current specification for return value will always be a true
- pointer type, but reverse_iterator supports proxy iterators where
- the pointer type may be some kind of 'smart pointer'
- 
- 
- </TD>
- <TD>
- Replace
- the existing returns specification with a copy of the operator*
- specification that returns this->tmp.operator->
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 282
- </TD>
- <TD>
- 24.4.2.1,
- 24.4.2.2.2, 24.4.2.3, 24.4.2.4.2, 24.4.2.5, 24.4.2.6.2
- </TD>
- <TD>
- n/a
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Insert
- iterators of move-only types will move from lvalues
- </TD>
- <TD>
- Add
- an additional constrained overload for operator= that requires
- !CopyConstructible<Cont::value_type> and mark it =delete.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 283
- </TD>
- <TD>
- 24.4.2.5,
- 24.4.2.6.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- postincrement
- operator overloads traditionally return by value - insert_iterator
- is declared as return by reference. The change is harmless in this
- case, but either front/back_insert_iterator should take the
- matching change for consistency, or this function should
- return-by-value
- </TD>
- <TD>
- change
- operator++(int) overload to return by value, not reference.
- Affects both class summary and operator definition in p
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 61
- </TD>
- <TD>
- 24.4.3.2.1
- </TD>
- <TD>
- 2nd
- paragraph, 1st
- line
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- Typo.
- 
- "intializing"
- should be "initializing"
- </TD>
- <TD>
- 
- Add "i"
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 284
- </TD>
- <TD>
- 24.5
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- stream iterators need constraining with concepts/requrires
- clauses.
- 
- 
- </TD>
- <TD>
- Provide
- constraints
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 285
- </TD>
- <TD>
- 24.5.1
- </TD>
- <TD>
- 1,2
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Much
- of the content of p1 and the whole of p2 is a redundant
- redefinition of InputIterator. It should be simplified
- 
- 
- </TD>
- <TD>
- Strike
- p2. Simplify p1 and add a cross-reference to the definition of
- InputIterator concept.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 286
- </TD>
- <TD>
- 24.5.1
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- To
- the casual reader it is not clear if it is intended to be able to
- assign to istream_iterator objects. Specifying the copy
- constructor but relying on the implicit copy-assign operator is
- confusing.
- 
- 
- </TD>
- <TD>
- Either
- provide a similar definition to the copy-assign operator as for
- the copy constructor, or strike the copy constructor
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 287
- </TD>
- <TD>
- 24.5.1.1
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- It
- is not clear what the intial state of an istream_iterator should
- be. Is _value_ initialized by reading the stream, or default/value
- initialized? If it is initialized by reading the stream, what
- happens if the initialization is deferred until first dereference,
- when ideally the iterator value should have been that of an
- end-of-stream iterator which is not safely dereferencable?
- 
- 
- </TD>
- <TD>
- Specify
- _value_ is initialized by reading the stream, or the iterator
- takes on the end-of-stream value if the stream is empty
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 288
- </TD>
- <TD>
- 24.5.1.1
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- provided specification is vacuous, offering no useful information.
- </TD>
- <TD>
- Either
- strike the specification of the copy constructor, or simply
- replace it with an = default definition.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 289
- </TD>
- <TD>
- 24.5.1.2
- </TD>
- <TD>
- 6
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- It
- is very hard to pick up the correct specification for
- istream_iterator::operator== as the complete specification
- requires reading two quite disconnected paragraphs, 24.5.1p3, and
- 24.5.1.2p6. Reading just the specifaction of the operation itself
- suggests that end-of-stream iterators are indistinguishable from
- 'valid' stream iterators, which is a very dangerous misreading.
- 
- 
- </TD>
- <TD>
- Merge
- 24.5.1p3, equality comparison of end-of-stream-iterators, into
- 24.5.1.2p6, the specification of the equality operator for
- istream_iterator.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 290
- </TD>
- <TD>
- 24.5.2
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- character type of a string delimiter for an ostream_iterator
- should be const charT *, the type of the elements, not char *, a
- narrow character string.
- 
- 
- </TD>
- <TD>
- Replace
- char * with const charT *
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 291
- </TD>
- <TD>
- 24.5.2.2
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- ostream_iterator
- postincrement operator returns by reference rather than by value.
- This may be a small efficiency gain, but it is otherwise
- unconventional. Prefer return-by-value.
- 
- 
- </TD>
- <TD>
- ostream_iterator
- operator++(int);
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 34
- </TD>
- <TD>
- 24.5.3
- [istreambuf.iterator]
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- There
- are two public sections, and the content of the second one is
- indented with respect to the first. I don't it should be.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 292
- </TD>
- <TD>
- 24.5.3
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Prefer
- the use of the new nullptr constant to the zero literal when using
- a null pointer in text.
- 
- 
- </TD>
- <TD>
- Change
- istreambuf_iterator(0) to istreambuf_iterator(nullptr)
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 293
- </TD>
- <TD>
- 24.5.3
- </TD>
- <TD>
- 2,3,4
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- listed paragraphs redundantly redefine an input iterator, and
- redundancy can be a dangerous thing in a specification. Suggest a
- simpler phrasing below.
- </TD>
- <TD>
- 2.
- The result of operator*() on an end of stream is undefined. For
- any other iterator value a char_type value is returned. 3. Two end
- of stream iterators are always equal. An end of stream iterator is
- not equal to a non-end of stream iterator. 4. As
- istreambuf_iterator() is an InputIterator but not a
- ForwardIterator, istreambuf_iterators object can be used only for
- one-pass algorithms. It is not possible to assign a character via
- an input iterator. 
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 294
- </TD>
- <TD>
- 24.5.3.2
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Implicit
- converting constructors can be invoked at surprising times, so
- there should always be a good reason for declaring one.
- </TD>
- <TD>
- Mark
- the two single-argument constructors take a stream or stream
- buffer as explicit. The proxy constructor should remain implicit.
- explicit istreambuf_iterator(basic_istream<charT,traits>&
- s) throw(); explicit
- istreambuf_iterator(basic_streambuf<charT,traits>* s)
- throw(); 
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 295
- </TD>
- <TD>
- 25
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- THere
- is a level of redundancy in the library specification for many
- algorithms that can be eliminated with the combination of concepts
- and default parameters for function templates. Eliminating
- redundancy simplified specification and reduces the risk of
- inttroducing accidental inconsistencies.
- 
- 
- </TD>
- <TD>
- Adopt
- n2743, or an update of that paper.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 62
- </TD>
- <TD>
- 25,
- 25.3.1.5, 26.3.6.5
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- The return types of
- is_sorted_until function and is_heap_until function are iterator.
- But basically, the return type of is_xxx function is bool. And the
- return type of lower_bound function and upper_bound is iterator.
- 
- So we think that it is
- reasonable to change those two functions.
- 
- 
- 
- </TD>
- <TD>
- 
- Change "is_sorted_until"
- to "sorted_bound"
- 
- Change "is_heap"
- to "heap_bound"
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 296
- </TD>
- <TD>
- 25.1.8
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- 'Returns' of adjacent_find requires only HasEqualTo, or a
- Predicate. Requiring EqualityComparable or EquivalenceRelation
- seems too strong and not useful.
- 
- 
- </TD>
- <TD>
- Change
- EqualityComparable to HasEqualTo and EquivalnceRelation to
- Predicate
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 297
- </TD>
- <TD>
- 25.2.11
- </TD>
- <TD>
- 6
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- definition of rotate_copy is very complicated. It is equivalent
- to: return copy(first, middle, copy(middle, last, result));
- 
- 
- </TD>
- <TD>
- Change
- 'effects' to, returns, requires, complexity to: effects:
- equivalent to: return copy(first, middle, copy(middle, last,
- result));
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 298
- </TD>
- <TD>
- 25.2.13
- </TD>
- <TD>
- 13
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- partition_point
- requires a partitioned array
- </TD>
- <TD>
- requires:
- is_partitioned(first, last, pred) != false;
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 299
- </TD>
- <TD>
- 25.2.2
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Should
- be consistent in style use of concepts in template parameter
- lists. The auto-OutputIterator sytle used in std::copy is probably
- preferred.
- </TD>
- <TD>
- Change
- way signature is declared: template<InputIterator InIter,
- OutputIterator<auto, RvalueOf<InIter::reference>::type>
- OutIter> OutIter move(InIter first, InIter last, OutIter
- result); 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 300
- </TD>
- <TD>
- 25.2.3
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Since
- publishing the original standard, we have learned that swap is a
- fundamental operation, and several common idioms rely on it -
- especially those related to exception safety. As such it belongs
- in the common <utility> header rather than the broader
- <algorithm> header, and likewise should move to clause 20.
- For backwards compatiblility the algorithm header should be
- required to #include <utility>, which would be covered in
- the resolution of LWG issue 343. There are already dependencies in
- <algorithm> on types declared in this header, so this
- comment does not create a new dependency.
- 
- 
- </TD>
- <TD>
- Move
- primary swap template from <algorithm> into <utility>.
- Move 25.2.3 to somewhere under 20.2. Require <algorithm> to
- #include <utility> to access pair and provide legacy support
- for finding swap.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 301
- </TD>
- <TD>
- 25.2.5
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- replace
- and replace_if have the requirement: OutputIterator<Iter,
- Iter::reference> Which implies they need to copy some values in
- the range the algorithm is iterating over. This is not however the
- case, the only thing that happens is const T&s might be copied
- over existing elements (hence the OutputIterator<Iter, const
- T&>
- 
- 
- </TD>
- <TD>
- Remove
- OutputIterator<Iter, Iter::reference> from replace and
- replace_if
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 302
- </TD>
- <TD>
- 25.3
- </TD>
- <TD>
- 4
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- the
- concept StrictWeakOrder covers the definition of a strict weak
- ordering, described in paragraph 4.
- 
- 
- </TD>
- <TD>
- Remove
- 4, and mention StrictWeakOrder in paragraph 1.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 303
- </TD>
- <TD>
- 25.3
- </TD>
- <TD>
- 6
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- This
- paragraph just describes is_partitioned
- </TD>
- <TD>
- 6
- A sequence [start,finish) is partitioned with respect to an
- expression f(e) if is_partitioned(start, finish, e) != false
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 304
- </TD>
- <TD>
- 25.3.6
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- requires clauses of push_heap, pop_heap and make_heap are
- inconsistently formatted, dispite being identical
- 
- 
- </TD>
- <TD>
- Format
- them identically.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 305
- </TD>
- <TD>
- 25.3.7
- </TD>
- <TD>
- 1,
- 9, 17
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- negative requirement on IsSameType is a hold-over from an earlier
- draught with a variadic template form of min/max algorith. It is
- no longer necessary.
- </TD>
- <TD>
- Strike
- the !IsSameType<T, Compare> constraint on min/max/minmax
- algorithms
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 84
- </TD>
- <TD>
- 26
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ge
- </TD>
- <TD>
- 
- Parts of the numerics chapter
- are not concept enabled.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 35
- </TD>
- <TD>
- 26.3
- [Complex numbers]
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- Instantiations
- of the class template complex<> have to be allowed for
- integral types, to reflect existing practice and ISO standards
- (LIA-III).
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 306
- </TD>
- <TD>
- 26.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Random
- number library component cannot be used in constrained templates
- 
- 
- </TD>
- <TD>
- Provide
- constraints for the random number library 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 63
- </TD>
- <TD>
- 26.4.8.5.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- No constructor of
- discrete_distribution that accepts initializer_list.
- 
- discrete_distribution
- initialize distribution by a given range (iterators), but
- temporary variable of a container or an array is needed in the
- following case.
- 
- 
- 
- 
- int ar[] = {1, 2, 3};
- 
- discrete_distribution<>
- dist(ar, ar+3);
- 
- 
- 
- 
- Other libraries also accept
- initializer_list, so change discrete_distribution library to
- accept initializer_list too.
- 
- 
- 
- </TD>
- <TD>
- 
- Add the following constructer.
- 
- discrete_distribution(initializer_list<result_type>);
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 64
- </TD>
- <TD>
- 26.5.2
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- “valarray<T>&
- operator+= (initializer_list<T>);” is not defined.
- 
- 
- 
- </TD>
- <TD>
- 
- Add valarray<T>&
- operator+= (initializer_list<T>);
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 307
- </TD>
- <TD>
- 26.7
- </TD>
- <TD>
- Footnote
- 288
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- The
- footnote refers to TR1, which is not a defined term in this
- standard. Drop the reference to TR1, those templates are a regular
- part of the standard now and how they were introduced is no longer
- relevant.
- 
- 
- </TD>
- <TD>
- Drop
- the reference to TR1.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 85
- </TD>
- <TD>
- 27
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ge
- </TD>
- <TD>
- 
- The input/output chapter is
- not concept enabled.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 308
- </TD>
- <TD>
- 27
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- 
- iostreams
- library cannot be used from constrained templates
- 
- 
- </TD>
- <TD>
- Provide
- constraints for the iostreams library, clause 27 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 65
- </TD>
- <TD>
- 27.4.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- Switch from
- “unspecified-bool-type” to　“explicit
- operator bool() const”.
- 
- 
- 
- </TD>
- <TD>
- 
- Replace
- "operator unspecified-bool-type()
- const;" with "explicit operator bool() const;"
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 66
- </TD>
- <TD>
- 27.4.4.3
- </TD>
- <TD>
- 1st
- paragraph
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- Switch from
- “unspecified-bool-type” to　“explicit
- operator bool() const”
- 
- 
- 
- </TD>
- <TD>
- 
- Replace
- "operator unspecified-bool-type()
- const;" with "explicit operator bool() const;"
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 36
- </TD>
- <TD>
- 
- 27.6.1.2.2
- [istream.formatted.arithmetic]
- </TD>
- <TD>
- 1,
- 2, and 3
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- iostate
- err = 0;
- 
- 
- 
- iostate
- is a bitmask type and so could be an enumeration. Probably using
- 
- goodbit
- is the solution.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 37
- </TD>
- <TD>
- 27.6.1.2.2
- [istream.formatted.arithmetic]
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- else
- if (lval < numeric_limits<int>::min()
- 
- ||
- numeric_limits<int>::max() < lval))
- 
- 
- 
- The
- parentheses aren't balanced.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 67
- </TD>
- <TD>
- 27.7.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- basic_stringbuf dose not use
- concept.
- </TD>
- <TD>
- 
- Replace “class
- Allocator” to “Allocator Alloc”.
- 
-   Correct as follows.
- 
- 
- 
- 
- namespace std {
- 
- template <class charT,
- class traits = char_traits<charT>,
- 
- Allocator
- Alloc =
- allocator<charT> >
- 
- class basic_stringbuf :
- public basic_streambuf<charT,traits> {
- 
- public:
- 
- ...
- 
- 
- 
- 
- // 27.7.1.1 Constructors:
- 
- explicit
- basic_stringbuf(ios_base::openmode which
- 
- =
- ios_base::in | ios_base::out);
- 
- explicit basic_stringbuf
- 
- (const
- basic_string<charT,traits,Alloc>&
- str,
- 
- ios_base::openmode which
- = ios_base::in | ios_base::out);
- 
- basic_stringbuf(basic_stringbuf&&
- rhs);
- 
-  
- 
- ...
- 
-  
- 
-
- 
- 
- // 27.7.1.3 Get and set:
- 
- basic_string<charT,traits,Alloc>
- str() const;
- 
- void
- str(const basic_string<charT,traits,Alloc>&
- s);
- 
-  
- 
- ...
- 
- };
- 
-
- 
- 
- template
- <class charT, class traits, Allocator
- Alloc>
- 
- void
- swap(basic_stringbuf<charT, traits, Alloc>&
- x,
- 
- basic_stringbuf<charT,
- traits, Alloc>&
- y);
- 
- template
- <class charT, class traits, Allocator
- Alloc>
- 
- void
- swap(basic_stringbuf<charT, traits, Alloc>&&
- x,
- 
- basic_stringbuf<charT,
- traits, Alloc>&
- y);
- 
- template
- <class charT, class traits, Allocator
- Alloc>
- 
- void
- swap(basic_stringbuf<charT, traits, Alloc>&
- x,
- 
- basic_stringbuf<charT,
- traits, Alloc>&&
- y);
- 
- }
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 68
- </TD>
- <TD>
- 27.7.2
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- basic_istringstream dose not
- use concept.
- </TD>
- <TD>
- 
- Replace “class
- Allocator” to “Allocator Alloc”.
- 
-   Correct as follows.
- 
-  
- 
- namespace std {
- 
- template <class charT,
- class traits = char_traits<charT>,
- 
- Allocator
- Alloc =
- allocator<charT> >
- 
- class basic_istringstream :
- public basic_istream<charT,traits> {
- 
- public:
- 
- typedef charT
- char_type;
- 
- typedef typename
- traits::int_type int_type;
- 
- typedef typename
- traits::pos_type pos_type;
- 
- typedef typename
- traits::off_type off_type;
- 
- typedef traits
- traits_type;
- 
- typedef Alloc
- allocator_type;
- 
- 
- 
- 
- // 27.7.2.1 Constructors:
- 
- explicit
- basic_istringstream(ios_base::openmode which = ios_base::in);
- 
- explicit
- basic_istringstream(
- 
- const
- basic_string<charT,traits,Alloc>&
- str,
- 
- ios_base::openmode
- which = ios_base::in);
- 
- basic_istringstream(basic_istringstream&&
- rhs);
- 
-  
- 
- // 27.7.2.2 Assign and
- swap:
- 
- basic_istringstream&
- operator=(basic_istringstream&& rhs);
- 
- void
- swap(basic_istringstream&& rhs);
- 
-
- 
- 
- // 27.7.2.3 Members:
- 
- basic_stringbuf<charT,traits,Alloc>*
- rdbuf() const;
- 
-  
- 
- basic_string<charT,traits,Alloc>
- str() const;
- 
- void
- str(const basic_string<charT,traits,Alloc>&
- s);
- 
-  
- 
- private:
- 
- //
- basic_stringbuf<charT,traits,Alloc>
- sb; exposition only
- 
- };
- 
-  
- 
- template
- <class charT, class traits, Allocator
- Alloc>
- 
- void
- swap(basic_istringstream<charT, traits, Alloc>&
- x,
- 
- basic_istringstream<charT,
- traits, Alloc>&
- y);
- 
- template
- <class charT, class traits, Allocator
- Alloc>
- 
- void
- swap(basic_istringstream<charT, traits, Alloc>&&
- x,
- 
- basic_istringstream<charT,
- traits, Alloc>&
- y);
- 
- template
- <class charT, class traits, Allocator
- Alloc>
- 
- void
- swap(basic_istringstream<charT, traits, Alloc>&
- x,
- 
- basic_istringstream<charT,
- traits, Alloc>&&
- y);
- 
- }
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 69
- </TD>
- <TD>
- 27.7.3
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- basic_ostringstream dose not
- use concept.
- </TD>
- <TD>
- 
- Replace “class
- Allocator” to “Allocator Alloc”.
- 
-   Correct as follows.
- 
- 
- 
- 
- namespace std {
- 
- template <class charT,
- class traits = char_traits<charT>,
- 
- Allocator
- Alloc =
- allocator<charT> >
- 
- class basic_ostringstream :
- public basic_ostream<charT,traits> {
- 
- public:
- 
- // types:
- 
- typedef charT
- char_type;
- 
- typedef typename
- traits::int_type int_type;
- 
- typedef typename
- traits::pos_type pos_type;
- 
- typedef typename
- traits::off_type off_type;
- 
- typedef traits
- traits_type;
- 
- typedef Alloc
- allocator_type;
- 
-  
- 
- // 27.7.3.1
- Constructors/destructor:
- 
- explicit
- basic_ostringstream(ios_base::openmode which = ios_base::out);
- 
- explicit
- basic_ostringstream(
- 
- const
- basic_string<charT,traits,Alloc>&
- str,
- 
- ios_base::openmode
- which = ios_base::out);
- 
- basic_ostringstream(basic_ostringstream&&
- rhs);
- 
-  
- 
- // 27.7.3.2 Assign/swap:
- 
- basic_ostringstream&
- operator=(basic_ostringstream&& rhs);
- 
- void
- swap(basic_ostringstream&& rhs);
- 
-  
- 
- // 27.7.3.3 Members:
- 
- basic_stringbuf<charT,traits,Alloc>*
- rdbuf() const;
- 
- basic_string<charT,traits,Alloc>
- str() const;
- 
- void
- str(const basic_string<charT,traits,Alloc>&
- s);
- 
- private:
- 
- //
- basic_stringbuf<charT,traits,Alloc>
- sb; exposition only
- 
- };
- 
-  
- 
- template
- <class charT, class traits, Allocator
- Alloc>
- 
- void
- swap(basic_ostringstream<charT, traits, Alloc>&
- x,
- 
- basic_ostringstream<charT,
- traits, Alloc>&
- y);
- 
- template
- <class charT, class traits, Allocator
- Alloc>
- 
- void
- swap(basic_ostringstream<charT, traits, Alloc>&&
- x,
- 
- basic_ostringstream<charT,
- traits, Alloc>&
- y);
- 
- template
- <class charT, class traits, Allocator
- Alloc>
- 
- void
- swap(basic_ostringstream<charT, traits, Alloc>&
- x,
- 
- basic_ostringstream<charT,
- traits, Alloc>&&
- y);
- 
- }
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 71
- </TD>
- <TD>
- 27.7.3
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- Typo.
- "template"
- is missing in "class basic_ostringstream" of the title
- of the chapter.
- </TD>
- <TD>
- 
- Correct as follows.
- 
- 27.7.3 Class
- basic_ostringstream
- 
- 
- 
- 
- should be
- 
- 
- 
- 27.7.3
- Class template
- basic_ostringstream
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 72
- </TD>
- <TD>
- 27.7.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- basic_stringstream dose not
- use concept.
- </TD>
- <TD>
- 
- Replace "class Allocator"
- to "Allocator Alloc".
- 
-   Correct as follows.
- 
-  
- 
- namespace std {
- 
- template <class charT,
- class traits = char_traits<charT>,
- 
- Allocator
- Alloc =
- allocator<charT> >
- 
- class basic_stringstream
- 
- : public
- basic_iostream<charT,traits> {
- 
- public:
- 
- // types:
- 
- typedef charT
- char_type;
- 
- typedef typename
- traits::int_type int_type;
- 
- typedef typename
- traits::pos_type pos_type;
- 
- typedef typename
- traits::off_type off_type;
- 
- typedef traits
- traits_type;
- 
- typedef Alloc
- allocator_type;
- 
-  
- 
- // constructors/destructor
- 
- explicit
- basic_stringstream(
- 
- ios_base::openmode which =
- ios_base::out|ios_base::in);
- 
- explicit
- basic_stringstream(
- 
- const
- basic_string<charT,traits,Alloc>&
- str,
- 
- ios_base::openmode which =
- ios_base::out|ios_base::in);
- 
- basic_stringstream(basic_stringstream&&
- rhs);
- 
-  
- 
- // 27.7.5.1 Assign/swap:
- 
- void
- swap(basic_stringstream&& rhs);
- 
-  
- 
- // Members:
- 
- basic_stringbuf<charT,traits,Alloc>*
- rdbuf() const;
- 
- basic_string<charT,traits,Alloc>
- str() const;
- 
- void
- str(const basic_string<charT,traits,Alloc>&
- str);
- 
- private:
- 
- // basic_stringbuf<charT,
- traits> sb; exposition only
- 
- };
- 
-  
- 
- template
- <class charT, class traits, Allocator
- Alloc>
- 
- void
- swap(basic_stringstream<charT, traits, Alloc>&
- x,
- 
- basic_stringstream<charT,
- traits, Alloc>&
- y);
- 
- template
- <class charT, class traits, Allocator
- Alloc>
- 
- void
- swap(basic_stringstream<charT, traits, Alloc>&&
- x,
- 
- basic_stringstream<charT,
- traits, Alloc>&
- y);
- 
- template
- <class charT, class traits, Allocator
- Alloc>
- 
- void
- swap(basic_stringstream<charT, traits, Alloc>&
- x,
- 
- basic_stringstream<charT,
- traits, Alloc>&&
- y);
- 
- }
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 73
- </TD>
- <TD>
- 27.8.1.14
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- It is a problem from C++98,
- fstream cannot appoint a filename of wide character string(const
- wchar_t and const wstring&).
- 
- 
- 
- </TD>
- <TD>
- 
- Add interface corresponding to
- wchar_t, char16_t and char32_t.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 86
- </TD>
- <TD>
- 28
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ge
- </TD>
- <TD>
- 
- The regular expressions
- chapter is not concept enabled.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 309
- </TD>
- <TD>
- 28
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Regular
- expressions cannot be used in constrained templates
- 
- 
- </TD>
- <TD>
- Provide
- constraints for the regular expression library, clause 28 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 310
- </TD>
- <TD>
- 28
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- regex chapter uses iterators in the old pre-concept style, it
- should be changed to use concepts instead.
- </TD>
- <TD>
- Use
- concepts for iterator template arguments throughout.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 314
- </TD>
- <TD>
- 28.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- swap overloads for regex classes are only supplied for l-value
- references. Other sections of the library (eg 21 strings or 23
- containers) provide two extra overloads taking an r-value
- reference as the first and second argument respectively.
- 
- 
- </TD>
- <TD>
- Add
- the missing overloads to 28.4 and the corresponding later sections
- in 28 for each swap function. We want to accept AMs paper which
- proposes a single overload with two r-value references
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 315
- </TD>
- <TD>
- 28.4
- </TD>
- <TD>
- p6
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- 6
- Effects: string_type str(first, last); return
- use_facet<collate<charT> >(
- getloc()).transform(&*str.begin(), &*str.end()); Is it
- legal to dereference str.end() ?
- 
- 
- </TD>
- <TD>
- Reword
- to effect clause to use legal iterator dereferences 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 316
- </TD>
- <TD>
- 28.4
- ff
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- constructors for regex classes do not have an r-value overload.
- 
- 
- </TD>
- <TD>
- Add
- the missing r-value constructors to regex classes.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 317
- </TD>
- <TD>
- 28.8
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- basic_string
- has both a constructor and an assignment operator that accepts an
- initializer list, basic_regex should have the same.
- </TD>
- <TD>
- In
- the basic_regex synopsis, after: basic_regex& operator=(const
- charT* ptr); add: basic_regex&
- operator=(initializer_list<charT> il); And after paragraph
- 20 add: basic_regex& operator=(initializer_list<charT>
- il); Effects: returns assign(il.begin(), il.end()); 
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 74
- </TD>
- <TD>
- 28.8
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- “basic_regx &
- operator= (initializer_list<T>);” is not defined.
- 
- 
- 
- </TD>
- <TD>
- 
- Add basic_regx & operator=
- (initializer_list<T>);
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 318
- </TD>
- <TD>
- 28.8.2
- </TD>
- <TD>
- para
- 22
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Constructor
- definition should appear with the other constructors not after
- assignment ops.
- 
- 
- </TD>
- <TD>
- Move
- para 22 to just after para 17.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 319
- </TD>
- <TD>
- 28.12.2
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- It
- was always expected that regex_token_iterator would be
- constructible from an array literal: indeed ideally this is the
- prefered method of initializing such an object. However, the best
- we could do in C++0x was: template <std::size_t N>
- regex_token_iterator(BidirectionalIterator a,
- BidirectionalIterator b, const regex_type& re, const int
- (&submatches)[N], regex_constants::match_flag_type m =
- regex_constants::match_default); Now that we have
- initializer_lists we should use them to remove this particular
- wart.
- </TD>
- <TD>
- To
- the synopsis for regex_token_iterator, after template <std::size_t
- N> regex_token_iterator(BidirectionalIterator a,
- BidirectionalIterator b, const regex_type& re, const int
- (&submatches)[N], regex_constants::match_flag_type m =
- regex_constants::match_default); add
- regex_token_iterator(BidirectionalIterator a,
- BidirectionalIterator b, const regex_type& re,
- initializer_list<int> submatches,
- regex_constants::match_flag_type m =
- regex_constants::match_default); In 28.12.2.1 add the declaration:
- regex_token_iterator(BidirectionalIterator a,
- BidirectionalIterator b, const regex_type& re,
- initializer_list<int> submatches,
- regex_constants::match_flag_type m =
- regex_constants::match_default); And to the end of para 3 add: The
- forth constructor initializes the member subs to hold a copy of
- the sequence of integer values in the range [submatches.begin(),
- submatches.end()).
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 87
- </TD>
- <TD>
- 29
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ge
- </TD>
- <TD>
- 
- The atomics chapter is not
- concept enabled. The adopted paper, N2427, did have those
- concepts.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 311
- </TD>
- <TD>
- 29
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Atomic
- types cannot be used generically in a constrained template
- 
- 
- </TD>
- <TD>
- Provide
- constraints for the atomics library, clause 29 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 312
- </TD>
- <TD>
- 29
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- contents of the <stdatomic.h> header are not listed
- anywhere, and <cstdatomic> is listed as a C99 header in
- chapter 17. If we intend to use these for compatibility with a
- future C standard, we should not use them now.
- </TD>
- <TD>
- Remove
- <cstdatomic> from the C99 headers in table 14. Add a new
- header <atomic> to the headers in table 13. Update chapter
- 29 to remove reference to <stdatomic.h> and replace the use
- of <cstdatomic> with <atomic>. If and when WG14 adds
- atomic operations to C we can add corresponding headers to table
- 14 with a TR.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 75
- </TD>
- <TD>
- 29
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- A definition of enum or struct
- is the style of C using typedef.
- </TD>
- <TD>
- 
- Change to a style of C++.
- 
- Correct as follows.
- 
- 
- 
- 
- 29.1
- 
-  
- 
- namespace std {
- 
- typedef
- enum memory_order {
- 
- memory_order_relaxed,
- memory_order_consume, memory_order_acquire,
- 
- memory_order_release,
- memory_order_acq_rel, memory_order_seq_cst
- 
- } memory_order;
- 
- }
- 
- 
- 
- 
- should be
- 
- 
- 
- 
- namespace std {
- 
- enum memory_order {
- 
- memory_order_relaxed,
- memory_order_consume, memory_order_acquire,
- 
- memory_order_release,
- memory_order_acq_rel, memory_order_seq_cst
- 
- };
- 
- }
- 
- 
- 
- 
- 29.3.1
- 
- 
- 
- 
- namespace std {
- 
- typedef
- struct atomic_bool {
- 
- ...
- 
- } atomic_bool;
- 
- }
- 
- 
- 
- 
- should be
- 
- 
- 
- 
- namespace std {
- 
- struct atomic_bool {
- 
- ...
- 
- };
- 
- }
- 
- 
- 
- 
- namespace std {
- 
- typedef
- struct atomic_itype
- {
- 
- ...
- 
- }
- atomic_itype;
- 
- }
- 
- 
- 
- 
- should be
- 
- 
- 
- 
- namespace std {
- 
- struct
- atomic_itype
- {
- 
- ...
- 
- };
- 
- }
- 
- 
- 
- 
- 29.3.2
- 
- 
- 
- 
- namespace std {
- 
- typedef
- struct atomic_address {
- 
- ...
- 
- } atomic_address;
- 
- }
- 
- 
- 
- 
- should be
- 
- 
- 
- 
- namespace std {
- 
- struct atomic_address {
- 
- ...
- 
- };
- 
- }
- 
- 
- 
- 
- 29.5
- 
- 
- 
- 
- namespace std {
- 
- typedef
- struct atomic_flag {
- 
- ...
- 
- } atomic_flag;
- 
- }
- 
- 
- 
- 
- should be
- 
- 
- 
- 
- namespace std {
- 
- struct atomic_flag {
- 
- ...
- 
- };
- }
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 313
- </TD>
- <TD>
- 29.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- seq_cst
- fences don't necessarily guarantee ordering
- http://home.twcny.rr.com/hinnant/cpp_extensions/issues_preview/lwg-active.html#926>
- </TD>
- <TD>
- Add
- a new paragraph after 29.1 [atomics.order]p5 that says For atomic
- operations A and B on an atomic object M, where A and B modify M,
- if there are memory_order_seq_cst fences X and Y such that A is
- sequenced before X, Y is sequenced before B, and X precedes Y in
- S, then B occurs later than A in the modifiction order of M. 
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 88
- </TD>
- <TD>
- 29.2
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- The
- "lockfree" facilities do not tell the programmer enough.
- </TD>
- <TD>
- 
- Expand the "lockfree"
- facilities. See the attached paper "Issues with the C++
- Standard" under Chapter 29, "atomics.lockfree doesn't
- tell the programmer enough"
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 89
- </TD>
- <TD>
- 29.3.1
- </TD>
- <TD>
- Table
- 122
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- The types in the table
- "Atomics for standard typedef types" should be typedefs,
- not classes. These semantics are necessary for compatibility with
- C.
- 
- 
- </TD>
- <TD>
- Change
- the classes to typedefs.
- </TD>
- <TD>
- Google
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 90
- </TD>
- <TD>
- 29.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- Are
- atomic functions allowed to have non-volatile overloads?
- </TD>
- <TD>
- 
- Allow non-volatile overloads.
- See the attached paper "Issues with the C++ Standard, under
- Chapter 29, "Are atomic functions allowed to have
- non-volatile overloads?"
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 91
- </TD>
- <TD>
- 29.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- Whether
- or not a failed compare_exchange is a RMW operation (as used in
- 1.10 [intro.multithread]) is unclear.
- </TD>
- <TD>
- 
- Make
- failing compare_exchange operations not
- be RMW. See the attached paper under "atomic RMW status of
- failed compare_exchange"
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 92
- </TD>
- <TD>
- 29.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- The
- effect of memory_order_consume with atomic RMW operations is
- unclear.
- </TD>
- <TD>
- 
- Follow the lead of fences
- [atomics.fences], and promote memory_order_consume to
- memory_order_acquire with RMW operations.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 76
- </TD>
- <TD>
- 30
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- A
- description for "Throws:
- Nothing." are
- not unified.
- 
- At
- the part without throw, "Throws:
- Nothing."
- should be described.
- </TD>
- <TD>
- 
- Add
- "Throws:
- Nothing." to the following.
- 
- 30.2.1.6
- , 1st
- paragraph
- 
- 30.3.3.1
- , 4th
- paragraph
- 
- 30.3.3.2.1
- , 6th
- paragraph
- 
- 30.4.1
- , 7th
- and 8th
- paragraph
- 
- 30.4.2
- , 6th,
- 7th,19th,21th
- and 25th
- paragraph
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 93
- </TD>
- <TD>
- 30
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ge
- </TD>
- <TD>
- 
- The thread chapter is not
- concept enabled.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- UK 320
- 
- 
- </TD>
- <TD>
- 30
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Threads
- library cannot be used in constrained templates
- </TD>
- <TD>
- Provide
- constraints for the threads library, clause 30 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 321
- </TD>
- <TD>
- 30
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- Throughout
- this clause, the term Requires: is used to introduce compile time
- requirements, which we expect to be replaced with concepts and
- requires in code. Run-time preconditions are introduced with the
- term "Preconditions:" which is not a defined part of the
- library documentation structure (17.5.2.4). However, this is
- exactly the direction that BSI would like to see the organisation
- move, replacing Requires: clauses with Preconditions: clasues
- throught the library. See comment against clause 17 for more
- details.
- 
- 
- </TD>
- <TD>
- Decument
- Preconditions: paragraphs in 17.5.2.4, and use consistently
- through rest of the library.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 94
- </TD>
- <TD>
- 30.1.2
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- te
- </TD>
- <TD>
- The first
- sentence of para 1 suggests that no other library function is
- permitted to call operating system or low level APIs.
- </TD>
- <TD>
- Rewrite
- para 1 as: “ Some functions described
- in this Clause are specified to throw exceptions of type
- system_error (19.4.5
- ). Such exceptions shall be thrown if a call to an operating
- system or underlying API results in an error that prevents the
- library function from satisfying its postconditions or from
- returning a meaningful value.”
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 95
- </TD>
- <TD>
- 30.1.3
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- te
- </TD>
- <TD>
- “native_handle_type”
- is a typedef, not a class member.
- </TD>
- <TD>
- 
- Several
- classes described in this Clause have a member native_handle
- (of type native_handle_type)
- . The
- 
- presence
- of this member and its semantics is implementation defined. [ Note:
- This member allows implementations to provide access to
- implementation details. The name of the member and the type are
- specified to facilitate portable compile-time detection. Actual
- use of this member or the corresponding type is inherently
- non-portable. —end
- note ]
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 96
- </TD>
- <TD>
- 30.1.4
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- te
- </TD>
- <TD>
- There is no
- definition here for monotonic clock.
- </TD>
- <TD>
- 
- Implementations
- should use a monotonic
- clock to measure
- time for these functions. A monotonic clock measures real time,
- but cannot be set, and is guaranteed to have no negative clock
- jumps.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 322
- </TD>
- <TD>
- 30.1.4
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Not
- all systms can provide a monotonic clock. How are they expected to
- treat a _for function?
- 
- 
- </TD>
- <TD>
- Add
- at least a note explaining the intent for systems that do not
- support a monotonic clock.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 323
- </TD>
- <TD>
- 30.2.1
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- presence of a non-explicit variadic template constructor alongside
- an explicit single-argument constructor can lead to behaviour that
- is not intended: the variadic constructor will be selected for
- implicit conversions, defeating the purpose of the explicit
- single-argument constructor. Additionally the single-argument
- constructor is redundant; the variadic constructor can provide
- identical functionality with one *fewer* copies if the supplied
- func is an lvalue.
- 
- 
- </TD>
- <TD>
- Mark
- constructor template <class F, class ...Args> thread(F&&
- f, Args&&... args); as explicit and remove the
- single-argument constructor.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 324
- </TD>
- <TD>
- 30.2.1.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- thread::id
- objects should be as useable in hashing containers as they are in
- ordered associative containers.
- 
- 
- </TD>
- <TD>
- Add
- thread::id support for std::hash
- 
- 
- 
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 77
- </TD>
- <TD>
- 30.2.1.2
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- "CopyConstructible"
- and "MoveConstructible" in "Requires:
- F and each Ti in
- Args shall be CopyConstructible if an lvalue and otherwise
- MoveConstructible." are reflected by interface.
- 
- 
- 
- </TD>
- <TD>
- 
- Add a concept for constructor
- of thread.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 78
- </TD>
- <TD>
- 30.2.1.2
- </TD>
- <TD>
- 
- 4th
- paragraph, 1st
- line
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- In "F and each Ti in
- Args", 'Ti' is not clear.
- </TD>
- <TD>
- 
- Replace "Ti" with
- "args"
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 97
- </TD>
- <TD>
- 30.2.1.3
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- te
- </TD>
- <TD>
- detach-on-destruction
- may result in “escaped” threads accessing objects with
- bounded lifetime after the end of their lifetime.
- </TD>
- <TD>
- See
- document WG21 N2802=08-0312 written by Hans Boehm.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- US
- 98
- </TD>
- <TD>
- 30.2.1.3,
- 30.2.1.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- The
- current defined behavior for the std::thread destructor is to
- detach the thread. Unfortunately, this behavior exposes
- programmers to tricky, hard-to-diagnose, undefined behavior.
- </TD>
- <TD>
- 
- Change destruction behavior to
- undefined behavior, with a note strongly encouraging termination.
- See the attached paper "Issues with the C++ Standard"
- under Chapter 30, "Implicit thread detach is harmful".
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 325
- </TD>
- <TD>
- 30.3.3
- </TD>
- <TD>
- 2
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- We
- believe constexpr literal values should be a more natural
- expression of empty tag types than extern objects as it should
- improve the compilers ability to optimize the empty object away
- completely.
- </TD>
- <TD>
- Replace
- the extern declarations: extern const defer_lock_t defer_lock;
- extern const try_to_lock_t try_to_lock; extern const adopt_lock_t
- adopt_lock; with constexpr values constexpr defer_lock_t
- defer_lock{}; constexpr try_to_lock_t try_to_lock{}; constexpr
- adopt_lock_t adopt_lock{}; 
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 326
- </TD>
- <TD>
- 30.3.3.2.1
- </TD>
- <TD>
- 7
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- precondition that the mutex is not owned by this thread offers
- introduces the risk of un-necessary undefined behaviour into the
- program. The only time it matters whether the current thread owns
- the mutex is in the lock operation, and that will happen
- subsequent to construction in this case. The lock operation has
- the identical pre-condition, so there is nothing gained by
- asserting that precondition earlier and denying the program the
- right to get into a valid state before calling lock.
- 
- 
- </TD>
- <TD>
- Strike
- 30.3.3.2.1p7
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 327
- </TD>
- <TD>
- 30.3.3.2.2
- </TD>
- <TD>
- 4,
- 9, 14, 19
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Not
- clear what the specification for error condition
- resource_deadlock_would_occur means. It is perfectly possible for
- this thread to own the mutex without setting owns to true on this
- specific lock object. It is also possible for lock operations to
- succeed even if the thread does own the mutex, if the mutex is
- recursive. Likewise, if the mutex is not recursive and the mutex
- has been locked externally, it is not always possible to know that
- this error condition should be raised, depending on the host
- operating system facilities. It is possible that 'i.e.' was
- supposed to be 'e.g.' and that suggests that recursive locks are
- not allowed. That makes sense, as the exposition-only member owns
- is boolean and not a integer to count recursive locks.
- 
- 
- </TD>
- <TD>
- Add
- a precondition !owns. Change the 'i.e.' in the error condition to
- be 'e.g.' to allow for this condition to propogate deadlock
- detection by the host OS.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 328
- </TD>
- <TD>
- 30.3.3.2.2
- </TD>
- <TD>
- 20
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- There
- is a missing precondition that owns is true, or an if(owns) test
- is missing from the effect clause
- </TD>
- <TD>
- Add
- a precondition that owns == true. Add an error condition to detect
- a violation, rather than yield undefined behaviour.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 329
- </TD>
- <TD>
- 30.5
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- future,
- promise and packaged_task provide a framework for creating future
- values, but a simple function to tie all three components together
- is missing. Note that we only need a *simple* facility for C++0x.
- Advanced thread pools are to be left for TR2.
- </TD>
- <TD>
- Provide
- a simple function along the lines of: template< typename F,
- typename ... Args > requires Callable< F, Args... >
- future< Callable::result_type > async( F&& f, Args
- && ... ); Semantics are similar to creating a thread
- object with a packaged_task invoking f with forward<Args>(args...)
- but details are left unspecified to allow different scheduling and
- thread spawning implementations. It is unspecified whether a task
- submitted to async is run on its own thread or a thread previously
- used for another async task. If a call to async succeeds, it shall
- be safe to wait for it from any thread. The state of thread_local
- variables shall be preserved during async calls. No two incomplete
- async tasks shall see the same value of this_thread::get_id().
- [Note: this effectively forces new tasks to be run on a new
- thread, or a fixed-size pool with no queue. If the library is
- unable to spawn a new thread or there are no free worker threads
- then the async call should fail.]
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 330
- </TD>
- <TD>
- 30.5.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- 30.5.1
- (and then 30.5.7) refer to a specialisation of
- constructible_with_allocator_prefix<> However this trait is
- not in the CD, so references to it should be removed.
- </TD>
- <TD>
- Remove
- the reference to constructible_with_allocator_prefix in 30.5.1
- Remove paragraph 30.5.7
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 79
- </TD>
- <TD>
- 30.5.1
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- te
- </TD>
- <TD>
- 
- The concept of UsesAllocator
- and Allocator should be used.
- </TD>
- <TD>
- 
- Correct as follows.
- 
-  
- 
- template <class R, class
- Alloc>
- 
- struct
- uses_allocator<promise<R>, Alloc>;
- 
- template <class R>
- 
- struct
- constructible_with_allocator_prefix<promise<R> >;
- 
-  
- 
- should be
- 
-  
- 
- template<class R, Allocator
- Alloc>
- 
- concept_map
- UsesAllocator<promise<R>, Alloc>;
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 331
- </TD>
- <TD>
- 30.5.3
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Not
- clear what it means for a public constructor to be 'exposition
- only'. If the intent is purely to support the library calling this
- constructor then it can be made private and accessed through
- friendship. Otherwise it should be documented for public
- consumption.
- 
- 
- </TD>
- <TD>
- Declare
- the constructor as private with a note about intended friendship,
- or remove the exposition-only comment and document the semantics.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 332
- </TD>
- <TD>
- 30.5.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ed
- </TD>
- <TD>
- It
- is not clear without reference to the original proposal how to use
- a future. In particular, the only way for the user to construct a
- future is via the promise API which is documented after the
- presentation of future. Most library clauses feature a small
- description of their components and intended use, it would be most
- useful in this case.
- 
- 
- </TD>
- <TD>
- Provide
- a small introductory paragraph, docuenting intended purpose of the
- future class template and the way futures can only be created via
- the promise API.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 333
- </TD>
- <TD>
- 30.5.4
- </TD>
- <TD>
- 5
- </TD>
- <TD>
- Ge
- </TD>
- <TD>
- We
- expect the complicated 3-signature specifcation for future::get()
- to be simplified to a single signature with a requires clause by
- the application of concepts.
- </TD>
- <TD>
- Requires
- fully baked concepts for clause 30
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 334
- </TD>
- <TD>
- 30.5.4
- </TD>
- <TD>
- 5
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Behaviour
- of get() is undefined if calling get() while not is_ready(). The
- intent is that get() is a blocking call, and will wait for the
- future to become ready.
- 
- 
- </TD>
- <TD>
- Effects:
- If is_ready() would return false, block on the asynchronous result
- associated with *this. 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 335
- </TD>
- <TD>
- 30.5.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- std::unique_future
- is MoveConstructible, so you can transfer the association with an
- asynchronous result from one instance to another. However, there
- is no way to determine whether or not an instance has been moved
- from, and therefore whether or not it is safe to wait for it.
- std::promise<int> p; std::unique_future<int>
- uf(p.get_future()); std::unique_future<int>
- uf2(std::move(uf)); uf.wait(); // oops, uf has no result to wait
- for.
- 
- 
- </TD>
- <TD>
- Add
- a "waitable()" function to unique_future (and
- shared_future) akin to std::thread::joinable(), which returns true
- if there is an associated result to wait for (whether or not it is
- ready). Then we can say: if(uf.waitable()) uf.wait(); 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 336
- </TD>
- <TD>
- 30.5.4
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- It
- is possible to transfer ownership of the asynchronous result from
- one unique_future instance to another via the move-constructor.
- However, it is not possible to transfer it back, and nor is it
- possible to create a default-constructed unique_future instance to
- use as a later move target. This unduly limits the use of
- unique_future in code. Also, the lack of a move-assignment
- operator restricts the use of unique_future in containers such as
- std::vector - vector::insert requires move-assignable for example.
- 
- 
- </TD>
- <TD>
- Add
- a default constructor with the semantics that it creates a
- unique_future with no associated asynchronous result. Add a
- move-assignment operator which transfers ownership.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 80
- </TD>
- <TD>
- 30.5.4
- , 30.5.5
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- Typo, duplicated ">"
- 
- "class Period>>"
- 
- 
- 
- </TD>
- <TD>
- 
- Remove one
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 337
- </TD>
- <TD>
- 30.5.5
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- shared_future
- should support an efficient move constructor that can avoid
- unnecessary manipulation of a reference count, much like
- shared_ptr
- 
- 
- </TD>
- <TD>
- Add
- a move constructor
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 338
- </TD>
- <TD>
- 30.5.5
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- shared_future
- is currently CopyConstructible, but not CopyAssignable. This is
- inconsistent with shared_ptr, and will surprise users. Users will
- then write work-arounds to provide this behaviour. We should
- provide it simply and efficiently as part of shared_future. Note
- that since the shared_future member functions for accessing the
- state are all declared const, the original usage of an immutable
- shared_future value that can be freely copied by multiple threads
- can be retained by declaring such an instance as "const
- shared_future".
- </TD>
- <TD>
- Remove
- "=delete" from the copy-assignment operator of
- shared_future. Add a move-constructor
- shared_future(shared_future&& rhs), and a move-assignment
- operator shared_future& operator=(shared_future&&
- rhs). The postcondition for the copy-assignment operator is that
- *this has the same associated state as rhs. The postcondition for
- the move-constructor and move assignment is that *this has the
- same associated as rhs had before the constructor/assignment call
- and that rhs has no associated state.
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 339
- </TD>
- <TD>
- 30.5.6
- </TD>
- <TD>
- 6,
- 7
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- Move
- assignment is goiing in the wrong direction, assigning from *this
- to the passed rvalue, and then returning a reference to an
- unusable *this
- </TD>
- <TD>
- Strike
- 6. 7 Postcondition: associated state of *this is the same as the
- associated state of rhs before the call. rhs has no associated
- state. 
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 340
- </TD>
- <TD>
- 30.5.6
- </TD>
- <TD>
- 11,
- 12, 13
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- There
- is an implied postcondition that the state of the promise is
- transferred into the future leaving the promise with no associated
- state. It should be spelled out.
- 
- 
- </TD>
- <TD>
- Postcondition:
- *this has no associated state.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 341
- </TD>
- <TD>
- 30.5.6
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- promise::swap
- accepts its parameter by lvalue reference. This is inconsistent
- with other types that provide a swap member function, where those
- swap functions accept an rvalue reference
- </TD>
- <TD>
- Change
- promise::swap to take an rvalue reference.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 342
- </TD>
- <TD>
- 30.5.6
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- std::promise
- is missing a non-member overload of swap. This is inconsistent
- with other types that provide a swap member function
- 
- 
- </TD>
- <TD>
- Add
- a non-member overload void swap(promise&& x,promise&&
- y){ x.swap(y); }
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 343
- </TD>
- <TD>
- 30.5.6
- </TD>
- <TD>
- 3
- </TD>
- <TD>
- Te
- </TD>
- <TD>
- The
- move constructor of a std::promise object does not need to
- allocate any memory, so the move-construct-with-allocator overload
- of the constructor is superfluous.
- </TD>
- <TD>
- Remove
- the constructor with the signature template <class Allocator>
- promise(allocator_arg_t, const Allocator& a, promise&
- rhs);
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- JP
- 81
- </TD>
- <TD>
- 30.5.8
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- There are not requirements for
- F and a concept of Allocator dose not use.
- </TD>
- <TD>
- 
- Correct as follows.
- 
- 
- 
- 
- template <class F>
- 
- explicit packaged_task(F f);
- 
- template <class F, class
- Allocator>
- 
- explicit
- packaged_task(allocator_arg_t, const Allocator& a, F f);
- 
- template <class F>
- 
- explicit packaged_task(F&&
- f);
- 
- template <class F, class
- Allocator>
- 
- explicit
- packaged_task(allocator_arg_t, const Allocator& a, F&&
- f);
- 
-  
- 
- should be
- 
-  
- 
- template <class F>
- 
- requires
- CopyConstructible<F> && Callable<F, ArgTypes...>
- 
- &&
- Convertible<Callable<F, ArgTypes...>::result_type, R>
- 
- explicit packaged_task(F f);
- 
-  
- 
- template
- <class F, Allocator
- Alloc>
- 
- requires
- CopyConstructible<F> && Callable<F, ArgTypes...>
- 
- &&
- Convertible<Callable<F, ArgTypes...>::result_type, R>
- 
- explicit
- packaged_task(allocator_arg_t, const Alloc&
- a, F f);
- 
-  
- 
- template <class F>
- 
- requires
- CopyConstructible<F> && Callable<F, ArgTypes...>
- 
- &&
- Convertible<Callable<F, ArgTypes...>::result_type, R>
- 
- explicit packaged_task(F&&
- f);
- 
-  
- 
- template
- <class F, Allocator
- Alloc>
- 
- requires
- CopyConstructible<F> && Callable<F, ArgTypes...>
- 
- &&
- Convertible<Callable<F, ArgTypes...>::result_type, R>
- 
- explicit
- packaged_task(allocator_arg_t, const Alloc&
- a, F&& f);
- 
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- DE-23
- </TD>
- <TD>
- Annex
- B
- </TD>
- <TD>
- p2
- </TD>
- <TD>
- te
- </TD>
- <TD>
- DE-23
- Recursive use of constexpr functions appears to be permitted.
- Since such functions may be required to be evaluated at
- compile-time, Annex B "implementation quantities" should
- specify a maximum depth of recursion.
- 
- 
- </TD>
- <TD>
- In
- Annex B, specify a recursion depth of 256 or a larger value.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- DE-24
- </TD>
- <TD>
- Annex
- B
- </TD>
- <TD>
- p2
- </TD>
- <TD>
- te
- </TD>
- <TD>
- DE-24
- The number of placeholders for "bind" is
- implementation-defined in 20.7.12.1.4, but no minimum is suggested
- in Annex B.
- 
- 
- </TD>
- <TD>
- Add
- a miminum of 10 placeholders to Annex B.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- DE-25
- </TD>
- <TD>
- Annex
- B
- </TD>
- <TD>
- p2
- </TD>
- <TD>
- te
- </TD>
- <TD>
- DE-25
- Specifying a minimum of 17 recursively nested template
- instantiations is too small for practical purposes. The limit is
- too high to effectively limit compiler resource usage, see
- http://ubiety.uwaterloo.ca/~tveldhui/papers/2003/turing.pdf . The
- conclusion is that the metric "number of recursively nested
- template instantiations" is inapposite.
- 
- 
- </TD>
- <TD>
- Remove
- the bullet "Recursively nested template instantiations [17]".
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 38
- </TD>
- <TD>
- C.2
- [diffs.library]
- </TD>
- <TD>
- 1
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- What
- is ISO/IEC 1990:9899/DAM 1? My guess is that's a typo for ISO/IEC
- 
- 9899/Amd.1:1995
- which I'd have expected to be referenced here (the tables
- 
- make
- reference to things which were introduced by Amd.1).
- 
- 
- </TD>
- <TD>
- 
- One
- need probably a reference to the document which introduce char16_t
- and
- char32_t
- in C (ISO/IEC TR 19769:2004?).
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- UK 
- 344
- </TD>
- <TD>
- Appendix
- D
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- Ge
- </TD>
- <TD>
- It
- is desirable to allow some mechanism to support phasing out of
- deprecated features in the future. Allowing compilers to implement
- a mode where deprecated features are not available is a good first
- step.
- </TD>
- <TD>
- Add
- to the definition of deprecated features permission for compilers
- to maintain a conditionally supported mode where deprecated
- features can be disabled, so long as they also default to a mode
- where all deprecated features are supported.
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- FR
- 39
- </TD>
- <TD>
- Index
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- ed
- </TD>
- <TD>
- 
- Some
- definitions seem not indexed (such as /trivially copyable/ or
- 
- /sequenced
- before/), indexing them would be useful (and marking specially the
- page -- say bold or italic -- which reference to the definition
- would increase the usefulness; having a separate index of all
- definitions is something which could also be considered).
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- <TD>
- 
- 
- </TD>
- </TR>
-</TABLE>
-</BODY>
-</HTML>
\ No newline at end of file
+<meta name="generator" content=
+"Microsoft FrontPage 5.0">
+<meta http-equiv="CONTENT-TYPE" content=
+"text/html; charset=us-ascii">
+<title>C++0x CD1 NB Comments</title>
+<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
+<meta name="AUTHOR" content="dow">
+<meta name="CREATED" content="20090221;19590000">
+<meta name="CHANGEDBY" content=" Barry E Hedquist">
+<meta name="CHANGED" content="20090222;18460000">
+<meta name="DESCRIPTION" content="FORM (ISO)">
+<style type="text/css">
+ 
+</style>
+<body lang="en-US" text="#000000" dir="ltr">
+<div type="HEADER">
+<table border="1" bordercolor="#000000" cellpadding="7"
+cellspacing="0" style="border-collapse: collapse">
+<tr valign="top">
+<td>
+1
+<td>
+2
+<td>
+3
+<td>
+4
+<td>
+5
+<td>
+6
+<td>
+7
+<tr valign="top">
+<td>
+MB1 
+<td>
+Clause No./ 
+Subclause No./ 
+Annex (e.g. 3.1)
+<td>
+Paragraph/ 
+Figure/Table/Note (e.g. Table 1)
+<td>
+Type of com-ment2
+<td>
+Comment (justification
+for change) by the MB
+<td>
+Proposed change by the
+MB
+<td>
+
+Disposition
+ 
+<tr valign="top">
+<td>
+FR 1
+<td>
+General Comment
+<td>
+ 
+<td>
+ge
+<td>
+Interactions between several new features
+appear obscure, and very few examples are offered to guide
+understanding of the formal text on interaction between these new
+additions.
+We worry about the complexity of the
+programming model so created.
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 1
+<td>
+1-16
+<td>
+ 
+<td>
+ge/te
+<td>
+The active issues identified in WG21
+N2803, C++ Standard Core Language Active Issues, must be addressed
+and appropriate action taken.
+ 
+
+<a href=
+"http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html">http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html></a>
+ 
+<td>
+Appropriate action would include making
+changes to the CD, identifying an issue as not requiring a change
+to the CD, or deferring the issue to a later point in time.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+CA-1
+<td>
+ 
+<td>
+ 
+<td>
+Ge
+<td>
+There are quite a number
+of defects for the current CD recorded in SC22/WG21-N2803 and
+N2806
+<td>
+Consider these comments
+and update ISO/IEC CD 14882 accordingly
+<td>
+ 
+<tr valign="top">
+<td>
+DE-1
+<td>
+1 through 16
+<td>
+ 
+<td>
+ge/te
+<td>
+DE-1 Consider addressing a
+significant part of the unresolved core language issues presented
+in WG21 document N2791 "C++ Standard Core Language Active Issues,
+Revision 59", available at
+http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2791.html
+.
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+CH 2
+<td>
+all
+<td>
+ 
+<td>
+te
+<td>
+The issues on the issues
+lists shall be addressed before the standard becomes final.
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 3
+<td>
+all
+<td>
+ 
+<td>
+ed
+<td>
+Latin abbreviations are
+presented incorrectly.
+<td>
+
+Italicize all Latin
+abbreviations, append commas after each occurrence of i.e.
+and e.g., and remove extraneous space after each such
+abbreviation.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+FR 3
+<td>
+1 [intro.scope]
+<td>
+2
+<td>
+ed
+<td>
+C++ is split at the end of line.
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 4
+<td>
+1.1
+<td>
+2
+<td>
+ed
+<td>
+There is a bad line break in "C++".
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 1
+<td>
+1.1
+<td>
+2
+<td>
+Ed
+<td>
+List of
+additional facilities over C has been extended with this standard,
+so should be mentioned in the introductory material.
+<td>
+Add the
+following to the list in 1.1p2: atomic operations concurrency
+alignment control user-defined literals attributes
+<td>
+ 
+<tr valign="top">
+<td>
+FR 4
+<td>
+1.2 [intro.refs]
+<td>
+1
+<td>
+ed
+<td>
+Is the lack of reference to ISO/CEI
+9899/AC3:2007 voluntary?
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 2
+<td>
+1.2
+<td>
+1
+<td>
+Ed
+<td>
+We recommend taking
+the latest update to each listed standard, yet the C standard is
+quite deliberately held back to the 1990 version without
+comment.+
+ 
+<td>
+... not sure
+...
+<td>
+ 
+<tr valign="top">
+<td>
+UK 3
+<td>
+1.3.1
+<td>
+ 
+<td>
+Ed
+<td>
+The
+definition of an argument does not seem to cover many assumed use
+cases, and we believe that is not intentional.
+<td>
+Revise the definition of argument to answer
+question such as: Are lambda-captures arguments? Are type names in
+a throw-spec arguments? 'Argument' to casts, typeid, alignof,
+alignas, decltype and sizeof? why in x[arg] : arg is not an
+agrument, but the value forwarded to operator[]() is ? Does not
+apply to operators as call-points not bounded by parenthises ?
+Similar for copy initialization and conversion? what are Deduced
+template 'arguments'? what are 'default arguments'? can attributes
+have arguments? what about concepts, requires clauses and
+concept_map instantiations? What about user-defined literals where
+parens are not used?
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 4
+<td>
+1.3.3
+<td>
+ 
+<td>
+Te
+<td>
+This
+definition is essentially worthless, as it says nothing about what
+distinguished a diagnostic message from other output messages
+provided by the implementation
+<td>
+... add something about the diagnostic message
+being a message issues by the implementation when translating a
+program that violates the rules of the standard. ...
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+FR 5
+<td>
+1.3.4
+[defns.dynamic.type]
+<td>
+ 
+<td>
+te
+<td>
+"The dynamic type of an rvalue expression is
+its static type." Is this true with rvalue references?
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 5
+<td>
+1.3.5
+<td>
+ 
+<td>
+te
+<td>
+The wording is unclear as
+to whether it is the input or the implementation "that is not a
+well-formed program".
+<td>
+Reword to clarify that it
+is the input that is here considered not well-formed.
+<td>
+ 
+<tr valign="top">
+<td>
+FR 6
+<td>
+1.3.6
+[defns.impl.defined]
+<td>
+ 
+<td>
+ed
+<td>
+There is a page break between the title and the
+paragraph.
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+FR 7
+<td>
+1.3.13
+[defns.undefined]
+<td>
+ 
+<td>
+ed
+<td>
+[intro.execution]/5 explicitly allows non
+causal undefined behaviour,
+<td>
+Adding it to the note outlying possible
+undefined behaviours.
+<td>
+ 
+<tr valign="top">
+<td>
+US 6
+<td>
+1.3.14
+<td>
+ 
+<td>
+ge
+<td>
+Unspecified behavior does not clearly
+state whether or not undefined behavior is permitted. (The standard
+says that "usually, the range of possible behaviors is delineated",
+but what happens if the range is not delineated? Is a crash, or
+worse, allowed?)
+ 
+<td>
+Clearly state whether or not Unspecified behavior
+includes undefined behavior.
+<td>
+ 
+<tr valign="top">
+<td>
+FR 8
+<td>
+1.4
+[intro.compliance]
+<td>
+8
+<td>
+ed
+<td>
+The paragraph as its stands seems to require
+that violations of the ODR (which make a program ill-formed) are
+required to be diagnosed if the program also uses an extension
+which defines some cases of ODR.
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 5
+<td>
+1.5
+<td>
+ 
+<td>
+Ge
+<td>
+Missing
+checklist of implementation defined behaviour (see ISO/IEC TR
+10176, 4.1.1p6)
+<td>
+Provide a new
+annex with the missing checklist
+<td>
+ 
+<tr valign="top">
+<td>
+UK 6
+<td>
+1.5
+<td>
+ 
+<td>
+Ge
+<td>
+Missing annex
+describing potential incompatibility to previous edition of the
+standard (see ISO/IEC TR 10176, 4.1.1p9)
+<td>
+Provide a new
+annex with the missing documentation. See n2733(08-0243) for a
+starting point
+<td>
+ 
+<tr valign="top">
+<td>
+US 7
+<td>
+1.5
+<td>
+2
+<td>
+ed
+<td>
+There is no mention of
+Clause 17.
+<td>
+Include Clause 17 among
+the list of Clauses that specify the Standard Library.
+<td>
+ 
+<tr valign="top">
+<td>
+US 8
+<td>
+1.5
+<td>
+2
+<td>
+te
+<td>
+
+The paragraph omits to
+mention concepts and concept maps among its list of entities
+defined in the Standard Library.
+ 
+<td>
+Mention concepts and
+concept maps among the list of entities.
+<td>
+ 
+<tr valign="top">
+<td>
+US 9
+<td>
+1.6
+<td>
+1
+<td>
+ed
+<td>
+The syntax description does not account
+for lines that wrap.
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 10
+<td>
+1.7
+<td>
+3
+<td>
+ed
+<td>
+The term thread is used before defined.
+<td>
+Reference
+1.10 [intro.multithread].
+<td>
+ 
+<tr valign="top">
+<td>
+US 11
+<td>
+1.7
+<td>
+¶ 3 last sent.
+<td>
+ed
+<td>
+The phrase “threads
+of execution” should be accompanied by a reference to
+[intro.multithread].
+<td>
+Insert the recommended
+reference.
+<td>
+ 
+<tr valign="top">
+<td>
+US 12
+<td>
+1.7
+<td>
+¶ 3 first
+sent.
+<td>
+te
+<td>
+A memory location is not
+an object as the sentence claims.
+<td>
+Clarify that a memory
+location “holds” an object rather than that it
+“is” an object.
+<td>
+ 
+<tr valign="top">
+<td>
+US 13
+<td>
+1.7
+<td>
+¶ 3 last sent.
+<td>
+te
+<td>
+It is unclear what is
+meant by memory locations that are "separate": are they distinct?
+non-overlapping? how much "separation" is needed?
+<td>
+Provide either a better
+definition of “separate” or reword (this and subsequent
+paragraphs) to avoid this term.
+<td>
+ 
+<tr valign="top">
+<td>
+US 14
+<td>
+1.7
+<td>
+¶ 4
+<td>
+te
+<td>
+The phrase "no matter what
+the sizes of the intervening bit-fields happen to be" contradicts
+the claim of separation "by a zero-length bit-field
+declaration".
+<td>
+Delete the “no
+matter…” phrase, or resolve the contradiction in a
+different way.
+<td>
+ 
+<tr valign="top">
+<td>
+US 15
+<td>
+1.7
+<td>
+¶ 5
+<td>
+te
+<td>
+A struct does not
+“contain” memory locations.
+<td>
+Reword so that a struct is
+“held in” one or more memory locations.
+<td>
+ 
+<tr valign="top">
+<td>
+US 16
+<td>
+1.9
+<td>
+ 
+<td>
+ 
+<td>
+The discussion of
+observable behavior in 1.9 is not consistent with the addition of
+threads to the language. Volatile reads and writes and other
+observable actions no longer occur in a single
+"sequence”.
+<td>
+Remove/replace various
+occurrences of "sequence" in 1.9.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 8
+<td>
+1.9
+<td>
+5
+<td>
+Te
+<td>
+With parallel
+execution there is no longer the idea of a single execution
+sequence for a program. Instead, a program may be considered a set
+of exectution sequences.
+<td>
+Update first
+sentance as: A conforming implementation executing a well-formed
+program shall produce the same observable behavior as one of the
+possible SETS OF execution sequences of the corresponding instance
+of the abstract machine CONFORMING TO THE MEMORY MODEL (1.10) with
+the same program and the same input.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 7
+<td>
+1.9
+<td>
+6
+<td>
+Te
+<td>
+Does the term
+'sequence' imply all reads/writes through volatile memory much be
+serialized, and cannot occur in parallel on truly parallel
+hardware? Allow for multiple concurrent sequences where each
+sequence is constrained by this observable behaviour rule, and
+multiple sequences are constrained by the memory model and
+happens-before relationships defined in 1.10
+<td>
+Replace
+'sequence' with 'sequences'.
+<td>
+ 
+<tr valign="top">
+<td>
+FR 9
+<td>
+1.9
+[intro.execution]
+<td>
+16
+<td>
+ed
+<td>
+This example use int *v while the other
+examples seems to use notation like int* v.
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 17
+<td>
+1.10
+<td>
+1
+<td>
+Ge
+<td>
+This definition of “thread” is poor,
+and assumes the user already knows what multi-threaded means
+(probably true!). In particular, it does not deal adequately with
+the concept that all threads share the same address space.
+<td>
+
+Replace first sentence of
+para 1 as follows:
+Under a hosted implementation, a C++ program can
+have more than one thread of execution (a.k.a. thread) running
+concurrently. Each thread is a single flow of control within a
+program. Anything whose address may be determined by a thread,
+including but not limited to static objects, storage obtained via
+new or by any dynamic allocator, directly addressable storage
+obtained through implementation-defined functions, and automatic
+variables, are accessible to all threads in the same
+program.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 9
+<td>
+2.1
+<td>
+2,
+4
+<td>
+Te
+<td>
+Undefined
+behaviour is a drastic way to silently ignore minor issues. The
+cases in this paragraph could be easily defined. In this case opt
+for conditionally supported behaviour, which mandates a diagnostic
+if the compiler is not prepared to handle the syntax
+consistently.
+<td>
+Replace undefined behaviour with conditionally
+supported behavior. Conditional behaviour may be implementation
+defined, although suggest there is a reasonable default in each
+case. For creating a universal-character name, splice text to
+create a universal-character. In the case of a file ending without
+a newline, treat as if the newline was implictly added, with an
+empty line to follow if the last character was a back-slash.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 10
+<td>
+2.1
+<td>
+3
+<td>
+Te
+<td>
+Implementation defined seems unnecessarily
+burdensome for negligible gain. I am yet to see code that depended
+on whether non-empty sequences of whitespace were concatenated.
+Better left unspecified.
+ 
+<td>
+How the
+compiler treats non-empty sequences of whitespace should be left
+unspecified, rather than implementation-defined.
+<td>
+ 
+<tr valign="top">
+<td>
+FR 10
+<td>
+2.1 [lex.phases]/5 and 2.2
+[lex.charset]/3
+<td>
+ 
+<td>
+te
+<td>
+[defns.multibyte] "the extended character
+set."
+[lex.charset]/3 cited below implies that
+there is an extended character set per locale.
+[lex.phases]/5 "Each [...]
+universal-character-name [...] is converted to the corresponding
+member of the execution character set"
+[lex.charset]/3 "The values of the members
+of the execution character sets are implementation defined, and any
+additional members are locale-specific."
+ 
+Together they seem to imply that what is
+locale-specific is if a value is valid or not for the current
+locale, not the representation of a given universal
+character.
+ 
+This is not the behaviour of at least some
+compilers I've access to which are allowing different codes for the
+same abstract character in different locale. During phase 5, they
+are using an implementation defined char set.
+ 
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK
+11
+<td>
+2.3
+<td>
+ 
+<td>
+Te
+<td>
+Trigraphs are
+a complicated solution to an old problem, that cause more problems
+than they solve in the modern environment. Unexpected trigraphs in
+string literals and occasionally in comments can be very confusing
+for the non-expert.
+<td>
+Deprecate the
+whole of 2.3 and move it to appendix D.
+<td>
+ 
+<tr valign="top">
+<td>
+UK
+12
+<td>
+2.4,
+2.8
+<td>
+2
+<td>
+Te
+<td>
+This undefined behaviour in token concatenation is
+worrying and we believe hard to justify. An implementation should
+either support this in a defined way, or issue a diagnosic.
+Documenting existing practice should not break existing
+implementations, although unconditionally requiring a diagnostic
+would lead to more portable programs.
+ 
+<td>
+Replace
+undefined behaviour with conditionally supported behaviour with
+implementation defined semantics.
+<td>
+ 
+<tr valign="top">
+<td>
+US 18
+<td>
+2.4
+<td>
+¶ 2
+<td>
+ed
+<td>
+The paragraph begins with
+an empty line.
+<td>
+Delete the empty
+line.
+<td>
+ 
+<tr valign="top">
+<td>
+FR 11
+<td>
+2.4 [lex.pptokens]
+<td>
+3
+<td>
+ed
+<td>
+There are spurious empty lines.
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+FR 12
+<td>
+2.5 [lex.digraph] and 2.11
+[lex.key]/2
+<td>
+ 
+<td>
+te
+<td>
+The alternative representations are reserved as
+such even in attribute. Is that what is wanted?
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+FI 2
+<td>
+2.5
+<td>
+Table 2
+<td>
+te
+<td>
+Add eq, for spelling out
+== in order to distinguish it from the assignment operator.
+<td>
+See eq-keyword.doc,
+eq-keyword.ppt
+<td>
+ 
+<tr valign="top">
+<td>
+UK
+13
+<td>
+2.9
+<td>
+2
+<td>
+Ed
+<td>
+This text is
+confusing in isolation, as it implies pp-numbers do not have a
+value in translation phase 4 when evaluating #if preprocessor
+expressions.
+<td>
+Add a note
+with a cross-refernce to 16.1 that a pp-number may briefly acquire
+a value during translation phase 4 while evaluating #if
+expressions.
+<td>
+ 
+<tr valign="top">
+<td>
+UK
+14
+<td>
+2.11
+<td>
+table
+3
+<td>
+Ed
+<td>
+The table is nearly sorted, but not quite. It was
+sorted in previous versions of the standard.
+ 
+<td>
+Sort the
+table.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 1
+<td>
+2.11
+<td>
+Table 3
+<td>
+ed
+<td>
+Keywords in the table are
+listed disorderly. Also, a part of a frame of the table is not
+drawn.
+<td>
+Sort it in alphabetical order. Complete the table
+frame.
+<td>
+ 
+<tr valign="top">
+<td>
+US 19
+<td>
+2.13.1
+<td>
+Table 5, rows “l or
+L” and “ll or LL”
+<td>
+te
+<td>
+The final entry in the
+last column (“unsigned long int”) is incorrect.
+<td>
+Replace the incorrect
+entries by “unsigned long long int”.
+<td>
+ 
+<tr valign="top">
+<td>
+US 20
+<td>
+2.13.1, 2.13.3
+<td>
+ 
+<td>
+te
+<td>
+Long strings of digits in literals are a
+continuing problem in the production and maintenance of
+programs.
+<td>
+Adopt the 1983 technology of Ada and use
+underscores to separate digits. <a href=
+"http://www.google.com/url?sa=D&q=http%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2007%2Fn2281.html"
+target="_blank">http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2281.html></a>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK
+15
+<td>
+2.13.2
+<td>
+2
+<td>
+Te
+<td>
+Inconsistency
+between definition of a multicharacter literal and a wide character
+literal containing multiple c-chars.
+<td>
+Define the term multicharacter wide literal for a
+wchar_t literal containing multiple elements, and specify its type
+is integer (or wider)
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK
+16
+<td>
+2.13.2
+<td>
+3
+<td>
+Ed
+<td>
+Not
+immediately clear why the question mark needs escaping. A note
+would help.
+<td>
+Add a note explaining that the ? character may
+need escaping to avoid accidentally creating a trigraph.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 2
+<td>
+2.13.4
+<td>
+1st paragraph, 2nd line
+ 
+<td>
+ed
+<td>
+Typo, R"..." should be R"[...]"
+<td>
+Correct typo.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 3
+<td>
+2.13.4
+<td>
+2nd paragraph
+<td>
+te
+<td>
+We think that the
+explanation of d-char-sequence is not enough.
+<td>
+Add the following.
+<ol>
+<li>
+Add the following to the explanation of
+d-char-sequence, more easily to understand.</ol>
+...prefix is a raw string literal.
+The d-char-sequence is used as delimiter.
+The terminating d-char-sequence of ...
+<ol start="2">
+<li>
+Add the following note that there are square
+brackets in r-char-sequence.</ol>
+[Note:
+char foo[] = R”delimiter[[a-z]
+specifies a range which matches any lowercase letter from "a" to
+"z".]delimiter”;
+ 
+the expression statement behaves exactly the same
+as
+ 
+char foo[]="[a-z] specifies a range which matches
+any lowercase letter from \"a\" to \"z\".";
+- end note]
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 4
+<td>
+2.13.4
+<td>
+3rd paragraph, 1st line of example
+<td>
+ed
+<td>
+Typo. Lack of a necessary backslash in
+the first line of the example as follows:
+ 
+const char *p = R"[a
+b
+c]";
+ 
+should be
+ 
+const char *p = R"[a\
+b
+c]";
+<td>
+Correct typo.
+<td>
+ 
+<tr valign="top">
+<td>
+US 21
+<td>
+2.13.4
+<td>
+¶ 3
+<td>
+ed
+<td>
+The paragraph, marked as a
+Note, contains an embedded example not marked as such.
+<td>
+Denote the code (and
+perhaps also its commentary) as an Example.
+<td>
+ 
+<tr valign="top">
+<td>
+US 22
+<td>
+2.13.4
+<td>
+¶ 3
+<td>
+te
+<td>
+The code does not have the
+effect predicted by its accompanying narrative.
+<td>
+Append a backslash to the
+first line of the code.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 5
+<td>
+2.13.4
+<td>
+11th paragraph, Table 7
+ 
+<td>
+te
+<td>
+It is not explicit how to
+combine raw-string and non-raw-string.
+<td>
+Add rules containing
+raw-string in the table 7.
+<td>
+ 
+<tr valign="top">
+<td>
+FR 13
+<td>
+2.13.4 [lex.string]
+<td>
+3
+<td>
+ed
+<td>
+Shouldn't the assert be
+assert(std::strcmp(p, "a\nb\nc") == 0);
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK
+17
+<td>
+2.13.4
+<td>
+10
+<td>
+Te
+<td>
+It would be preferred for attempts to modify
+string literals to be diagnosable errors. This is not possible due
+to the deprecated implicit conversion to pointer to null-terminated
+character sequence of non-const characters. If this deprecated
+conversion were remove (see other comments) then string literals
+are always accessed through const types, and the compiler can
+enforce the no modification rule. The only exception would be using
+const_cast to cast away constness, but this is already covered
+under the const_cast rules so needs no further detail here.
+ 
+<td>
+(asssuming
+deprecated conversion to non-const array is removed or can be
+turned off) Strike the sentence on undefined behaviour.
+<td>
+ 
+<tr valign="top">
+<td>
+UK
+18
+<td>
+2.13.4
+<td>
+ 
+<td>
+Te
+<td>
+The addition of static_assert (7p4) to the
+language raises the need to concatenate string representations of
+integral constant expressions (typically from a sizeof or alignof
+expression) with narrow string literals to provide an informative
+error message. There is no need to support arbitrary constant
+expressions and especially not floating point values or formatting
+flags. Likewise, the need is purely to support static_assert so
+only narrow string literal support is required, although
+generalizing to other literal types would be useful.
+ 
+<td>
+Define a
+syntax to support string-ization of integral constant expressions
+in a form eligible for string literal concatenation, 2.13.4p6.
+Suggested syntax: I" integral-constant-expression ". There is no
+raw variant, although it could combine with type specifier in the
+same way that the R prefix does, supporting u8I, uI, UI and
+LI.
+<td>
+ 
+<tr valign="top">
+<td>
+UK
+19
+<td>
+2.13.4
+<td>
+ 
+<td>
+Ed
+<td>
+The grammar
+for string literal is becoming unwieldy and could easily be
+refactored into the type optional specifier and the string
+contents.
+<td>
+Refactor string-literal grammar as: (note -
+current Drupal view loses formatting which is vital to clearly read
+the grammar) string-literal: string-literal-type-specifierOPT
+string-literal-body string-literal-type-specifier: one of u8 u U L
+string-literal-body: " s-char-sequenceOPT " R raw-string
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+FR 14
+<td>
+3 [basic]
+<td>
+7
+<td>
+ed
+<td>
+"In general it is necessary to determine
+whether a name denotes one of these entities before parsing the
+program that contains it."
+<td>
+Would prefer
+"... before continuing to parse the
+program that contains it."
+
+or even
+"... to complete the parsing of the
+program that contains it."
+as some names denotes entities declared after
+the first occurrence.
+<td>
+ 
+<tr valign="top">
+<td>
+FR 15
+<td>
+3 [basic]
+<td>
+8
+<td>
+ed
+<td>
+/operator-function-id/,
+/conversion-function-id/, /template-id/ are followed by a space and
+then a "s" while usually such production names aren't followed by a
+space when put in plural (see /identifier/).
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK
+20
+<td>
+3
+<td>
+ 
+<td>
+Ge
+<td>
+Chapter 3 ("Basic concepts") provides common
+definitions used in the rest of the document. Now that we have
+concepts as a primary feature, the title of this chapter can be
+confusing as it does not refer to the language feature but to
+definitions used in the document.
+ 
+<td>
+Change the
+title to "Basic definitions".
+<td>
+ 
+<tr valign="top">
+<td>
+UK
+21
+<td>
+3
+<td>
+2
+<td>
+Ed
+<td>
+Concepts is
+now the name of a specific feature of the language, the term now
+risks confusion and ambiguity when used in the more general
+sense.
+<td>
+Rename the
+chapter Basic ???. THe note in p2 specifically needs similar
+rewording
+<td>
+ 
+<tr valign="top">
+<td>
+UK
+22
+<td>
+3
+<td>
+6
+<td>
+Te
+<td>
+References are frequently considered variables,
+but this definition only applies to objects.
+ 
+<td>
+Add "or
+reference" after both uses of "object"
+<td>
+ 
+<tr valign="top">
+<td>
+UK
+23
+<td>
+3.1
+<td>
+2
+<td>
+Ed
+<td>
+alias-declarations are not definitions and should
+be added to the list
+ 
+<td>
+Add
+alias-declaration after typedef declaration.
+<td>
+ 
+<tr valign="top">
+<td>
+UK
+24
+<td>
+3.1
+<td>
+2
+<td>
+Te
+<td>
+The current words suggest the declaration of a
+static integral constant data member of a class cannot be a
+definition. Trying to fix this wording in-place will be verbose and
+risk raising more confusion than it solves, so suggest a footnote
+to call out the special case
+ 
+<td>
+Add a
+footnote attached to the static data membmer rule: *static data
+member delcarations of intergral type may also be definitions if a
+constant integral expression is provided for an initializer.
+<td>
+ 
+<tr valign="top">
+<td>
+UK
+25
+<td>
+3.1
+<td>
+3
+<td>
+Ed
+<td>
+Example is misleading as implicitly defined
+default constructor uses default initialization, not value
+initialization, for non-static data members. In the case of
+std::String this makes no difference, but it makes a big difference
+for fundamental types and pointers.
+ 
+<td>
+Remove the :
+s() from the illustrated default constructor: struct C {
+std::string s; C() { } C(const C& x): s(x.s) { } C&
+operator=(const C& x) { s = x.s; return *this; } ~C() { }
+};
+<td>
+ 
+<tr valign="top">
+<td>
+UK
+26
+<td>
+3.2
+<td>
+1
+<td>
+Te
+<td>
+THe one definition rule should cover references,
+and unless the term 'variable' is extended to cover references the
+list in this paragraph is incomplete.
+ 
+<td>
+Either
+include references in the definition of 'variable' (see earlier
+comment) or add reference to the list in this paragraph.
+<td>
+ 
+<tr valign="top">
+<td>
+UK
+27
+<td>
+3.2
+<td>
+4
+<td>
+Ed
+<td>
+A class type must be complete when catching
+exceptions, even by reference or pointer. See 15.3.
+ 
+<td>
+Add "when
+used in an exception-handler (15.3)" to the list.
+<td>
+ 
+<tr valign="top">
+<td>
+FR 16
+<td>
+3.3 [Declarative regions
+and scopes.]
+<td>
+ 
+<td>
+te
+<td>
+The scope of function parameters is
+defined, but what is the scope of template parameters?
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK
+28
+<td>
+3.3.1
+<td>
+3
+<td>
+Te
+<td>
+Class templates are not classes, so we should
+include this case.
+ 
+<td>
+ammend
+"class" to "class or class template"
+<td>
+ 
+<tr valign="top">
+<td>
+UK
+29
+<td>
+3.3.10
+<td>
+3
+<td>
+Te
+<td>
+operators and
+conversion functions do not have names, yet are susceptible to
+'name hiding' within a class - indeed we rely on this for the
+implicitly declared copy-assignment operator.
+<td>
+Add the additional phrase "The declaration of an
+operator or conversion function in a derived class (Clause 10)
+hides the declaration of an operator or conversion function of a
+base class of the same operator or type;"
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+FR 17
+<td>
+3.5 [Program and
+linkage]
+<td>
+ 
+<td>
+te
+<td>
+This section does not specify whether
+concept names have linkage.
+Do they or not? If concept names do not
+have linkage, then a note is appropriate, and that would be a bit
+surprising and curious. What is the rationale?
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+30
+<td>
+3.5
+<td>
+2
+<td>
+Te
+<td>
+This
+paragraph implies concepts have no linkage (do they need it?) and
+that the entities behind names without linkage cannot be used in
+other scopes. This maybe a bigger problem for concept maps?
+<td>
+Add a note to
+clarify that concepts don't need linkage.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+31
+<td>
+3.5
+<td>
+4
+<td>
+Te
+<td>
+What is the
+linkage of names declared inside a namespace, in turn declared
+inside an anonymous namespace? It is not clear why such a namespace
+has no linkage, and there is no language suggesting its memmbers
+should lose linkage with it, which we assume is the intended
+consequence.
+<td>
+Clarify rules
+for namespaces inside nested namespaces, or remove the
+restriction.
+<td>
+ 
+<tr valign="top">
+<td>
+US 23
+<td>
+3.5
+<td>
+6
+<td>
+ed
+<td>
+Bad paragraph break.
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+FR 18
+<td>
+3.5 [basic.link]
+<td>
+6
+<td>
+ed
+<td>
+The paragraph number is not aligned with the
+text.
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+FR 19
+<td>
+3.6 [Start and
+termination]
+<td>
+ 
+<td>
+te
+<td>
+This section completely ignores the real
+world and practical case of dynamically linked or loaded libraries.
+In current computing environments, they are ubiquitous and they
+cannot be ignored in
+practical C++ programs. The
+Standard
+should address this aspect.
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+32
+<td>
+3.6.1
+<td>
+3
+<td>
+Te
+<td>
+Do we really
+want to allow: constexpr int main() { return 0; } as a valid
+program?
+<td>
+Add constexpr to the list of ill-formed things to
+annotate main
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 24
+<td>
+3.6.1
+<td>
+4
+<td>
+te
+<td>
+std::quick_exit is not referenced.
+<td>
+Reference std::quick_exit as well as std::exit in
+saying that automatic objects are not destroyed. It should
+not
+do so in saying that calling
+std::quick_exit is undefined from within destructors for static or
+thread duration objects.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 25
+<td>
+3.6.3
+<td>
+¶ 2 last sent.
+<td>
+ed
+<td>
+The parenthesized phrase,
+introduced via “i.e.” is in the nature of an
+example.
+<td>
+Change “i.e.”
+to “e.g.”
+<td>
+ 
+<tr valign="top">
+<td>
+JP 6
+<td>
+3.7.4.1
+<td>
+4th paragraph, 4th line
+<td>
+ed
+<td>
+Typo.
+Lack of a comma right after
+“(3.7.2)” in the sentence while there are commas after
+any other recitations like “(3.7.1)”. It is just a
+unification matter.
+ 
+[ Note: in particular, a global
+allocation function is not called to allocate storage for objects
+with static storage duration (3.7.1), for objects or references
+with thread storage duration (3.7.2) for objects of type
+std::type_info (5.2.8), or for the copy of an object thrown by a
+throw expression (15.1). -end note ]
+ 
+should be
+ 
+[ Note: in particular, a global
+allocation function is not called to allocate storage for objects
+with static storage duration (3.7.1), for objects or references
+with thread storage duration (3.7.2), for objects of type
+std::type_info (5.2.8), or for the copy of an object thrown by a
+throw expression (15.1). -end note ]
+ 
+<td>
+Correct typo.
+<td>
+ 
+<tr valign="top">
+<td>
+DE-3
+<td>
+3.7.4.3
+<td>
+ 
+<td>
+te
+<td>
+
+DE-3 It is unclear whether
+the following code has well-defined behavior; none of the bullets
+in the second paragraph seem to apply.
+int& i = *new
+int(5);
+delete &i;
+<td>
+Clarify that &i is
+considered a safely-derived pointer value.
+<td>
+ 
+<tr valign="top">
+<td>
+US 26
+<td>
+3.8
+<td>
+1 and 5
+<td>
+te
+<td>
+Use of object fields during destruction is
+excessively and erroneously constrained.
+<td>
+See the attached document "Issues with
+the C++ Standard" under Chapter 3 "Use of objects, especially from
+other threads, during destruction".
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 27
+<td>
+3.9
+<td>
+¶ 9 first
+sent.
+<td>
+ed
+<td>
+There is a
+superfluous/extraneous “and”.
+<td>
+Delete “and”
+from the phrase “and std::nullptr_t”.
+<td>
+ 
+<tr valign="top">
+<td>
+FR 20
+<td>
+3.9 [Types]
+<td>
+ 
+<td>
+te
+<td>
+The phrase 'effective type' is defined and
+used in a way that is incompatible with C99. Such a deliberate
+incompatible choice of terminology is both unfortunate and
+confusing, given past practice of the committee to maintain greater
+compatibility with C99. We strongly suggest that the phrase
+'effective type' not be used in such an incompatible way.
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 7
+<td>
+3.9.2
+<td>
+3rd paragraph, 13th line
+<td>
+ed
+<td>
+over-aligned type was
+added as new notion. So it is preferable to add the link after
+that.
+<td>
+Add (3.11) after over-aligned type as
+the link.
+[ Note:
+pointers to over-aligned types(3.11) have no special representation, but their
+range of valid values is restricted by the extended alignment
+requirement. This International Standard specifies only two ways of
+obtaining such a pointer: taking the address of a valid object with
+an over-aligned type(3.11), and using one of the runtime pointer alignment
+functions. An implementation may provide other means of obtaining a
+valid pointer value for an over-aligned type(3.11).—end note ]
+<td>
+ 
+<tr valign="top">
+<td>
+US 28
+<td>
+3.9.3
+<td>
+¶ 5 first
+sent.
+<td>
+ed
+<td>
+
+The closing braces of the
+first two sets are preceded by extraneous space.
+ 
+<td>
+Delete the extra
+spaces.
+<td>
+ 
+<tr valign="top">
+<td>
+DE 4
+<td>
+4.2
+<td>
+p2
+<td>
+te
+<td>
+DE-4 The deprecated
+conversion from string literals to pointer to non-const character
+types should be limited to those conversions and types of string
+literals that were already present in ISO/IEC 14882:2003, or the
+deprecated conversions should be removed entirely.
+<td>
+
+Consider applying the
+proposed resolution presented in core issue 693 in WG21 document
+N2714 “C++ Standard Core Language Active Issues, Revision
+58“, available at
+http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2714.html
+; or remove only the conversions to "pointer to char16_t", "pointer
+to char32_t" in 4.2 paragraph 2 and 15.1 paragraph 3.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+CH 1
+<td>
+4.9 and 5.2.9
+<td>
+ 
+<td>
+te
+<td>
+With respect to the target
+type, pointer to members should behave like normal pointers (least
+surprise principle).
+<td>
+
+The standard should allow
+implicit conversions from ``pointer to member of <tt>T</tt> of type cv <tt>D</tt>'' to ``pointer to member of
+<tt>T</tt> of type cv
+B'', where D is of class type and B is a public base of D, It
+should allow explicit conversion the other way around.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+DE-5
+<td>
+4.11, 5.3.1, 5.5
+<td>
+ 
+<td>
+te
+<td>
+DE-5 Ref-qualification has
+not been integrated with pointer-to-members.
+<td>
+
+Review implicit conversions
+(4.11), forming pointer-to-members (5.3.1), and dereferencing
+pointer-to-members (5.5) for type-safety concerns in the presence
+of ref-qualifiers on the member.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+33
+<td>
+4.13
+<td>
+1
+<td>
+Te
+<td>
+We have: "No
+two signed integer types shall have the same rank ..." "the rank of
+char shall equal the rank of signed char" Can we therefore deduce
+that char may not be signed?
+<td>
+Replace the first sentence with "No two signed
+integer types shall have the same rank, even if they have the same
+representation, except that signed char shall have the same rank as
+char even if char is signed (3.9.1/1)."
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+34
+<td>
+4.13
+<td>
+1
+<td>
+Ed
+<td>
+6th bullet, "the rank of char" - first letter
+should be capitalised for consistency with the other bullets
+ 
+<td>
+The rank of
+char
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+36
+<td>
+5.1
+<td>
+1
+<td>
+Ed
+<td>
+Primary expressions are literals, names, names
+qualified by the scope resolution operator ::, and lambda
+expressions. The immediately following grammar flatly contradicts
+this - this and (e) are also lambda expressions.
+ 
+<td>
+Delete this
+paragraph.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+37
+<td>
+5.1
+<td>
+11
+<td>
+Ed
+<td>
+Member function templates are not member
+functions, so should also be listed in the 3rd bullet
+ 
+<td>
+Add member
+function templates to the 3rd bullet
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+38
+<td>
+5.1
+<td>
+3
+<td>
+Te
+<td>
+this might be
+useful in a few more places than it is permitted, specifically in
+decltype expressions within a class. Two examples that would be
+ill-formed at class scope without changes: typedef decltype( *this
+) this_type; decltype( [this]{ return this->memfun(); } )
+my_lambda;
+<td>
+... words to
+follow ...
+<td>
+ 
+<tr valign="top">
+<td>
+JP 8
+<td>
+5.1
+<td>
+7th paragraph, Syntax rules
+<td>
+te
+<td>
+In the current syntax definition, a
+scope operator(::) cannot be applied to decltype, but it should be.
+It would be useful in the case to obtain member type(nested-type)
+from an instance as follows:
+vector<int> v;
+decltype(v)::value_type i = 0; // int i =
+0;
+<td>
+Add “decltype ( expression ) ::
+“ to nested-name-specifier syntax like below.
+ 
+nested-name-specifier:
+type-name ::
+namespace-name ::
+nested-name-specifier identifier ::
+nested-name-specifier templateopt
+simple-template-id ::
+nested-name-specifieropt concept-id ::
+decltype ( expression ) ::
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 9
+<td>
+5.1.1
+<td>
+ 
+<td>
+te
+<td>
+It would be preferable that
+“&&” could be specified in a lambda expression
+to declare move capture.
+ 
+Here is an example from N2709.
+ 
+template<typename F>
+std::unique_future<typename
+std::result_of<F()>::type> spawn_task(F f){
+typedef typename
+std::result_of<F()>::type result_type;
+ 
+struct local_task {
+std::promise<result_type>
+promise;
+F func;
+local_task(local_task const&
+other)=delete;
+local_task(F func_):
+func(func_)
+{}
+ 
+local_task(local_task&&
+other):
+promise(std::move(other.promise)),
+f(std::move(other.f))
+{}
+ 
+void operator() {
+try
+{
+promise.set_value(f());
+}
+catch(...)
+{
+promise.set_exception(std::current_exception());
+}
+}
+};
+ 
+local_task task(std::move(f));
+ 
+std::unique_future<result_type>
+res(task.promise.get_future());
+std::thread(std::move(task));
+return res;
+}
+ 
+This can be rewritten simply as follows
+if move capture can be used in a lambda expression.
+ 
+template<typename F>
+std::unique_future<typename
+std::result_of<F()>::type> spawn_task(F f){
+typedef typename
+std::result_of<F()>::type result_type;
+ 
+std::promise<result_type>
+promise;
+std::unique_future<result_type>
+res(promise.get_future());
+std::thread([&&promise,
+&&f]() {
+try
+{
+promise.set_value(f());
+}
+catch(...)
+{
+promise.set_exception(std::current_exception());
+}
+});
+return res;
+}
+ 
+<td>
+Add move capture in a lambda
+expression.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 10
+<td>
+5.1.1
+<td>
+ 
+<td>
+te
+<td>
+In the current syntax definition, a
+returned type of a function object cannot be obtained by using
+result_of from an unnamed function object generated by a lambda
+expression because it doesn’t have result type.
+ 
+template <class F>
+void foo(F f)
+{
+typedef std::result_of<F()>::type
+result; // error
+}
+foo([]{});
+ 
+If “Callable” or
+“Predicate” concept is specified, a returned type can
+be obtained from a function object without result_type. But it is
+preferable to be able to obtain it with template.
+ 
+<td>
+Add result_type to the syntax of an
+unnamed function object generated by a lambda expression.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 29
+<td>
+5.1.1
+<td>
+ 
+<td>
+te
+<td>
+The standard does not state whether or
+not direct recursion of lambdas is possible.
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 30
+<td>
+5.1.1
+<td>
+ 
+<td>
+te
+<td>
+The standard does not clarify the meaning of
+<code>this</code> in lambdas. Does it mean
+this lambda, or this class within which the lambda is
+nested?
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 31
+<td>
+5.1.1
+<td>
+ 
+<td>
+te
+<td>
+The current wording does not specify how context
+capturing and name resolution take place when the inner lambda refers to the
+outer lambda's locals variables and parameters.
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+45
+<td>
+5.1.1
+<td>
+para
+2
+<td>
+Te
+<td>
+Lambda is a
+language feature with an apparent dependency on <functional>.
+This increases dependency of language on library, and is
+inconsistent with the definition of freestanding in
+17.6.2.4.
+<td>
+Change the text "a closure object behaves as a
+function object" to "a closure object is a built-in object which
+behaves as a function object"; and after "context.", insert " A
+closure object may be used without any need for
+<functional>." This makes clear what may already be implied,
+namely that lambdas can be used in freestanding implementations and
+don't increase dependency of language on library. (Marked as
+technical comment anyway because this clarity is technically
+important).
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 32
+ 
+<td>
+5.1.1
+<td>
+3
+<td>
+ed
+<td>
+The final italic "this" in the paragraph
+should be a teletype "this".
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+39
+<td>
+5.1.1
+<td>
+11
+<td>
+Te
+<td>
+This
+paragraph lists all the special member functions for the class
+representing a lambda. But it omits the destructor, which is
+awkward.
+<td>
+Add "F has an
+implicitly-declared destructor".
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+40
+<td>
+5.1.1
+<td>
+12
+<td>
+Te
+<td>
+If one or more names in the effective capture set
+are preceded by &, the effect of invoking a closure object or a
+copy after the innermost block scope of the context of the lambda
+expression has been exited is undefined. That is too restrictive.
+The behaviour should be undefined iff the lifetime of any of the
+variables referenced has ended. This should be safe and legal;
+currently it has undefined behaviour: int i;
+reference_closure<void ()> f; if (blah) { f = [&i]() { };
+} if (f) f();
+ 
+<td>
+If one or
+more names in the effective capture set are preceded by &, the
+effect of invoking a closure object or a copy after the lifetime of
+any of the variables referenced has ended is undefined.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+41
+<td>
+5.1.1
+<td>
+12
+<td>
+Te
+<td>
+For argument
+dependant lookup (3.4.2) the associated namespaces for a class
+include its bases, and associated namespaces of its bases.
+Requiring the result of a lambda expression *to dervide from*
+std::reference_closure means that ADL will look in namespace std
+when the lambda capture is entirely by reference, which might have
+surprising results. Also, relying on the idea of implicitly slicing
+objects is uncomfortable.
+<td>
+Replace
+inheritance with implicit conversion.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+42
+<td>
+5.1.1
+<td>
+ 
+<td>
+Te
+<td>
+A lambda with
+an empty capture list has identical semantics to a regular function
+type. By requiring this mapping we get an efficient lambda type
+with a known API that is also compatible with existing operating
+system and C library functions.
+<td>
+Add a new paragraph: "A lambda expression with an
+empty capture set shall be convertible to pointer to function type
+R(P), where R is the return type and P is the parameter-type-list
+of the lambda expression." Additionally it might be good to (a)
+allow conversion to function reference (b) allow extern "C"
+function pointer types
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+43
+<td>
+5.1.1
+<td>
+12
+<td>
+Te
+<td>
+The note spells out the intent that objects from
+lambda-expressions with an effective capture list of references
+should be implemented as a pair of pointers. However, nothing in
+the rest of 5.1.1 lifts the requirement of to declare a reference
+member for each captured name, and a non-normative note is not
+enough to relax that.
+ 
+<td>
+... provvide
+exceptions in the right places ...
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+44
+<td>
+5.1.1
+<td>
+12
+<td>
+Te
+<td>
+There is a strong similarity between a [&]{}
+lambda capturing a stack frame, and a [this]{} lambda binding a
+member function to a class instance. The reference_closure
+requirement should be extended to the second case, although we need
+some syntax to create such an object that is distinct from the
+existing pointer-to-member syntax. This would be a cleaner
+alternative to the new std::mem_fn library component.
+ 
+<td>
+Extend
+reference_closure requirement to cover [this] lambdas. Consider a
+simple syntax for creating such bound expressions.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+46
+<td>
+5.1.1
+<td>
+para
+12
+<td>
+Te
+<td>
+The
+requirement that a lambda meeting appropriate conditions be an
+object derived from reference_closure makes lambda the language
+feature dependent on <functional>, which increases dependency
+of the language on the library and bloats the definition of
+freestanding C++.
+<td>
+Replace text "is publicly derived from" with
+"shall be implemented in a manner indistinguishable from". This
+places an ABI constraint on reference closures such that compiler
+and library implementer have to do compatible things. But it cuts
+the dependency of lambda syntax on <functional>.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+DE-6
+<td>
+5.1.1, 20.7.18
+<td>
+ 
+<td>
+te
+<td>
+DE-6 Some uses of lambda
+expressions refer to specializations of the unconstrained class
+template std::reference_closure (5.1.1). If the
+lambda expression appears in a constrained context and the return
+type or a parameter type for the lambda depend on a template
+parameter (see 14.10), such a use is ill-formed.
+<td>
+In 20.7.18, for the class
+template std::reference_closure, require
+Returnable for R and VariableType for each of the ArgTypes.
+<td>
+ 
+<tr valign="top">
+<td>
+DE-7
+<td>
+5.1.1
+<td>
+p10
+<td>
+ed
+<td>
+DE-7 The note at the end
+of paragraph 10 appears to be garbled.
+<td>
+Remove "or references" in
+the note.
+<td>
+ 
+<tr valign="top">
+<td>
+DE-8
+<td>
+5.1.1
+<td>
+p10
+<td>
+te
+<td>
+DE-8 The construction of
+the function call operator signature is missing specifications for
+the ref-qualifier and the attribute-specifier.
+<td>
+Add bullets that say that
+the ref-qualifier and the attribute-specifier are absent.
+<td>
+ 
+<tr valign="top">
+<td>
+US 33
+<td>
+5.1.1
+<td>
+11
+<td>
+Ge
+<td>
+There is no definition of
+“move constructor” or “move
+operation”
+<td>
+
+Since this is the first place
+the terms are used, a definition should either be added here, or a
+cross reference to one.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+DE-9
+<td>
+5.1.1
+<td>
+ 
+<td>
+te
+<td>
+DE-9 There is not a single
+example of a lambda-expression in the standard. See also core issue
+720 in WG21 document N2791 "C++ Standard Core Language Active
+Issues, Revision 59", available at
+http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2791.html
+.
+<td>
+Add a few well-chosen
+examples.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+52
+<td>
+5.2
+<td>
+3
+<td>
+Ed
+<td>
+This
+paragraph seens out of place, assignment expressions are covered in
+5.17
+<td>
+Move p3 to
+subsection 5.17
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+53
+<td>
+5.2.1
+<td>
+ 
+<td>
+Te
+<td>
+The
+definition in p1 makes no allowance for overloaded operator[] that
+treats the expression as a simple function call, and does not
+support the interchangability of arguments. Howver p2 relies on
+this definition when describing the use of brace-init-lists inside
+[].
+<td>
+Insert a new
+p2 describing the changed semantics for overloaded operator[]. This
+should be a note to avoid introducing normative text that could
+potentially conflict with the later definiton of these
+semantics.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+59
+<td>
+5.2.2
+<td>
+7
+<td>
+Te
+<td>
+When there is
+no parameter for a given argument, the argument is passed in such a
+way that the receiving function can obtain the value of the
+argument by invoking va_arg. That shouldn't apply to parameter
+packs. template <class ... Types> void f(Types ... pack);
+f(1, 2, 3);
+<td>
+Clarify that
+this sentence only applies where the ellipsis is used.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+60
+<td>
+5.2.5
+<td>
+3
+<td>
+Ed
+<td>
+In the
+remainder of 5.2.5, cq represents either const or the absence of
+const vq represents either volatile or the absence of
+volatile.
+<td>
+Add "and"
+before vq
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+61
+<td>
+5.2.5
+<td>
+p1
+<td>
+Ed
+<td>
+Together with
+footnote 60 there may be confusion that the postfix expression is
+always evaluated - even when part of an unevaluated operand. We
+believe the standard does not require this, and a comment in the
+existing note would be a useful clarification.
+<td>
+Clarify in
+footnote 60 that this will not happen if the whole expression is an
+unevaluated operand.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+62
+<td>
+5.2.5
+<td>
+4
+<td>
+Te
+<td>
+In the final
+bullet, what does 'not an lvalue' mean? Does it imply rvalue, or
+are there other possible meanings? Should clauses that trigger on
+rvalues pick up on this?
+<td>
+Replace 'not
+an lvalue' with 'is an rvalue'.
+<td>
+ 
+<tr valign="top">
+<td>
+DE-10
+<td>
+5.2.5
+<td>
+ 
+<td>
+te
+<td>
+DE-10 If E1.E2 is
+referring to a non-static member function, the potential
+ref-qualification on E2 should be taken into account.
+<td>
+Adjust the presentation of
+the types involved as appropriate.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+63
+<td>
+5.2.6
+<td>
+2
+<td>
+Ed
+<td>
+Paragraph 2
+is missing its number.
+<td>
+Add
+one.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+64
+<td>
+5.2.7
+<td>
+3
+<td>
+Ed
+<td>
+A new name R
+is introduced for use in paragraphs 3 and 4. But R is the same as
+T.
+<td>
+Replace R with T and replace "the required result
+type (which, for convenience, will be called R in this
+description)" with "T".
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+65
+<td>
+5.2.7
+<td>
+8
+<td>
+Te
+<td>
+In the first two bullets we have "the result is a
+pointer (an lvalue referring) to". But para 2 makes clear that a
+dynamic_cast of an rvalue references produces a rvalue. (Can an
+lvalue refer to anything anyway?)
+ 
+<td>
+Replace "an
+lvalue referring to" with "reference", twice.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+66
+<td>
+5.2.8
+<td>
+1
+<td>
+Te
+<td>
+typeid may return "an implementation-defined class
+derived from std :: type_info". The derivation must be
+public.
+ 
+<td>
+an
+implementation-defined class publicly derived from std ::
+type_info
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+67
+<td>
+5.2.9
+<td>
+1, 2,
+3
+<td>
+Te
+<td>
+Paragraph 1
+specifies when the result of static_cast is an lvalue; repeating it
+is unnecessary.
+<td>
+In para 2, delete "It is an lvalue if the type
+cast to is an lvalue reference; otherwise, it is an rvalue." and
+"The result is an rvalue.". In para 3, delete "The result is an
+lvalue if T is an lvalue reference type (8.3.2), and an rvalue
+otherwise."
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+54
+<td>
+5.2.10
+<td>
+3,
+6
+<td>
+Te
+<td>
+Para 3: "The
+mapping performed by reinterpret_cast is implementation-defined.".
+Para 6: "... the result of such a pointer conversion is
+unspecified." Which is it?
+<td>
+In para 6, replace unspecified with
+implementation-defined. Alternatively, delete paragraph 3, since
+individual cases are labelled appropriately.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+55
+<td>
+5.2.10
+<td>
+2
+<td>
+Ed
+<td>
+dynamic_cast
+and reinterpret_cast crossreference 5.2.11 without creating an
+extra note. The second half of the note is unrelated to the
+crossrefernce, and would serve as well in normative text.
+<td>
+Strike the note about definition of casting away
+constness, preserve the cross-reference. The second sentance on
+reintrepret_cast to its own type should move out of the note into
+the normative text.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+56
+<td>
+5.2.10
+<td>
+5
+<td>
+Ed
+<td>
+The notion of safely derived pointers means this
+conversion may not be as safe in the revised standard as the
+original. It would be good to call attention to the changed
+semantics with a note.
+ 
+<td>
+Add: [Note:
+the result of such a conversion will not be a safely-derived
+pointer value (3.7.4.3) -- end note]
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+57
+<td>
+5.2.10
+<td>
+8
+<td>
+Ed
+<td>
+Conditionally
+supported behaviour gives a wide range or permission, so clarify
+relationship between safely-derived object pointers and function
+pointers in a note.
+<td>
+Add: [Note:
+In such cases, the implementation shall also define whether a
+safely-derived object pointer cast to a function pointer can be
+safely cast back -- end note]
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+58
+<td>
+5.2.11
+<td>
+9
+<td>
+Te
+<td>
+Casting from an lvalue of type T1 to an lvalue of
+type T2 using a reference cast casts away constness if a cast from
+an rvalue of type “pointer to T1” to the type
+“pointer to T2” casts away constness. That doesn't
+cover rvalue references.
+ 
+<td>
+Replace
+lvalue with "lvalue or rvalue" twice.
+<td>
+ 
+<tr valign="top">
+<td>
+US 34
+ 
+<td>
+5.3
+<td>
+1
+<td>
+ed
+<td>
+The list of unary operator should be in teletype
+font.
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+68
+<td>
+5.3.1
+<td>
+2-9
+<td>
+Te
+<td>
+All the unary
+operands other than * return rvalues - but this is not
+stated.
+<td>
+Add a paragraph 1a "The following unary operators
+all produce results that are rvalues."
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+69
+<td>
+5.3.1
+<td>
+2
+<td>
+Te
+<td>
+If we cannot bind references/take address of
+functions in concept_maps, does that mean we cannot use generic
+bind in constrained templates? Launch threads with expressions
+found via concept map lookup? Hit problems creating std::function
+objects? Does the problem only occur if we use qualified lookup to
+explicitly name a concept map? Does it only kick in if we rely on
+the implicit function implementation provided by a concept_map, so
+some types will work and others won't for the same
+algorithm?!
+ 
+<td>
+... unknown
+...
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+70
+<td>
+5.3.3
+<td>
+1
+<td>
+Te
+<td>
+The sizeof operator shall not be applied to ... an
+enumeration type before all its enumerators have been declared We
+should allow enum E : int; sizeof(E).
+ 
+<td>
+Change "an
+enumeration type" to "an enumeration type whose underlying type is
+not fixed".
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+71
+<td>
+5.3.4
+<td>
+2
+<td>
+Te
+<td>
+The type of
+an allocated object wih the type specifier auto is determined by
+the rules of copy initialization, but the initialization applied
+will be direct initialization. This would affect classes which
+declare their copy constructor explicit, for instance. For
+consistency, use the same form of initiailization for the deduction
+as the new expression.
+<td>
+Replace T x =
+e; with T x(e);
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+72
+<td>
+5.3.4
+<td>
+7
+<td>
+Te
+<td>
+The library headers have been carefully structured
+to limit the dependencies between core language and specific
+headers. The exception thrown should be catchable by a handler for
+a type lised in <exception> header in cluase 18. This might
+be accomplished by moving length_error into the <exception>
+header, but its dependency on logic_error with its std::string
+constructors suggest this is not a good idea. Prefer to pick an
+existing exception instead.
+ 
+<td>
+Throw
+std::bad_alloc instead of std::length_error.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+73
+<td>
+5.3.4
+<td>
+6
+<td>
+Ed
+<td>
+A class type with conversion operator can only be
+used if the conversion type is constexpr and the class is a literal
+type. Adding the single word 'literal' before class type will
+clarify this.
+ 
+<td>
+Add 'literal'
+before 'class type'
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+74
+<td>
+5.3.4
+<td>
+8
+<td>
+Ed
+<td>
+operators, like constructors and destructors, do
+not have names. However, in certain circumstances they can be
+treated as if they had a name, but usually the stanadard is very
+clear not to actually describe their name as a distinct
+property.
+ 
+<td>
+Change "the
+allocation function’s name is operator new" to "the
+allocation function is named operator new" and similarly for
+operator delete.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+35
+<td>
+5.3.4
+<td>
+9
+<td>
+Ed
+<td>
+Missing
+period in middle of paragraph between "in the scope of T" and "If
+this lookup fails"
+<td>
+Add a period between "in the scope of T" and "If
+this lookup fails"
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+75
+<td>
+5.3.5
+<td>
+8
+<td>
+Ed
+<td>
+A paragraph strarting with [Note... is easily
+skipped when reading, missing the normative text at the end.
+ 
+<td>
+Swap order of
+the note and normative text.
+<td>
+ 
+<tr valign="top">
+<td>
+FR 21
+<td>
+5.3.6 [Alignof
+<td>
+ 
+<td>
+te
+<td>
+Should not the type of alignof-expression be of
+type std::max_align_t?
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 35
+<td>
+5.8
+<td>
+2 and 3
+<td>
+ed
+<td>
+There is curious spacing in the
+expressions "E1 <<E2" and "E1 >>E2". This is a
+formatting change since previous versions of the Standard.
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+47
+<td>
+5.14 /
+5.15
+<td>
+2
+<td>
+Ed
+<td>
+Why are the descriptions of order of evaluation of
+expressions and side effects different between && and ||
+operators. The interaction with the memory model should be
+identical, so identical words should be used to avoid accidential
+inconsistencies in interpretation.
+ 
+<td>
+Pick one form
+of wording as 'the best' and apply it in both places.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+48
+<td>
+5.18
+<td>
+1
+<td>
+Ed
+<td>
+The defining feature of the comma operator is the
+guaranteed sequencing of two expressions. This guarantee is lost
+when presented with an overloaded operator, and this change is
+subtle enough to call attention to it.
+ 
+<td>
+Add: [Note:
+There are no guarantees on the order of value computation for an
+overloaded comma operator -- end note]
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+49
+<td>
+5.19
+<td>
+2
+<td>
+Te
+<td>
+Is an
+implementation permitted to reject this? constexpr int f() { return
+f(); } int a[f()]; AFAICT it is well-formed; f() seems to satisfy
+all the rules to make it a constant expression. I would hate
+compilation to become a potentially non-terminating
+experience.
+<td>
+Add an escape clause to allow the implementation
+to reject excessively deep nesting of constexpr function
+evaluations. (This can possibly be a note, since it is arguable
+that this point is handled by the general rule on resource limits
+in 1.4/2. A sufficiently smart compiler could use tail recursion
+above, meaning that it would never run out of memory given this
+program though.)
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+50
+<td>
+5.19
+<td>
+2
+<td>
+Te
+<td>
+The following
+should be valid: enum E { foo = 4}; const E c = foo; int a[c]; But
+currently it is not - c is not an lvalue of effective integral type
+(4th bullet). (See also 7.1.6.1/2)
+<td>
+Change "effective integral type" to "effective
+integral or enumeration type" in the 4th bullet, 1st
+sub-bullet.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+51
+<td>
+5.19
+<td>
+2
+<td>
+Te
+<td>
+typeid expressions can never be constant, whether
+or not the operand is a polymorphic class type. The result of the
+expression is a reference, and the typeinfo class that the
+reference refers to is polymorphic, with a virtual destructor - it
+can never be a literal type.
+ 
+<td>
+Strike the
+words "whose operand is of a polymorphic class type" on the bullet
+for typeid expressions.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+76
+<td>
+6.3
+<td>
+ 
+<td>
+Ed
+<td>
+Do we really
+need two different terms that say the same thing?
+<td>
+Pick either 'block' or 'compound statement' as the
+preferred term and use it consistently throughout the
+standard.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+FR 22
+<td>
+6.4.2 [The switch
+statement]
+<td>
+ 
+<td>
+te
+<td>
+The constant-expression in
+ 
+case constant-expression
+ 
+should be allowed to be of any constant
+expression of literal type for which a constexpr comparison
+operator (operator< and operator==) is in scope. Now that
+constant expressions of other integral types are evaluated at
+compile time, the restriction for case-labels is at best
+artificial.
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+77
+<td>
+6.5
+<td>
+5
+<td>
+Ed
+<td>
+The terms i/o operation, synchronize operation and
+atomic operation have very specific meanings within the standard.
+The paragraph would be much easier to understand with the terms
+crossreferenced.
+ 
+<td>
+Profide a
+cross-reference for the terms: i/o operation, synchronize operation
+and atomic operation
+<td>
+ 
+<tr valign="top">
+<td>
+JP 11
+<td>
+6.5.4
+<td>
+1st paragraph, 5th line
+<td>
+ed
+<td>
+There is no _RangeT type
+in the equivalent code to “range-base for” statement.
+It existed in N2049.
+<td>
+Add a typedef for _RangeT in the example
+as follows:
+ 
+{
+
+    typedef
+decltype( expression ) _RangeT;
+
+    auto
+&& __range = ( expression );
+
+    for ( auto
+__begin = std::Range<_RangeT>:: begin(__range),
+
+           
+__end =
+std::Range<_RangeT>:: end(__range);
+
+          __begin != __end;
+
+          ++__begin )
+
+    {
+
+        for-range-declaration = *__begin;
+
+        statement
+
+    }
+}
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+78
+<td>
+6.5.4
+<td>
+2
+<td>
+Te
+<td>
+Including the
+header <iterator_concepts> is far too unwieldy to enable an
+important and (expected to be) frequently used syntax.
+<td>
+Merge <iterator_concepts> into
+<concepts> and change 6.5.4p2 to refer to <concepts>,
+or make the Range concept fundamental along with the other support
+concepts in 14.9.4 and strike any reference to including a
+header.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+79
+<td>
+6.5.4
+<td>
+ 
+<td>
+Te
+<td>
+The definition of for (for-range-declaration :
+expression) statement is expanded in terms which require a Range
+concept, and the program is ill-formed if <iterator_concepts>
+isn't included. For users, iterating through old-fashioned arrays,
+this is a sledge-hammer to crack a nut and compares poorly with
+other languages. It's also not possible to implement this without
+adversely impacting the freestanding definition in 17.6.2.4.
+ 
+<td>
+When
+expression is an array a of length N whose length is known at
+compile time, expand range-for as 'for (... p=a, p!=a+N, p++) ...'
+without requiring the Range concept or <iterator_concepts>.
+Also, when expression is an initializer_list, expand range-for
+similarly without requiring <iterator_concepts>.
+<td>
+ 
+<tr valign="top">
+<td>
+DE-11
+<td>
+6.9
+<td>
+p1
+<td>
+te
+<td>
+
+DE-11 A sentence in paragraph
+1 reads: "Outside of a constrained context, the late-checked block
+has no effect." This, at face value, specifies that the
+compound-statement of such a late-checked block is never
+executed, which appears to be unintended.
+ 
+<td>
+State that such a
+late-checked block has the same meaning as if the late_check keyword were absent.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+80
+<td>
+7
+<td>
+1
+<td>
+Ed
+<td>
+Many of the sections and major subsections open
+with a sentence summarising the content. I'm not sure this is
+necessary; this isn't a tutorial. The problem with these summaries
+is that because they omit much of the detail, they tend to be
+inaccurate. This may not matter, but I feel the document would be
+improved by omitting them. There's a prime example here:
+"Declarations specify how names are to be interpreted." Not true
+for static_assert, an asm declaration nor an anonymous bit
+field.
+ 
+<td>
+Strike the
+first sentence.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+81
+<td>
+7
+<td>
+4
+<td>
+Te
+<td>
+String literal concatenation happens in phase 6,
+before parsing, so it is legal and useful to use it for the string
+literal in a static_assert. It would be useful to add a note
+mentioning this.
+ 
+<td>
+Add a note:
+Multiple adjacent string literals may be used instead of a single
+/string-literal/; see [lex.phases].
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+82
+<td>
+7
+<td>
+2
+<td>
+Te
+<td>
+Paragraph 2 talks about declarations that can have
+nested declarations within them. It doesn't mention scoped
+enumerations - but according to 7.2/11, "Each scoped enumerator is
+declared in the scope of the enumeration."
+ 
+<td>
+Add "scoped
+enumeration" to the list in the second sentence.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+83
+<td>
+7.1
+<td>
+2
+<td>
+Te
+<td>
+The longest sequence of decl-specifiers that could
+possibly be a type name is taken as the decl-specifier-seq of a
+declaration. But many sequences of decl-specifiers cannot possibly
+be a type name - eg the sequence "friend int", or "typedef
+int".
+ 
+<td>
+Not sure. I
+understand the rule, just not how to say it.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+84
+<td>
+7.1
+<td>
+1
+<td>
+Te
+<td>
+The grammar includes alignment-specifier as a
+production for decl-specifier, but there is no production for
+alignment-specifier. I suspect this is a holdover from before
+alignment was handled as an attribute.
+ 
+<td>
+Delete the
+production (including the duplicate in A6)
+<td>
+ 
+<tr valign="top">
+<td>
+FI 3
+<td>
+7.1
+<td>
+[dcl.spec.auto]
+<td>
+te
+<td>
+
+While it’s considered
+too late for this standard revision, consider loosening the
+restrictions for auto specifier and making it more a mirror of a
+deduced template function parameter.
+ 
+<td>
+See
+restricted-auto.ppt
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+85
+<td>
+7.1.1
+<td>
+1
+<td>
+Ed
+<td>
+... the init-declarator-list of the declaration
+shall not be empty (except for global anonymous unions, which shall
+be declared static). Global here means "declared at namespace
+scope". (cf 9.5/3 "Anonymous unions declared in a named namespace
+or in the global namespace shall be declared static.").
+ 
+<td>
+Replace
+"global" with "namespace scope".
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+86
+<td>
+7.1.1
+<td>
+2,3
+<td>
+Te
+<td>
+The register keyword serves very little function,
+offering no more than a hint that a note says is typically ignored.
+It should be deprecated in this version of the standard, freeing
+the reserved name up for use in a future standard, much like auto
+has been re-used this time around for being similarly
+useless.
+ 
+<td>
+Deprecate
+current usage of the register keyword.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+87
+<td>
+7.1.1
+<td>
+1, 4,
+5
+<td>
+Te
+<td>
+Why require two keywords, where one on its own
+becomes ill-formed? thread_local should imply 'static' in this
+case, and the combination of keywords should be banned rather than
+required. This would also eliminate the one of two exceptions
+documented in 7.1.1p1.
+ 
+<td>
+Drop
+requirement to combine static keyword with thread_local at
+block-scope inside a function definition.
+<td>
+ 
+<tr valign="top">
+<td>
+US 36
+<td>
+7.1.1
+<td>
+4
+<td>
+te
+<td>
+The permission to use thread_local
+static data members is missing.
+ 
+<td>
+Add the static members as a permitted use.
+<td>
+ 
+<tr valign="top">
+<td>
+FR 23
+<td>
+7.1.5 [constexpr]
+<td>
+ 
+<td>
+te
+<td>
+'constexpr' functions should be allowed to
+take const reference parameters, as long as their uses are in a
+context where a constant expression may be required. For example,
+the following should be allowed
+ 
+template<typename T, int N>
+int size(const T(&)[N]) { return N;
+}
+ 
+int a[] = { 41,42,43,44 };
+enum { v = size(a) };
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 12
+<td>
+7.1.5
+<td>
+ 
+<td>
+te
+<td>
+
+It should be allowed to
+define constexpr recursively.
+There is an explanation in N2235,
+Generalized Constant Expressions—Revision 5, as
+follows.
+ 
+We (still) prohibit recursion in all its form in
+constant expressions. That is not strictly necessary because an
+implementation limit on recursion depth in constant expression
+evaluation would save us from the possibility of the compiler
+recursing forever. However, until we see a convincing use case for
+recursion, we don’t propose to allow it.
+ 
+Then, here are the use cases where
+allowing recursion for constexpr is very useful.
+ 
+Range of problem to be handled with
+constexpr would become extended. For example, user defined type
+(e.g. Complex type) could be placed in ROM area. But with current
+specification, a function defined with constexpr cannot be called
+recursively. As a side effect is not allowed in compile-time, it
+cannot be implemented to repeat anything without recursion.
+Although it could be implemented without recursion like func0,
+func1, func2 in an example below, it is not elegant
+solution.
+ 
+constexpr double func0(double x) { /*
+... */}
+constexpr double func1(double x) { /*
+call for func0 */ }
+constexpr double func2(double x) { /*
+call for func1 */ }
+/* ... */
+ 
+- Compile-time and runtime
+As constexpr can be also evaluated both
+in compile-time and runtime, we need to discuss about both
+cases.
+ 
+Runtime evaluation is just to execute
+it. If you eliminate constexpr keyword, it is executable as of now.
+Any modern compiler may optimize tail recursion easily.
+ 
+Compile-time evaluation is the same
+thing as template recursion. It is necessary to support floating
+point operation, but it is already possible to calculate it in
+compile-time, so it’s ok.
+ 
+- Sample
+Here is an example to calculate a square
+root using constexpr recursively.
+ 
+/*constexpr*/ double SqrtHelper(double
+x, double a, int n)
+{
+return n == 0 ? a : SqrtHelper(x, (x / a
++ a) / 2.0, n - 1);
+}
+ 
+/*constexpr*/ double Sqrt(double
+x)
+{
+return SqrtHelper(x, x, 20);
+}
+ 
+/*constexpr*/ double root2 = Sqrt(2.0); //
+1.41421...
+ 
+<td>
+Allow constexpr recursion.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 37
+<td>
+7.1.6.1
+<td>
+1
+<td>
+ed
+<td>
+There is a "Note: 3.9.3 describes how
+cv-qualifiers affect object and function types." So far as I can
+see, 3.9.3 CV-qualifiers only describes cv-qualifiers for objects,
+cv-qualifiers for (member) functions being described in 8.3.5
+Functions.
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+89
+<td>
+7.1.6.1
+<td>
+2
+<td>
+Te
+<td>
+The two normative sentences in this paragraph
+appear to duplicate text elsewhere - but they aren't exact
+duplicates, which introduces uncertainty. 1. "An object declared in
+namespace scope with a const-qualified type has internal linkage
+unless it is explicitly declared extern or unless it was previously
+declared to have external linkage.". This nearly repeats 7.1.1/7:
+"Objects declared const and not explicitly declared extern have
+internal linkage." The former seems to allow more wiggle room - can
+an object be "previously declared to have external linkage" without
+having been "explicitly declared extern"? 2. "A variable of
+non-volatile const-qualified integral or enumeration type
+initialized by an integral constant expression can be used in
+integral constant expressions (5.19)." This nearly duplicates
+5.19/2, bullet 4, 1st sub-bullet - "[... an integaral constant
+expression can use] an lvalue of effective integral type that
+refers to a non-volatile const variable or static data member
+initialized with constant expressions". The latter does not allow
+for lvalues of enumeration type (neither scoped not unscoped
+enumerations are integral types - 3.9.1/7, and note 44). This seems
+to be a flaw in 5.19/2.
+ 
+<td>
+Make the
+normative text in this section into one or more notes, with cross
+references, and correct the referenced text if necessary.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+90
+<td>
+7.1.6.2
+<td>
+para 1 and
+table 9
+<td>
+Ed
+<td>
+The grammar in paragraph one makes
+"nested-name-specifier template simple-template-id" a
+simple-type-specifier, but unlike all the others it is omitted from
+table 9.
+ 
+<td>
+Add a row to
+table 9 mentioning simple-template-id and punting to clause 14 (cf
+decltype(expression)).
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+91
+<td>
+7.1.6.2
+<td>
+4
+<td>
+Te
+<td>
+5.1/5 says "[A] parenthesized expression can be
+used in exactly the same contexts as those where the enclosed
+expression can be used, and with the same meaning, except as
+otherwise indicated." When the first bullet point of this
+paragraph, describing the type denoted by decltype(e), says "if e
+is an id-expression ... decltype(e) is the type of the entity named
+by e", 5.1/5 is not excluded, which would imply that decltype((e))
+was also the type of e. But the intention appears that it should be
+caught by the third bullet and treated as an lvalue expression, so
+decltype((e)) should be a reference to the type of e. Conversely,
+the second bullet point says "(parentheses around e are ignored)",
+which is redundant because of 5.1/5.
+ 
+<td>
+Insert
+"unparenthised" in the first bullet point - "if e is an
+*unparenthised* id-expression ...". In the second bullet point,
+move "(parentheses around e are ignored)" into a note.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+92
+<td>
+7.1.6.3
+<td>
+2
+<td>
+Ed
+<td>
+The note correctly indicates that, if T is a
+template type parameter, then "friend class T;" is ill-formed. It
+might be worth pointing out at the same time that the alternative
+"friend T;" is now allowed - see 11.4/3.
+ 
+<td>
+Either strike
+the note or add reference to 11.4/3 and/or mention of "friend
+T;".
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+93
+<td>
+7.1.6.3
+<td>
+Grammar
+before para 1
+<td>
+Ed
+<td>
+In the third production, "enum ::opt
+nested-name-specifieropt identifier", enum should not be in
+italics; its referring to the enum keyword.
+ 
+<td>
+Change to
+keyword font
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+94
+<td>
+7.1.6.4
+<td>
+1
+<td>
+Ed
+<td>
+The auto
+type-specifier signifies that the type of an object being declared
+shall be deduced from its initializer or specified explicitly at
+the end of a function declarator. A function declarator does not
+declare an object.
+<td>
+The auto type-specifier signifies that the type of
+an object being declared shall be deduced from its initializer or
+that the return type of a function is specified explicitly at the
+end of a function declarator.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+95
+<td>
+7.1.6.4
+<td>
+4
+<td>
+Te
+<td>
+(See also c++std-core-13583) This paragraph allows
+auto "in the type-specifier-seq in a new-type-id (5.3.4)" (and
+nowhere else not listed). Specifically, it isn't allowed in a
+type-id in a new-expression. That allows "new auto (42)", but not
+"new (auto)(42)". However, 5.3.4/2 suggests the latter should be
+allowed "If the auto type-specifier appears in the
+type-specifier-seq of a new-type-id or type-id of a new-expression
+...". The inconsistency should be resolved, ideally in favour of
+allowing both forms.
+ 
+<td>
+Change "in a
+new-type-id" to "in a new-type-id or type-id in a
+new-expression".
+<td>
+ 
+<tr valign="top">
+<td>
+FR 24
+<td>
+7.1.6.4 [auto
+specifier]
+<td>
+ 
+<td>
+te
+<td>
+Now that 'auto' is finally used in its
+most obvious sense to state `deduce the type of this variable from
+initializer', it should also be allowed in template parameter
+declarations, as in
+ 
+template<auto n> struct X { /*
+… */ };
+ 
+X<903> x;
+ 
+X<&Widget::callback> y;
+ 
+instead of the current, often verbose and
+cumbersome
+ 
+template<typename T, T n> struct X { /*
+… */ };
+ 
+X<int,903> x;
+X<void
+(Widget::*)(),&Widget::callback> y;
+ 
+We understand that 'auto' is used in
+14.1/18 in a different way (for constrained template), but that
+usable appears very strange syntax, unnatural and does not fit well
+with the usage in this section.
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 38
+<td>
+7.2
+<td>
+1
+<td>
+ed
+<td>
+The discussion of attribute specifiers
+should be a separate paragraph.
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 39
+<td>
+7.2
+<td>
+2
+<td>
+te
+<td>
+The paragraph says in part "An
+opaque-enum-declaration declaring an unscoped enumeration shall not
+omit the enum-base." This statement implies that the base may be
+omitted for scoped enumerations, which is somewhat inconsistent
+with paragraph 3 and somewhat consistent with paragraph 5.
+ 
+<td>
+As this implication leaves no representation, it
+should be either affirmed here or the statement should be expanded.
+Perhaps a note is warranted.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 13
+<td>
+7.2
+<td>
+paragraph 3
+<td>
+ed
+<td>
+In the description for an unscoped
+enumeration, enum-base in redeclaration must be the same underlying
+type as in the 1st declaration, but it is not described explicitly,
+while it is referred that all enum-bases in redeclarations must
+specify the same underlying type.
+ 
+<td>
+Replace the description,
+"same underlying type", with "same as underlying type of (previous)
+declaration."
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+96
+<td>
+7.2
+<td>
+7
+<td>
+Te
+<td>
+enum E { }; What are the values of E? It has
+neither a smallest nor largest enumerator, so paragraph 7 doesn't
+help. (Paragraph 6 indicates that the underlying type is as if E
+had a single enumerator with value 0, but that does not define the
+values of E.)
+ 
+<td>
+Add a second
+sentence to paragraph 7 (before "Otherwise"): "If the
+enumerator-list is empty, 0 is the only value of the
+enumeration."
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+97
+<td>
+7.2
+<td>
+9
+<td>
+Ed
+<td>
+Missing punctuation after "blue" in: "The possible
+values of an object of type color are red, yellow, green, blue
+these values can be converted ..."
+ 
+<td>
+Add a
+semicolon: "The possible values of an object of type color are red,
+yellow, green, blue; these values can be converted ..."
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+98
+<td>
+7.2
+<td>
+5
+<td>
+Te
+<td>
+It would be useful to be able to determine the
+underlying type of an arbitrary enumeration type. This would allow
+safe casting to an integral type (especially needed for scoped
+enums, which do not promote), and would allow use of
+numeric_limits. In general it makes generic programming with
+enumerations easier.
+ 
+<td>
+Add a
+TransformationTrait to 20.5.6 that returns the underlying type of
+an enumeration type.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+99
+<td>
+7.2
+<td>
+3
+<td>
+Te
+<td>
+It is unclear whether an enumeration type is
+complete after an opaque-enum-declaration. This paragraph only says
+so in a note, and the general rule in 3.9/5 ("Incompletely-defined
+object types ... are incomplete types") is unclear in this
+situation.
+ 
+<td>
+Move "an
+enumeration declared by an opaque-enum-declaration ... is a
+complete type" from the note to normative text.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 14
+<td>
+7.3.1
+<td>
+ 
+<td>
+te
+<td>
+
+The description of the
+behavior when a member that was defined with same name in other
+namespace was referred.
+
+- It seems that the behavior
+of the following case is not defined. So we think that it is
+necessary to define that.
+namespace Q {
+inline namespace V {
+int g;
+}
+int g;
+}
+Q::g =1;// ill-fromed, Q::V::g =1;, or Q::g =
+1;?
+
+- Add that the following case
+is ill-formed to more easily to understand.
+namespace Q {
+inline namespace V1{
+int g;
+}
+inline namespace V2{
+int g;
+}
+}
+Q::g =1;//ill-formed
+ 
+<td>
+
+Add the description of the
+behavior when a member that was defined with same name in other
+namespace was referred.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+100
+<td>
+7.3.3
+<td>
+10 and
+13
+<td>
+Ed
+<td>
+Para 10 says "A using-declaration is a declaration
+and can therefore be used repeatedly where (and only where)
+multiple declarations are allowed." Para 13 says "Since a
+using-declaration is a declaration, the restrictions on
+declarations of the same name in the same declarative region (3.3)
+also apply to using-declarations." These appear to be saying
+exactly the same thing.
+ 
+<td>
+Delete para
+10, moving its example into para 13.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+101
+<td>
+7.3.3
+<td>
+20
+<td>
+Te
+<td>
+If a using-declaration uses the keyword typename
+and specifies a dependent name (14.6.2), the name introduced by the
+using-declaration is treated as a typedef-name (7.1.3). That
+doesn't specify at all what the effect of using typename with a
+non-dependent name is. Is it allowed? What about outside any
+template? What if the name isn't a type? (14.6/4 doesn't cover
+this, I think.)
+ 
+<td>
+Allow
+typename for non-dependent names iff they refer to a type.
+<td>
+ 
+<tr valign="top">
+<td>
+DE-12
+<td>
+7.3.3
+<td>
+p15
+<td>
+te
+<td>
+
+DE-12 Overriding and hiding
+of member functions named in using-declarations should consider
+ref-qualifiers, because they are part of the function type.
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+FR 25
+<td>
+7.3.3 [The using
+declaration]
+<td>
+Paragraph 21
+<td>
+te
+<td>
+The syntax for concept map alias is
+unnecessarily both confused and verbose.
+<td>
+We strongly suggest simplifications,
+e.g.
+using N1::C<int>;
+that fits well with existing constructs.
+The syntactic complexity is too high for a new feature presumably
+designed to support sound programming.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+102
+<td>
+7.3.4
+<td>
+6
+<td>
+Ed
+<td>
+This paragraph says "If name lookup finds a
+declaration for a name in two different namespaces, and the
+declarations do not declare the same entity and do not declare
+functions, the use of the name is ill-formed." But the example uses
+declaration of functions, so is not covered by this
+paragraph.
+ 
+<td>
+Move the
+example to paragraph 7, and/or replace it with an appropriate
+example.
+<td>
+ 
+<tr valign="top">
+<td>
+US 40
+<td>
+7.6
+<td>
+ 
+<td>
+te
+<td>
+The list of attributes is missing an attribute to
+indicate that a function with a <code>throw()</code>
+(throws nothing) clause need
+not have the <code>unexpected()</code> catch clause generated. This attribute was a
+motivating example for the attribute syntax, and its omission is
+surprising.
+ 
+<td>
+Add the attribute.
+<td>
+ 
+<tr valign="top">
+<td>
+US 41
+<td>
+7.6
+<td>
+ 
+<td>
+te
+<td>
+A common problem is unintentionally
+declaring a new virtual member function instead of overriding a
+base virtual member function.
+ 
+<td>
+An attribute stating intent to override would
+enable better diagnostics.
+<td>
+ 
+<tr valign="top">
+<td>
+FR 26
+<td>
+7.6 [Attributes]
+<td>
+ 
+<td>
+ed
+<td>
+Are they part of object types or not? The
+section does not appear to indicate that clearly.
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+FI 1
+<td>
+7.6
+<td>
+ 
+<td>
+te
+<td>
+Add override-attribute for
+functions in order to avoid mistakes when overriding
+functions.
+<td>
+See
+override-attribute.doc, override-attribute.ppt
+<td>
+ 
+<tr valign="top">
+<td>
+FR 27
+<td>
+7.6.1
+<td>
+ 
+<td>
+te
+<td>
+This section specifies that no name lookup
+is performed on any identifier contained in an attribute-token.
+This in particular implies that, for example, it is impossible to
+define a template class parameterized by its alignment. That
+restriction is unacceptable.
+The original alignment proposal made that
+useful construct possible.
+Furthermore paragraph 7.6.1/2 appears
+contradictory with the rest of that section -- since no name lookup
+is performed, how a 'type-id'is determined?
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+103
+<td>
+7.6.1
+<td>
+ 
+<td>
+Te
+<td>
+Attributes
+should support pack expansion. For example, this would be extremely
+useful with the align attribute, directly supporting the (removed)
+functionality of aligned_union. NOte that aligned_union was removed
+as varaiant-unions were considered a complete replacement - however
+this is not true for variadic templates. Adding this support to
+attributes would remove the remaining need, and support similar
+attributes in the future.
+<td>
+Add:
+attribute... to the grammar for attribute-list Add to list in
+14.5.3p4: "In an attribute-list(7.6.1); the pattern is an
+attribute."
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+104
+<td>
+7.6.1
+<td>
+1
+<td>
+Ed
+<td>
+It is helpful for each subclause to contain a
+short paragraph introducing its intent an purpose. 7.6 has such a
+paragraph, but it is nested under a more specific
+subsection.
+ 
+<td>
+7.6.1p1
+should move up one level to become 7.6p1. There grammar should
+remain under 7.6.1
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+105
+<td>
+7.6.1
+<td>
+1
+<td>
+Te
+<td>
+Allowing only
+one level of namespaces in attributes seems unnecessarily
+limiting.
+<td>
+To:
+attribute-scoped-token: attribute-namespace :: identifier add
+attribute-namespace :: attribute-scoped-token
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+106
+<td>
+7.6.2
+<td>
+1
+<td>
+Ed
+<td>
+Extensive use of alignment and related terms
+without cross reference.
+ 
+<td>
+Add
+cross-reference to 3.11.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 15
+<td>
+7.6.2
+<td>
+ 
+<td>
+ed
+<td>
+
+An abbreviation of 7.6.2
+should be “[decl.attr.align]” instead of
+“[dcl.align]”. 
+Section name “[dcl.align]” is not consistent with
+others, because others in 7.6 are the form of
+“dcl.attr.*”. In N2761, the section name of 7.1.7 had
+been changed from “[dcl.align]” to
+“[dcl.attr.align]”, but in N2800 it was reverted to
+“[dcl.align]” along with a change of section number,
+7.1.7 to 7.6.2.
+ 
+<td>
+Change "[dcl.align]" of
+7.6.2 to "[decl.attr.align]".
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+107
+<td>
+7.6.3
+<td>
+ 
+<td>
+Ed
+<td>
+While undefined behaviour might be the best we can
+guarantee, it would be helpful to encourage implementations to
+diagnose function definitions that might execute a return.
+ 
+<td>
+Adda a [Note
+: implementations are encouraged to issue a diagnostic where the
+definition of a function marked [[noreturn]] might execute a return
+statement -- end note]
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+108
+<td>
+7.6.4
+<td>
+2
+<td>
+Te
+<td>
+It is unclear why no diagnostic is required for an
+easily detectable violation. It is even more surprising that the
+associated footnote mandates behaviour for an ill-formed
+program.
+ 
+<td>
+Strike "no
+diagnostic required" and the associated footnote.
+<td>
+ 
+<tr valign="top">
+<td>
+US 42
+<td>
+7.6.4
+<td>
+ 
+<td>
+te
+<td>
+The meaning of the <code>[[final]]</code> attribute applied to classes is inconsistent with
+other languages and not desirable in its own right.
+ 
+<td>
+Modify the semantics of <code>[[final]]</code> applied to classes. See the attached paper "Issues
+with the C++ Standard" under Chapter 7 "Meaning of
+<code>[[final]]</code> attribute applied to classes".
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+109
+<td>
+7.6.5
+<td>
+4
+<td>
+Ed
+<td>
+The example code refers in comments to
+"Compilation unit" A and B. The term should be "Translation unit"
+(2/1)
+ 
+<td>
+Replace
+"Compilation" with "Translation" in two places
+<td>
+ 
+<tr valign="top">
+<td>
+ 
+<td>
+ 
+<td>
+ 
+<td>
+ 
+<td>
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+110
+<td>
+7.6.5
+<td>
+4
+<td>
+Te
+<td>
+The code in the example (compilation unit A) has:
+"foo_head[i].load(memory_order_consume)". foo_head[i] is of type
+foo *, so it does not have a load member.
+ 
+<td>
+Change the
+type of foo_head to atomic<foo *>[].
+<td>
+ 
+<tr valign="top">
+<td>
+US 43
+<td>
+8
+<td>
+ 
+<td>
+te
+<td>
+With the introduction of late-specified return
+types for functions and lambda expressions, we now have three
+different syntaxes for declaring functions. The
+<code>-></code> late declaration is used in two. The
+<code>auto</code> keyword is used in one, but also used differently
+in variable definitions.
+ 
+<td>
+Some simplification is needed.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+111
+<td>
+8.3.5
+<td>
+13
+<td>
+Ed
+<td>
+Example missing closing bracket in
+template<typename... T> void f(T (* ...t)(int, int);
+ 
+<td>
+Add closing
+bracket like this: template<typename... T> void f(T (*
+...t)(int, int));
+<td>
+ 
+<tr valign="top">
+<td>
+US 44
+<td>
+8.3.5
+<td>
+13
+<td>
+ed
+<td>
+In the Example, "template void f(T (*
+...t)(int, int);" is missing a close parenthesis.
+ 
+<td>
+It presumably should read: "template void f(T (*
+...t))(int, int);".
+<td>
+ 
+<tr valign="top">
+<td>
+US 45
+<td>
+8.3.5
+<td>
+13
+<td>
+te
+<td>
+At present, function
+parameter packs can only occur at the end of a
+parameter-declaration-list. This restriction unnecessarily
+prohibits uses of function parameter packs in cases where template
+argument deduction isn’t needed, e.g.,
+ 
+template<class...
+T> struct X { };
+template<class... T1,
+class... T2>
+struct X<pair<T1,
+T2>...> {
+void f(T1...,
+T2...);
+};
+ 
+More importantly, this
+restriction is inconsistent with the way pack expansions are
+handled. For example, this template is well-formed (but X<T...,
+int> is a non-deduced context):
+ 
+template<class...
+T> void f(X<T..., int>);
+ 
+Therefore, the restriction that limits function
+parameter packs to the end of the parameter-declaration-list should
+be removed. Instead, function parameter packs not at the end of the
+parameter-declaration-list should be considered non-deduced
+contexts.
+<td>
+In 8.3.5p13, remove the sentence
+“A function parameter pack, if
+present, shall occur at the end of the
+parameter-declaration-list.”
+ 
+In 14.8.2.1p1, replace the phrase
+“For a function parameter pack” with “For a
+function parameter pack that occurs at the end of a
+parameter-declaration-list”.
+ 
+Replace the note text “A
+function parameter pack can only occur at the end of a
+parameter-declaration-list (8.3.5).” with
+“A function parameter pack that does not occur at the end of
+a parameter-declaration-list is a non-deduced
+context.”
+ 
+In 14.8.2.5p5, add a new
+bullet: “A function parameter pack that does not occur at the
+end of its parameter-declaration-list.”
+ 
+In 14.8.2.5p10, replace
+“If the
+parameter-declaration corresponding to Pi is a function parameter
+pack” with “If the parameter-declaration corresponding to Pi
+is a function parameter pack and Pi occurs at the end of the
+parameter-declaration-list”.
+ 
+Replace the note
+text “A function parameter pack can only occur at the end of
+a parameter-declaration-list (8.3.5).” with
+“A function parameter pack that does not occur at the end of
+a parameter-declaration-list is a non-deduced
+context.”
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+DE-13
+<td>
+8.4
+<td>
+p2
+<td>
+te
+<td>
+DE-13 The second
+paragraph, quoting the grammar for the declarator of a function
+declaration, is not considering late-specified return types and
+attributes.
+<td>
+Properly quote the grammar
+from 8.3.5.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 16
+<td>
+8.5
+<td>
+15th paragraph, 1st line
+ 
+<td>
+ed
+<td>
+Typo, duplicated "in"
+"The initialization that occurs in in the
+forms"
+<td>
+Remove one.
+<td>
+ 
+<tr valign="top">
+<td>
+US 46
+<td>
+8.5.3
+<td>
+ 
+<td>
+te
+<td>
+The ability for an rvalue
+reference to bind to an lvalue opens a type-safety hole that
+becomes very dangerous with concepts. For example, consider
+vector’s push_back operation:
+requires
+MoveConstructible<T> void push_back(T&&);
+requires
+CopyConstructible<T> void push_back(const T&);
+ 
+For a copy-constructible
+T (which is also move-constructible), push_back does the right
+thing. However, if T is something that is move-constructible (e.g.,
+unique_ptr<int>), the second overload is removed from
+considered (it is effectively SFINAE’d away), so only the
+first overload remains. Therefore, one could accidentally call
+push_back with an lvalue of type T, and push_back would silently
+move from the lvalue. The same problem occurs without concepts
+(albeit less frequently).
+ 
+ 
+<td>
+Prohibit rvalue
+references from binding to lvalues.
+ 
+Unfortunately this change
+will break some current use cases of rvalue reference including the
+use of rvalue streams, and of the forward function itself. To
+resolve this we may want to consider three types of
+references:
+ 
+<ol>
+<li>
+The current
+reference.
+<li>
+A non-const reference
+that only binds to rvalues.
+<li>
+A non-const reference
+that will bind to both lvalues and rvalues.</ol>
+ 
+Still another solution would be to adopt the
+“deleted function” solution for all functions. This
+solution is described in comment for 12.1, 12.4, 12.8, but
+restricted to special functions in that comment. (See US
+NN).
+<td>
+ 
+<tr valign="top">
+<td>
+US 49
+<td>
+8.5.4
+<td>
+6
+<td>
+ed
+<td>
+In the Example, the comments could be
+improved.
+<td>
+See the attached paper "Issues with the
+C++ Standard" under "Editorial Issues" and "8.5.4/6".
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+112
+<td>
+9
+<td>
+4-9
+<td>
+Ge
+<td>
+We now have concepts that should (or should not?)
+map to the terms described in Clause 9 - these should be at least
+referenced.
+ 
+<td>
+Add
+appropriate forward references to 14.9.4
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+113
+<td>
+9.4.2
+<td>
+3
+<td>
+Ed
+<td>
+Mis-applied
+edit from the paper n2756
+<td>
+The term
+'constant-initializer' should have been struck out when replaced by
+brace-or-equal-initializer. There are two occurrences in this
+paragraph
+<td>
+ 
+<tr valign="top">
+<td>
+US 50
+<td>
+12.1, 12.4, 12.8
+<td>
+ 
+<td>
+te
+<td>
+Implicitly-declared
+default constructors, destructors, copy constructors, and copy
+assignment operators are deleted when their definitions would be
+ill-formed. However, unlike with overloading and template argument
+deduction, access control is performed as part of the check for
+making one of these special function deleted. This inconsistency
+should be removed.
+ 
+This change would
+sacrifice some backward compatibility in favor of consistency. With
+the current wording, checking that the following class
+‘A’ is CopyConstructible would proceed without error
+(it is not CopyConstructible):
+class A { A(const
+A&); };
+With the proposed change,
+testing whether A is CopyConstructible would produce a diagnostic.
+To fix the problem, the user would have to use a deleted
+function:
+class A { A(const A&)
+= delete; };
+ 
+<td>
+In 12.1p5, remove the phrase
+“or inaccessible from the
+implicitly-declared default constructor”.
+ 
+In 12.4p3, remove the phrase
+“or a destructor that is
+inaccessible from the implicitly-declared destructor,” and
+the phrase “or a destructor that is inaccessible from
+the implicitly-declared
+destructor”.
+ 
+In 12.8p5, remove the phrase
+“or inaccessible from the
+implicitly-declared copy constructor” from the two places it
+occurs.
+ 
+In 12.8p10, remove the phrase
+“or inaccessible from the
+implicitly-declared copy assignment operator” from the two
+places it occurs.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+FR 28
+<td>
+12.6.1 [Explicit initialization]
+ 
+<td>
+ 
+<td>
+te
+<td>
+This section, in particular the example with
+`g' appears contradictory with the syntax for uniform
+initialization.
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 51
+<td>
+12.6.2
+<td>
+2
+<td>
+ed
+<td>
+The discussion of delegating
+constructors should be in its own paragraph.
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+114
+<td>
+12.6.2
+<td>
+1
+<td>
+Te
+<td>
+Despite all
+the attempts to unify initialization syntax, it is still not
+possible to copy-initialize base classes or non-static data
+members, which means the explicit keyword cannot have a bearing
+during evaluation of a constructor. A minimal addition to the
+grammar, allowing an optional = between the mem-initializer-id and
+braced-init-list would allow the user to choose between copy and
+direct initialization
+<td>
+Ammend the grammar for mem-initializer:
+mem-initializer-id =OPT braced-init-list Extend p3 to allow for
+Copy Initialization if the optional = is present: 3 The
+expression-list or braced-init-list in a mem-initializer is used to
+initialize the base class or non-static data member subobject
+denoted by the mem-initializer-id according to the initialization
+rules of 8.5 for direct-initialization, OR COPY-INITIALIZATION IF
+THE OPTIONAL = IS PRESENT BETWEEN THE MEM-INITIALIZER-ID and the
+BRACED-INIT-LIST. [Example:...
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 52
+<td>
+13.5.8
+<td>
+¶ 5
+<td>
+ed
+<td>
+A word is
+misspelled.
+<td>
+Change “shal”
+to “shall”.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+115
+<td>
+14
+<td>
+6-11
+<td>
+Ge
+<td>
+Exported templates were a great idea that is
+generally understood to have failed. In the decade since the
+standard was adopted, only one implementation has appeared. No
+current vendors appear interested in creating another. We
+tentatively suggest this makes the feature ripe for deprecation.
+Our main concern with deprecation is that it might turn out that
+exported constrained templates become an important compile-time
+optimization, as the constraints would be checked once in the
+exported definition and not in each translation unit consuming the
+exported declarations.
+ 
+<td>
+Consider
+deprecating exported templates, but no action yet. Examine
+interaction with constrained templates, and see if other more
+appropriate mechanism will support compile-time
+optimization.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+116
+<td>
+14
+<td>
+6-11
+<td>
+Te
+<td>
+Is it possible to export a concept map template?
+The current wording suggests it is possible, but it is not entirely
+clear what it would mean.
+ 
+<td>
+Either
+prohibit exporting concept map templates, or more directly address
+what it means to export a concept map.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+117
+<td>
+14
+<td>
+2
+<td>
+Ge
+<td>
+It would be nice to allow template alias within a
+function scope, and possibly a scoped concept map. As these affect
+name lookup and resolution, rather than defining new callable code,
+they are not seen to present the same problems that prevented class
+and function templates in the past.
+ 
+<td>
+Allow
+template aliases to be declared inside a function scope, and
+consider scoped concept maps.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+118
+<td>
+14
+<td>
+6-11
+<td>
+Ed
+<td>
+Exported templates are a complicated feature with
+surprisingly little text. To make this important text more visible,
+split it off into its own subclause [temp.export]
+ 
+<td>
+Create a new
+subclause [temp.export] containing 14p6-11. Move 14p12 ahead of
+this subclause.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+119
+<td>
+14
+<td>
+4
+<td>
+Te
+<td>
+Does a concept map have linkage? Reading this
+paragraph and 3.5 suggests a concept map template has external
+linkage, but not a 'regular' concept map. Believe this is an
+oversight that the linkage words were not updated to provide an
+exception, rather than linkage of concept maps is intended.
+ 
+<td>
+Add an
+exception that concept map templates have no linkage, or add
+concept maps to the list of entities with linkage in 3.5
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+120
+<td>
+14.1
+<td>
+9
+<td>
+Ed
+<td>
+As this is the first time the phrase
+“parameter pack” appears in Ch 14 I would like to see
+the section 8.3.5 referenced here (as well as in 14.1p17).
+ 
+<td>
+Insert
+“(8.3.5)” after “parameter pack”
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+121
+<td>
+14.1
+<td>
+18
+<td>
+Ed
+<td>
+The example (that follows the normative text) has
+no begin example marker
+ 
+<td>
+Prefix the
+example code with "[ Example:"
+<td>
+ 
+<tr valign="top">
+<td>
+FR 29
+<td>
+14.3 [Template arguments]
+ 
+<td>
+ 
+<td>
+te
+<td>
+Constant expressions of any literal type should
+be allowed as template arguments.
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 53
+<td>
+14.5.1
+<td>
+5
+<td>
+te
+<td>
+If the requirements of a constrained member
+that is a copy constructor, copy assignment operator, or destructor
+are not satisfied, then that user-declared special function will
+not exist. It appears that, in this case, the special function will
+then be implicitly defined, which is likely
+to either (a) fail to compile or (b) produce a function with the
+wrong semantics. For example:
+template<ObjectType
+T> class vector {
+T* first, last,
+end;
+public:
+requires
+CopyConstructible<T> vector(const vector&);
+};
+ 
+If instantiated with a type that is not
+CopyConstructible, vector will get an implicitly-defined copy
+constructor that performs a copy of the pointers.
+<td>
+Add to 14.5.1p5:
+If the constrained member is a copy constructor
+(12.8), destructor (12.4), or copy assignment operator and its
+template requirements are not satisfied, then a copy constructor,
+destructor, or copy assignment operator, respectively, with the
+same signature as the constrained member (after substituting the
+class template’s template arguments for its template
+parameters) will be declared as a deleted function (8.4).
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+122
+<td>
+14.5.3
+<td>
+4
+<td>
+Te
+<td>
+Variadic templates should be supported in axioms.
+There are axioms in the library that rely on this feature, such as
+the FrontEmplacement axiom in FrontEmplacementContainer
+(23.1.6.1p10)
+ 
+<td>
+Add
+clarification in p2 that function parameter packs can be used to
+declare axioms, much like p1 clarifies they can be used to declare
+concepts as well as templates.
+<td>
+ 
+<tr valign="top">
+<td>
+FR 30
+<td>
+14.5.7 [Template aliases]
+<td>
+ 
+<td>
+te
+<td>
+When are two template alias names
+equivalent?
+ 
+E.g. given
+template<template<class>
+class> struct X { };
+ 
+template<typename,typename> struct Y
+{ };
+ 
+template<typename T>
+using Z1 = Y<int,T>;
+ 
+template<typename T>
+using Z2 = Y<int,T>;
+ 
+Are the types X<Z1> and X<Z2>
+equivalent?
+We would suggest yes (since Z1<T>
+and Z2<T> are the same for all T), but we do not see any
+wording to that effect.
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 17
+<td>
+14.7.2
+<td>
+2nd paragraph, 15th line
+<td>
+ed
+<td>
+Typo.
+if that namespace is inline, any
+namespace from its enclosing namespace set.
+ 
+should be
+ 
+if that namespace is inline, any namespace
+forming its
+enclosing namespace set.
+ 
+<td>
+Replace "from" with
+"forming"
+<td>
+ 
+<tr valign="top">
+<td>
+DE-14
+<td>
+14.7.3
+<td>
+p1
+<td>
+te
+<td>
+DE-14 The bulleted list
+neither addresses "member function template of a class" nor "member
+class template of a class".
+<td>
+Add the respective
+bullets.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 18
+<td>
+14.7.3
+<td>
+2nd paragraph, 2nd line
+<td>
+ed
+<td>
+Typo,
+any namespace from its enclosing
+namespace set
+ 
+should be
+ 
+any namespace forming its enclosing namespace set
+ 
+<td>
+Replace "from" with
+"forming"
+<td>
+ 
+<tr valign="top">
+<td>
+JP 19
+<td>
+14.8.2
+<td>
+6th paragraph, 1st line
+<td>
+ed
+<td>
+Typo, duplicated "is"
+"At certain points in the template argument
+deduction process it is is necessary"
+ 
+<td>
+Remove one
+<td>
+ 
+<tr valign="top">
+<td>
+US 54
+<td>
+
+14.9 [concept],
+14.10
+[temp.constrained]
+<td>
+ 
+<td>
+ge
+<td>
+Concepts is of course the
+largest new feature in C++0x (in terms of new text inserted into
+the wording), and already we have found some significant defects
+with it. So far nothing devastating has been found, but more time
+is needed to shake more bugs out.
+<td>
+I propose no specific
+change here.
+<td>
+ 
+<tr valign="top">
+<td>
+US 55
+<td>
+14.9.1
+<td>
+¶ 6
+<td>
+ed
+<td>
+The paragraph number is in
+the wrong place, causing a grammar rule to be indented more than
+its fellows.
+<td>
+Move the paragraph number
+so as to follow the grammar rules, thus numbering the single
+sentence, “The body of a concept … .”
+<td>
+ 
+<tr valign="top">
+<td>
+US 56
+<td>
+14.9.1
+<td>
+¶ 6
+<td>
+ed
+<td>
+The sentence contains two
+references to 14.9.1.3 [concept.req].
+<td>
+Change the second such
+reference (at the end of the sentence) to 14.9.1.4
+[concept.axiom].
+<td>
+ 
+<tr valign="top">
+<td>
+US 57
+<td>
+14.9.1.4
+<td>
+¶ 3
+<td>
+ed
+<td>
+A word is misplaced,
+changing the intended meaning.
+<td>
+Change “only find
+… if” to “find … only if”.
+<td>
+ 
+<tr valign="top">
+<td>
+US 58
+<td>
+14.9.1.4
+<td>
+¶ 3
+<td>
+ed
+<td>
+The listed phrases are not
+grammatically parallel.
+<td>
+Insert “in”
+before “one” so as to obtain “... in the concept,
+in one of its less refined concepts, or in an associated
+requirement.”
+<td>
+ 
+<tr valign="top">
+<td>
+US 59
+<td>
+14.9.1.4
+<td>
+ 
+<td>
+te
+<td>
+Axioms are under-specified and provide little
+benefit to programmers, so they should be removed from the working
+paper. The optimizations permitted by axioms (see 14.9.1.4p4-5) are
+not compulsory (and, therefore, programmers cannot rely on them)
+and the semantics expressed by axioms cannot be verified by any
+implementation. The resulting specification has lead to great
+confusion (see the reflector thread “Are floating point types
+Regular?” starting with c++std-lib-22717). Given the level of
+confusion and the inability to verify the correctness of axioms, it
+is likely that many axioms written by programmers (including those
+specified in the candidate draft) will be incorrect.
+<td>
+Remove clause 14.9.1.4
+[concept.axiom]
+In 2.11p1, remove
+“axiom” from the list of keywords.
+ 
+In 14.5.8p7, remove
+“, or if the resulting concept map fails to satisfy the
+axioms of the corresponding concept”
+ 
+In 14.9.1p6, remove
+axiom-definition from the list of grammar productions for
+concept-member-specifier. Remove “, and axioms” from
+the final sentence, and instead “and” prior to
+“associated requirements” in the final sentence.
+ 
+ 
+Remove paragraph 14 of
+clause 14.9.2.
+ 
+In 14.10.1p6, remove the sentence, “When
+the concept-instance-alias-def appears in the optional
+requires-clause of an axiom-definition (14.9.1.4), the potential
+scope of the identifier begins at its point of declaration and
+terminates at the end of the
+axiom-deﬁnition.”
+ 
+In clauses 20.2.5, 20.2.8, 23.1.6.1, 23.1.6.2,
+and 24.1.4, remove the axiom-definitions and replace them with
+paragraphs (denoted Requires, Postconditions, or Effects, as
+appropriate) that express the intended semantics of the concepts
+from which the axiom-definitions were removed.
+ 
+In 24.1.4p2, replace the
+word “axiom” with “condition.”
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+FR 31
+<td>
+14.9.1.4 [Axioms]
+<td>
+ 
+<td>
+te
+<td>
+This section states that an
+axiom-definition defines a new semantics axiom but is unusually
+vague as to what those semantics might be.
+ 
+The use of the '==' and '!=' with
+completely new semantics, unrelated to anything we have seen before
+in C++ is both unwise and confusing, especially if the types
+involved in the expressions happen to have operator== and
+operator!= defined.
+We strongly suggest use
+of different tokens, e.g. , and opposed to
+this obscure usage/overload.
+The description is very vague. How many
+times is an implementation permitted to replace one expression by
+another one when they have side effects?
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+DE-15
+<td>
+14.9.1.4
+<td>
+ 
+<td>
+te
+<td>
+DE-15 There is no
+implementation experience for axioms. Use of axioms is an area of
+active scientific research. It is likely that syntax changes will
+become necessary to make good use of axioms; having the syntax
+space already crowded is unhelpful. Axioms ought to be useful in
+concepts applicable to floating-point types (such as
+EqualityComparable), but IEEE floating-point types have special
+values such as NaN violating the axioms.
+<td>
+Remove section 14.9.1.4
+and any reference to axioms in the rest of the proposed standard
+other than the keyword reservation in section 2.11.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+123
+<td>
+14.9.1.4
+<td>
+ 
+<td>
+Te
+<td>
+auto concepts and axioms are incompatible. An
+axiom defines the semantics of an operaton or set of operations
+that describes the run time behaviour. A concept describes purely
+syntactic requirements at compile time. Where an auto concept will
+match anything that meets the syntax requirements, there is no way
+to know if the axioms will be met or not, and no way to opt out via
+some kind of negative concept map.
+ 
+<td>
+Add a
+paragraph making axioms ill-formed inside an auto concept.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+124
+ 
+<td>
+14.9.1.4
+<td>
+6
+<td>
+Ed
+<td>
+Spelling
+mistake, double-e in were.
+<td>
+weere ->
+were
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+125
+<td>
+14.9.1.4
+<td>
+2
+<td>
+Te
+<td>
+The implicit equality comparison operator
+available to axioms has no semantic. It is not clear what
+expressing the condition if( a == b ) { conditional-axiom } would
+mean if a and b are not truly EqualityComparable. We suspect the
+intent of the 'implicit defefinition' is to support declaring the
+equivalence of statements, a context where the operator will not
+actually be evaluated.
+ 
+<td>
+Define the
+semantics of the implicitly declared comparison operators, or
+restrict their usage to declaring equivalence between
+statements.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+126
+<td>
+14.9.4
+<td>
+41
+<td>
+Ed
+<td>
+This paragraph contains the only definition of the
+underlying_type member - but it's a note, so not normative.
+ 
+<td>
+Move the
+second sentence to the Requires clause in paragraph 42.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+127
+<td>
+14.9.4
+<td>
+ 
+<td>
+Ed
+<td>
+Provide a diagram clearly showing refinement
+relationship between the different support concepts. Several were
+created during development of this clause and they were very
+helpful.
+ 
+<td>
+Provide the
+diagram.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+128
+<td>
+14.9.4
+<td>
+4
+<td>
+Ed
+<td>
+It is
+surprising for many people that non-copyable move-only types can be
+used with a return statement, and so Returnable does not always
+imply CopyConstructible.
+<td>
+A non-normative note: [Note: 'move only' types
+that are constructible from rvalue references may be Returnable,
+but not CopyConstructible(20.1.8) - end note]
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 20
+<td>
+14.9.4
+<td>
+2nd paragraph
+<td>
+te
+<td>
+
+Trivially copyable type was
+added in “3.9 Types”, so we think that it is necessary
+to add concept to trivially copyable type like
+“TriviallyCopyableType”.
+ 
+<td>
+Add TriviallyCopyableType that is
+trivially copyable type as concept.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+129
+<td>
+14.10.1,
+20.1.2
+<td>
+ 
+<td>
+Te
+<td>
+It should be possible to support boolean constant
+expressions as requirements without resorting to defining the True
+concept in the library. Boolean expressions are very likely to be
+constraints when deadline with non-type template parameters and
+variadic templates, and constraints in these cases should feel just
+as natural as constraints on the type system.
+ 
+<td>
+Remove the
+True concept and library subclause 20.1.2. Provide support in
+14.10.1 for boolean constant expressions as constraints. This may
+involve overloading the true keyword to disambiguate but ideally
+would not.
+<td>
+ 
+<tr valign="top">
+<td>
+US 60
+<td>
+14.10.1
+<td>
+1
+<td>
+te
+<td>
+The use of && as the separator for a
+list of requirements has shown itself to be a serious teachability
+problem. The mental model behind ‘&&’ treats
+concepts as simple predicates, which ignores the role of concepts
+in type-checking templates. The more programmers read into the
+‘&&’ (and especially try to fake || with
+&& and !), the harder it is for them to understand the role
+of concept maps. Simply changing the separator to ‘,’
+would eliminate a significant source of confusion.
+<td>
+Replace
+requirement-list:
+requirement-list ...
+[opt] && requirement
+requirement ...
+[opt]
+ 
+with
+ 
+requirement-list
+requirement-list ...[opt]
+, requirement
+requirement ...
+[opt]
+ 
+In 14.5.4p6, replace the
+first sentence with:
+The instantiation of an
+expansion produces a comma-separated list E1, E2, ..., EN, where N
+is the number of elements in the pack expansion parameters.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+130
+<td>
+15.1
+<td>
+4
+<td>
+Te
+<td>
+With the new crrent_exception API it is possible
+to capture a reference to an exception that will outlive its last
+active handler. That is in conflict with the sentance "When the
+last remaining active handler for the exception exits by any means
+other than throw; the temporary object is destroyed and the
+implementation may deallocate the memory for the temporary
+object;"
+ 
+<td>
+Update
+sentence to allow for exceptions held in excpetion_ptr
+objects.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+131
+<td>
+15.3
+<td>
+3
+<td>
+Te
+<td>
+A handler catching its parameter by
+rvalue-reference is syntactically valid, but will never be
+activated.
+ 
+<td>
+Disallow
+handlers catching by rvalue-reference.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+132
+<td>
+15.3
+<td>
+16
+<td>
+Te
+<td>
+There are obscure cases whrere a copy constructor
+is not usually the best match to copy-initialize an object, e.g. A
+converting constructor template taking arguments by non-const
+reference. A footnote explaining such cases would be helpful, or
+the sentance could be rewritten using copy-initialization instead
+of directly calling a copy constructor.
+ 
+<td>
+Rewite using
+copy-initialization rather than directly invoking the copy
+constructor
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+133
+<td>
+15.4
+<td>
+2
+<td>
+Te
+<td>
+Template aliases have the same semantics as a
+typedef so should also be disallowed
+ 
+<td>
+add "or
+alias-declaration" after "shall not appear in a typedef
+declaration".
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+134
+<td>
+15.4
+<td>
+6
+<td>
+Ed
+<td>
+The sentance "An exception-specification can also
+include the class std::bad_exception (18.7.2.1)." is
+redundant.
+ 
+<td>
+Either strike
+the quoted sentance, or add a note explaining why it is worth
+calling special attention to this class.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+135
+<td>
+15.4
+<td>
+8
+<td>
+Te
+<td>
+Unclear if
+std::unexpected is called before or after the function arguments
+have been destroyed
+<td>
+Clarify the
+sequence of calling unexpected with respect to interesting objects,
+such as function arguments or partially constructed bases and
+members when called from a constructor or destructor
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+136
+<td>
+15.4
+<td>
+ 
+<td>
+Ge
+<td>
+Exception
+specifications have proven close to worthless in practice, while
+adding a measurable overhead to programs. The feature should be
+deprecated. The one exception to the rule is the empty throw
+specification which could serve a legitimate optimizing role if the
+requirement to call the runtime unexpected mechanism was relaxed in
+this case.
+<td>
+Move 15.4 and
+the parts of 15.5 that refer to it to Appendix D. Replace 15.4 with
+a simpler specification for empty throw specifications, where the
+std::unexpected call is conditionally supported allowing vendors to
+choose between optimizing and providing runtime checks. Ideally
+require vendors to provide a mode where the runtime checks are
+always disabled.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+137
+<td>
+15.5
+<td>
+ 
+<td>
+Ed
+<td>
+There is no mention of the current_exception API
+which can extend the lifetime of an exception object. There should
+at least be a forward reference to the library clause 18.7.5
+ 
+<td>
+Add another
+paragraph outlining 18.7.5 and the ability of an exception_ptr to
+extend the lifetime of an exception object
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+138
+<td>
+15.5.1
+<td>
+1
+<td>
+Ed
+<td>
+The third bullet is redundant with the first, as
+it is a subset of the same conditions.
+ 
+<td>
+Merge the
+third bullet into the first bullet as a note or example.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+139
+<td>
+15.5.1
+<td>
+1
+<td>
+Te
+<td>
+According to the first bullet it is perfectly
+alright for a library function to exit by throwing an exception
+during stack unwinding, This is clearly not true.
+ 
+<td>
+Strike the
+word 'user' from the first bullet point.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+140
+<td>
+15.5.2
+<td>
+2
+<td>
+Ed
+<td>
+The detailed specification can fool people into
+thinking an exception will automatically be translated into
+bad_exception, where the default behaviour of std::unexcepted is to
+immediately call std::terminate();
+ 
+<td>
+Add a note
+highlighting the default behaviour of std::unexpected if the user
+does not supply a hander-function
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+141
+<td>
+15.6
+<td>
+ 
+<td>
+Ed
+<td>
+This whole subclause is redundant due to 15.1p5
+and 15.3p17
+ 
+<td>
+Strike
+15.6
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+142
+<td>
+16.3.5
+<td>
+3
+<td>
+Ed
+<td>
+This paragraph opens with "[ Note" but has no
+corresponding "end note ]"
+ 
+<td>
+Add "end note
+]"
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+143
+<td>
+16.3.5
+<td>
+7
+<td>
+Ed
+<td>
+Example uses
+#define t(x,y.z) x ## y ## z
+<td>
+Change
+"x,y.z" to "x,y,z"
+<td>
+ 
+<tr valign="top">
+<td>
+US 2
+<td>
+17-30
+<td>
+ 
+<td>
+ge/te
+<td>
+The active issues identified in WG21
+N2806, C++ Standard Library Active Issues, must be addressed and
+appropriate action taken.
+ 
+
+<a href=
+"http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html></a>
+ 
+<td>
+Appropriate action would include making changes to
+the CD, identifying an issue as not requiring a change to the CD,
+or deferring the issue to a later point in time.
+<td>
+ 
+<tr valign="top">
+<td>
+FR 2
+<td>
+General Comment
+<td>
+Library
+<td>
+ge
+<td>
+The adoption of the library `constexpr'
+proposal was not reflected in the draft, despite formal WG21
+committee vote.
+<td>
+FR 2
+<td>
+General Comment
+<tr valign="top">
+<td>
+US 61
+<td>
+17 onward
+<td>
+ 
+<td>
+te
+<td>
+The concepts core language
+feature is applied to only some of the Standard Library clauses,
+and even then not always consistently.
+<td>
+
+Review all clauses of the
+Standard Library, and consistently apply concept technology
+wherever possible and appropriate. The proposed wording in WG21
+N2781 exemplifies the necessary level of detail.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+CA-2
+<td>
+17 Library
+<td>
+ 
+<td>
+Ge
+<td>
+
+“Concepts” are a
+significant new addition to the language, but are not exploited
+uniformly in the library as documented in CD 14882.
+<td>
+Fix the standard library so that
+“Concepts” are used appropriately in the
+library.
+<td>
+ 
+<tr valign="top">
+<td>
+US 62
+<td>
+17-30
+<td>
+ 
+<td>
+ge
+<td>
+Provide concepts and
+requirements clauses for all standard library templates
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 63
+<td>
+17-30
+ 
+<td>
+ 
+<td>
+te
+<td>
+The behavior of the
+library in the presence of threads is incompletely
+specified.
+For example, if thread 1
+assigns to X, then writes data to file f, which is read by thread
+2, and then accesses variable X, is thread 2 guaranteed to be able
+to see the value assigned to X by thread 1? In other words, does
+the write of the data "happen before" the read?
+Another example: does
+simultaneous access using operator at() to different characters in
+the same non-const string really introduce a data race?
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+DE-2
+<td>
+17 through 30
+<td>
+ 
+<td>
+te
+<td>
+DE-2 Marking a constructor
+with "explicit" has semantics even for a constructor with zero or
+several parameters: Such a constructor cannot be used with
+list-initialization in a copy-initialization context, see 13.3.1.7.
+The standard library apparently has not been reviewed for marking
+non-single-parameter constructors as "explicit".
+<td>
+Consider marking
+zero-parameter and multi-parameter constructors "explicit" in
+classes that have at least one constructor marked "explicit" and
+that do not have an initializer-list constructor.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 21
+<td>
+ 
+17 Library
+21.2, 21.4,
+27.2, 27.6, 27.7, 27.8.1, 28.4
+<td>
+ 
+<td>
+te
+<td>
+Support of char16_t/char32_t is
+insufficient. The basic_xxx classes of <iostream>,
+<fstream>, <regex>, etc. does not have typedefs for
+char16_t/char32_t.
+Functions such as stoi, to_string in
+‘21.4 Numeric Conversion’ does not support
+char16_t/char32_t types.
+<td>
+Add commented lines corresponding to char16_t,
+char32_t.
+ 
+21.2 paragraph1
+ 
+namespace std {
+
+ ...
+ 
+
+ // 21.4: numeric
+conversions
+
+ ...
+ 
+
+ int stoi(const
+u16string& str, size_t *idx = 0, int base = 10);
+
+ long stol(const
+u16string& str, size_t *idx = 0, int base = 10);
+
+ unsigned long
+stoul(const u16string& str, size_t *idx = 0, int base =
+10);
+
+ long long stoll(const
+u16string& str, size_t *idx = 0, int base = 10);
+
+ unsigned long long
+stoull(const u16string& str, size_t *idx = 0, int base =
+10);
+
+ float stof(const
+u16string& str, size_t *idx = 0);
+
+ double stod(const
+u16string& str, size_t *idx = 0);
+
+ long double stold(const
+u16string& str, size_t *idx = 0);
+
+ u16string
+to_u16string(long long val);
+
+ u16string
+to_u16string(unsigned long long val);
+
+ u16string
+to_u16string(long double val);
+ 
+ 
+int stoi(const u32string&
+str, size_t *idx = 0, int base = 10);
+
+ long stol(const
+u32string& str, size_t *idx = 0, int base = 10);
+
+ unsigned long
+stoul(const u32string& str, size_t *idx = 0, int base =
+10);
+
+ long long stoll(const
+u32string& str, size_t *idx = 0, int base = 10);
+
+ unsigned long long
+stoull(const u32string& str, size_t *idx = 0, int base =
+10);
+
+ float stof(const
+u32string& str, size_t *idx = 0);
+
+ double stod(const
+u32string& str, size_t *idx = 0);
+
+ long double stold(const
+u32string& str, size_t *idx = 0);
+
+ u32string
+to_u32string(long long val);
+
+ u32string
+to_u32string(unsigned long long val);
+
+ u32string
+to_u32string(long double val);
+}
+ 
+27.2
+ 
+namespace std {
+
+ ...
+
+ typedef
+basic_ios<char> ios;
+
+ typedef
+basic_ios<wchar_t> wios;
+
+ typedef
+basic_ios<char16_t> u16ios;
+
+ typedef
+basic_ios<char32_t> u32ios;
+ 
+
+ ...
+
+ typedef
+basic_ifstream<wchar_t> wifstream;
+
+ typedef
+basic_ofstream<wchar_t> wofstream;
+
+ typedef
+basic_fstream<wchar_t> wfstream;
+ 
+
+ typedef
+basic_streambuf<char16_t> u16streambuf;
+
+ typedef
+basic_istream<char16_t> u16istream;
+
+ typedef
+basic_ostream<char16_t> u16ostream;
+
+ typedef
+basic_iostream<char16_t> u16iostream;
+ 
+
+ typedef
+basic_stringbuf<char16_t> u16stringbuf;
+
+ typedef
+basic_istringstream<char16_t> u16istringstream;
+
+ typedef
+basic_ostringstream<char16_t> u16ostringstream;
+
+ typedef
+basic_stringstream<char16_t> u16stringstream;
+
+ typedef
+basic_filebuf<char16_t> u16filebuf;
+ 
+
+ typedef
+basic_ifstream<char16_t> u16ifstream;
+
+ typedef
+basic_ofstream<char16_t> u16ofstream;
+
+ typedef
+basic_fstream<char16_t> u16fstream;
+ 
+
+ typedef
+basic_streambuf<char32_t> u32streambuf;
+
+ typedef
+basic_istream<char32_t> u32istream;
+
+ typedef
+basic_ostream<char32_t> u32ostream;
+
+ typedef
+basic_iostream<char32_t> u32iostream;
+ 
+
+ typedef
+basic_stringbuf<char32_t> u32stringbuf;
+
+ typedef
+basic_istringstream<char32_t> u32istringstream;
+
+ typedef
+basic_ostringstream<char32_t> u32ostringstream;
+
+ typedef
+basic_stringstream<char32_t> u32stringstream;
+
+ typedef
+basic_filebuf<char32_t> u32filebuf;
+ 
+
+ typedef
+basic_ifstream<char32_t> u32ifstream;
+
+ typedef
+basic_ofstream<char32_t> u32ofstream;
+
+ typedef basic_fstream<char32_t>
+u32fstream;
+ 
+
+ ...
+
+ template <class
+state> class fpos;
+
+ typedef
+fpos<char_traits<char>::state_type> streampos;
+
+ typedef
+fpos<char_traits<wchar_t>::state_type>
+wstreampos;
+
+ typedef
+fpos<char_traits<char16_t>::state_type>
+u16streampos;
+
+ typedef
+fpos<char_traits<char32_t>::state_type>
+u32streampos;
+}
+ 
+27.6
+ 
+namespace std {
+
+ template <class
+charT, class traits = char_traits<charT> >
+
+ class
+basic_istream;
+
+ typedef
+basic_istream<char> istream;
+
+ typedef
+basic_istream<wchar_t> wistream;
+
+ typedef
+basic_istream<char16_t> u16istream;
+
+ typedef
+basic_istream<char32_t> u32istream;
+ 
+
+ template <class
+charT, class traits = char_traits<charT> >
+
+ class
+basic_iostream;
+
+ typedef
+basic_iostream<char> iostream;
+
+ typedef
+basic_iostream<wchar_t> wiostream;
+
+ typedef
+basic_iostream<char16_t> u16iostream;
+
+ typedef
+basic_iostream<char32_t> u32iostream;
+}
+ 
+namespace std {
+
+ template <class
+charT, class traits = char_traits<charT> >
+
+ class
+basic_ostream;
+
+ typedef
+basic_ostream<char> ostream;
+
+ typedef
+basic_ostream<wchar_t> wostream;
+
+ typedef
+basic_ostream<char16_t> u16ostream;
+
+ typedef
+basic_ostream<char32_t> u32ostream;
+}
+ 
+27.7 paragraph 1
+ 
+namespace std {
+
+ template <class
+charT, class traits = char_traits<charT>,
+
+     class Allocator = allocator<charT>
+>
+
+ class
+basic_stringbuf;
+ 
+
+ typedef
+basic_stringbuf<char> stringbuf;
+
+ typedef
+basic_stringbuf<wchar_t> wstringbuf;
+
+ typedef
+basic_stringbuf<char16_t> u16stringbuf;
+
+ typedef
+basic_stringbuf<char32_t> u32stringbuf;
+ 
+
+ template <class
+charT, class traits = char_traits<charT>,
+
+     class Allocator = allocator<charT>
+>
+
+ class
+basic_istringstream;
+ 
+
+ typedef
+basic_istringstream<char> istringstream;
+
+ typedef
+basic_istringstream<wchar_t> wistringstream;
+
+ typedef
+basic_istringstream<char16_t> u16istringstream;
+
+ typedef
+basic_istringstream<char32_t> u32istringstream;
+ 
+
+ template <class
+charT, class traits = char_traits<charT>,
+
+     class Allocator = allocator<charT>
+>
+
+ class
+basic_ostringstream;
+ 
+
+ typedef
+basic_ostringstream<char> ostringstream;
+
+ typedef
+basic_ostringstream<wchar_t> wostringstream;
+
+ typedef
+basic_ostringstream<char16_t> u16ostringstream;
+
+ typedef
+basic_ostringstream<char32_t> u32ostringstream;
+ 
+
+ template <class
+charT, class traits = char_traits<charT>,
+
+     class Allocator = allocator<charT>
+>
+
+ class
+basic_stringstream;
+ 
+
+ typedef
+basic_stringstream<char> stringstream;
+
+ typedef
+basic_stringstream<wchar_t> wstringstream;
+
+ typedef
+basic_stringstream<char16_t> u16stringstream;
+
+ typedef
+basic_stringstream<char32_t> u32stringstream;
+}
+ 
+27.8.1 paragraph 1
+ 
+namespace std {
+
+ template <class
+charT, class traits = char_traits<charT> >
+
+ class
+basic_filebuf;
+
+ typedef
+basic_filebuf<char> filebuf;
+
+ typedef
+basic_filebuf<wchar_t> wfilebuf;
+
+ typedef
+basic_filebuf<char16_t> u16filebuf;
+
+ typedef
+basic_filebuf<char32_t> u32filebuf;
+ 
+
+ template <class
+charT, class traits = char_traits<charT> >
+
+ class
+basic_ifstream;
+
+ typedef
+basic_ifstream<char> ifstream;
+
+ typedef
+basic_ifstream<wchar_t> wifstream;
+
+ typedef
+basic_ifstream<char16_t> u16ifstream;
+
+ typedef
+basic_ifstream<char32_t> u32ifstream;
+ 
+
+ template <class
+charT, class traits = char_traits<charT> >
+
+ class
+basic_ofstream;
+
+ typedef
+basic_ofstream<char> ofstream;
+
+ typedef
+basic_ofstream<wchar_t> wofstream;
+
+ typedef
+basic_ofstream<char16_t> u16ofstream;
+
+ typedef
+basic_ofstream<char32_t> u32ofstream;
+ 
+
+ template <class
+charT, class traits = char_traits<charT> >
+
+ class
+basic_fstream;
+
+ typedef
+basic_fstream<char> fstream;
+
+ typedef
+basic_fstream<wchar_t> wfstream;
+
+ typedef
+basic_fstream<char16_t> u16fstream;
+
+ typedef
+basic_fstream<char32_t> u32fstream;
+}
+ 
+28.4
+ 
+namespace std {
+
+ ...
+
+ typedef
+basic_regex<char> regex;
+
+ typedef
+basic_regex<wchar_t> wregex;
+
+ typedef
+basic_regex<char16_t> u16regex;
+
+ typedef
+basic_regex<char32_t> u32regex;
+ 
+
+ ...
+
+ typedef
+sub_match<const char*> csub_match;
+
+ typedef
+sub_match<const wchar_t*> wcsub_match;
+
+ typedef
+sub_match<const char16_t*> u16csub_match;
+
+ typedef
+sub_match<const char32_t*> u16csub_match;
+
+ typedef
+sub_match<string::const_iterator> ssub_match;
+
+ typedef
+sub_match<wstring::const_iterator> wssub_match;
+
+ typedef
+sub_match<u16string::const_iterator> u16ssub_match;
+
+ typedef
+sub_match<u32string::const_iterator> u32ssub_match;
+ 
+
+ ...
+
+ typedef
+match_results<const char*> cmatch;
+
+ typedef
+match_results<const wchar_t*> wcmatch;
+
+ typedef
+match_results<const char16_t*> u16cmatch;
+
+ typedef
+match_results<const char32_t*> u32cmatch;
+
+ typedef
+match_results<string::const_iterator> smatch;
+
+ typedef
+match_results<wstring::const_iterator> wsmatch;
+
+ typedef
+match_results<u16string::const_iterator> u16smatch;
+
+ typedef
+match_results<u32string::const_iterator> u32smatch;
+ 
+
+ ...
+
+ typedef
+regex_iterator<const char*> cregex_iterator;
+
+ typedef
+regex_iterator<const wchar_t*> wcregex_iterator;
+
+ typedef
+regex_iterator<const cha16r_t*> u16cregex_iterator;
+
+ typedef
+regex_iterator<const char32_t*> u32cregex_iterator;
+
+ typedef
+regex_iterator<string::const_iterator>
+sregex_iterator;
+
+ typedef
+regex_iterator<wstring::const_iterator>
+wsregex_iterator;
+
+ typedef
+regex_iterator<u16string::const_iterator>
+u16sregex_iterator;
+
+ typedef
+regex_iterator<u32string::const_iterator>
+u32sregex_iterator;
+ 
+
+ ...
+
+ typedef
+regex_token_iterator<const char*>
+cregex_token_iterator;
+
+ typedef
+regex_token_iterator<const wchar_t*>
+wcregex_token_iterator;
+
+ typedef
+regex_token_iterator<const char16_t*>
+u16cregex_token_iterator;
+
+ typedef
+regex_token_iterator<const char32_t*>
+u32cregex_token_iterator;
+
+ typedef
+regex_token_iterator<string::const_iterator>
+sregex_token_iterator;
+
+ typedef
+regex_token_iterator<wstring::const_iterator>　　　wsregex_token_iterator;
+
+ typedef
+regex_token_iterator<u16string::const_iterator>
+u16sregex_token_iterator;
+
+ typedef
+regex_token_iterator<u32string::const_iterator>　u32sregex_token_iterator;
+}
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+144
+<td>
+17.1
+<td>
+2
+<td>
+Ed
+<td>
+List of
+contents of library should be extened to cover new clauses
+<td>
+Add "regular
+expressions, atomic operations and threads"
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+145
+<td>
+17.1
+<td>
+6
+<td>
+Ed
+<td>
+Summary of numeric
+facilities should mention random numbers
+ 
+<td>
+Add random
+number framework to the list of library facilities
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+146
+<td>
+17.1
+<td>
+ 
+<td>
+Ed
+<td>
+Add a summary
+paragraph for regular expressions
+<td>
+Add a summary
+paragraph for regular expressions
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+147
+<td>
+17.1
+<td>
+ 
+<td>
+Ed
+<td>
+Add a summary
+paragraph for threads
+<td>
+Add a summary
+paragraph for threads
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+148
+<td>
+17.2
+<td>
+Table
+12
+<td>
+Ed
+<td>
+Table 12 is mentioned in and relates to section
+17.2, but has been pushed down to appear directly after the title
+of section 17.3 which is rather unfortunate/confusing for the
+reader.
+ 
+<td>
+Make sure
+tables are rendered in the section to which they relate.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+149
+<td>
+17.3
+<td>
+ 
+<td>
+Ed
+<td>
+For consistency with narrow-oriented and
+wide-oriented streams, we should add terms for streams of Unicode
+character sequences
+ 
+<td>
+Define
+Utf16-oriented stream classes and Uft32-oriented stream classes for
+streams of char16_t/char32_t values.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+150
+<td>
+17.3
+<td>
+ 
+<td>
+Ed
+<td>
+The addition
+of move semantics to the language means that many library APIs
+leave an object in a safely-destructible state, where no other
+operations can safely be performed unless it is assigned a new
+value. Library presentation would be simplified and made more
+precise if we introduce a term for this state. By analogy with
+singular iterators suggest the term 'singular object' or 'the
+object is in a singular state'.
+<td>
+Define 'singular state' such that an object with a
+singular state can only be assigned to or safely destroyed.
+Assiging a new value typically removes the singular state. Note
+that objects with a singular state may not be safely copied, so you
+cannot put an object into a singular state by copying another
+object in a singular state. Use this new term in the postcondition
+of all library APIs that move from an rvalue reference. It might
+also be used to simplify the definition of singular iterator to an
+iterator value with a singular state.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+151
+<td>
+17.3.1
+<td>
+ 
+<td>
+Ed
+<td>
+Missing crossreference to 17.3.17
+[defns.repositional.stream]
+ 
+<td>
+Add
+cross-reference in the existing empty brackets
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+152
+<td>
+17.3.12
+<td>
+ 
+<td>
+Te
+<td>
+Object state is using a definition of object
+(instance of a class) from outside the standard, rather than the
+'region of storage' definiton in 1.8p1
+ 
+<td>
+Clarify terms
+and usage
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+153
+<td>
+17.3.17
+<td>
+ 
+<td>
+Te
+<td>
+If a repositional stream can only seek to a
+position previously encountered, then an
+arbitrary-positional-stream cannot satisfy this definition, as
+cross-referenced in 17.3.17
+ 
+<td>
+Strike the
+word 'only'. A note might be added to reinforce the intent
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+154
+ 
+<td>
+17.3.20
+<td>
+ 
+<td>
+Ed
+<td>
+Missing
+definition of a stable partition algorithm
+<td>
+Add
+definition from 25.2.12p7
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+155
+<td>
+17.3.3
+<td>
+ 
+<td>
+Ed
+<td>
+Add clause 28
+to list that use this definition of character
+<td>
+Add clause 28
+to list that use this definition of character
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+156
+<td>
+17.3.4
+<td>
+ 
+<td>
+Ed
+<td>
+Add regular expressions to set of templates using
+character container type
+ 
+<td>
+Add regular
+expressions to set of templates using character container
+type
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+157
+<td>
+17.5.2.2
+<td>
+3
+<td>
+Ed
+<td>
+Add concepts to the ordered list of
+presentation
+ 
+ 
+<td>
+Add concepts
+into the sequence
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+158
+<td>
+17.5.2.2
+<td>
+3
+<td>
+Ed
+<td>
+templates are
+neither classes nor functions
+<td>
+Replace 'classes' and 'functions' with 'classes
+and class templates' and 'functions and function templates'
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+159
+<td>
+17.5.2.4
+<td>
+Footnote
+152
+<td>
+Ed
+<td>
+This informative footnote was relevant in 1998,
+not 2008. The term 'existing vendors' may imply something different
+now
+ 
+<td>
+Strike the
+footnote, or replace 'existing' with 'original' or similar
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+160
+<td>
+17.5.2.4
+<td>
+3
+<td>
+Ed
+<td>
+requires is now a keyword with a specific meaning
+related to concepts, and its use in library specifcation may be
+confusing. Generally the Requires clause is used to make
+requirements on the caller, not the library, so typically providing
+runtime pre-conditions. Suggest a new name to refflect that. Note
+that Clause 30 already seems to be written to this
+convention.
+ 
+<td>
+Replace
+'Requires' with 'Preconditions'
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+161
+<td>
+17.5.2.4
+<td>
+4
+<td>
+Ed
+<td>
+This paragraph is redundant as the definition of
+the term 'handler function' is already provided in 17.3. Are we in
+danger of proving two definitions of the same terms? Which is the
+'controlling' definition?
+ 
+<td>
+Strike
+17.5.2.4p4
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+162
+<td>
+17.5.2.4
+<td>
+3
+<td>
+Ed
+<td>
+Clause 30 makes use of a 'Synchronization'
+semantic element, that frequently appears either between Effects:
+and Postconditions:, or between Returns: and Throws:
+ 
+<td>
+Add
+'Synchronization' to the list either between Effects: and
+Postconditions:, or between Returns: and Throws:.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+163
+<td>
+17.5.2.4
+<td>
+3
+<td>
+Te
+<td>
+Many functions are defined as "Effects: Equivalent
+to a...", which seems to also define the preconditions, effects,
+etc. But this is not made clear.
+ 
+<td>
+Introduce an
+explicit "Equivalent to", which defines all of the properties of
+the function.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+164
+<td>
+17.5.3.2.1
+<td>
+1
+<td>
+Ed
+<td>
+This phrasing
+predates concepts. While this kind of description is still used,
+the examples provided are now all concepts, and should be replaced
+with appropriate examples
+<td>
+Use better names for the examples. Ideally totally
+replace the need by constraining all templates in library, so that
+real concepts are all that is needed. Note if retained that
+CopyConstructible is mis-spelled.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+165
+<td>
+17.5.3.2.2, 17.5.3.2.3
+<td>
+ 
+<td>
+Te
+<td>
+constraints on bitmask and enumation types were
+supposed to be tightened up as part of the motivation for the
+constexpr feature - see paper n2235 for deails
+ 
+<td>
+Adopt wording
+in line with the motivation described in N2235
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+166
+<td>
+17.5.3.2.4.1, 17.5.3.3
+ 
+<td>
+ 
+<td>
+Ed
+<td>
+List of
+library clauses should go up to 30, not 27
+<td>
+Replace
+initial refernce to ch27 with ch30
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+167
+<td>
+17.5.3.4
+Private members
+<td>
+ 
+<td>
+Ed
+<td>
+Comment
+marker in wrong place.
+<td>
+Change: // streambuf* sb; exposition only to
+streambuf* sb; // exposition only To reflect actual usage.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+168
+<td>
+17.6.2.2
+<td>
+2
+<td>
+Te
+<td>
+We should make it clear (either by note or
+normatively) that namespace std may contain inline namespaces, and
+that entities specified to be defined in std may in fact be defined
+in one of these inline namespaces. (If we're going to use them for
+versioning, eg when TR2 comes along, we're going to need
+that.)
+ 
+<td>
+Replace
+"namespace std or namespaces nested within namespace std" with
+"namespace std or namespaces nested within namespace std or inline
+namespaces nested directly or indirectly within namespace
+std"
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+169
+<td>
+17.6.2.2
+<td>
+ 
+<td>
+Te
+<td>
+This phrasing contradicts later freedom to
+implement the C standard library portions in the global namespace
+as well as std. (17.6.2.3p4)
+ 
+<td>
+Resolve
+conflict in either place
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+170
+<td>
+17.6.2.3
+<td>
+ 
+<td>
+Te
+<td>
+One of goals of C++0x is to make language easier
+to teach and for 'incidental' programmers. The fine-grained headers
+of the C++ library are valuable in large scale systems for managing
+dependencies and optimising build times, but overcomplicated for
+simple development and tutorials. Add additional headers to support
+the whole library through a single include statement.
+ 
+<td>
+Add a new
+header <std> that has the effect of including everything in
+tables 13 and 14, except <iosfwd> and <cassert>. Add an
+additional header <fwd> that adds all declarations from
+<std> but no definitions.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+171
+<td>
+17.6.2.4
+<td>
+3
+<td>
+Ed
+<td>
+Does freestanding implementation require a full
+implementation of all listed headers? The reference to abort,
+at_exit and exit is confusing. Is a conforming implementation allow
+to deliver partial forms of these headers? If so which ones? Are
+empty versions of everything but <cstdlib> conforming?
+ 
+<td>
+Either strike
+the references to abort, at_exit and exit, or clarify which headers
+only require partial support.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+172
+<td>
+17.6.2.4
+<td>
+3
+<td>
+Te
+<td>
+No reference to new functions quick_exit and
+at_quick_exit
+ 
+<td>
+Add reference
+to quick_exit and at_quick_exit
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+173
+<td>
+17.6.2.4
+<td>
+table
+15
+<td>
+Te
+<td>
+<initializer_list> is missing from headers
+required in freestanding implementations.
+ 
+<td>
+Add 18.8,
+initializer lists, <initializer_list>, to the end of the
+table.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 23
+<td>
+17.6.2.4
+<td>
+2nd paragraph, Table 15
+<td>
+te
+<td>
+There is a freestanding implementation including
+<type_traits>, <array>, <ratio>, lately added to
+Table 13, C++ library headers. 
+Programmers think them useful and hope that these headers are also
+added to Table 15, C++ headers for freestanding implementations,
+that shows the set of headers which a freestanding implementation
+shall include at least.
+ 
+<td>
+Add <type_traits>, <array>,
+<ration> to Table 15.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+174
+<td>
+17.6.3.2
+<td>
+3
+<td>
+Ed
+<td>
+The phrasing is mildly ambiguous when using the
+word 'it' to refer back to the header - an unfotunate reading might
+confuse it with the translate unit, which is the subject of the
+surrounding clause.
+ 
+<td>
+Replace 'the
+first reference to any of the entities declared in that header by
+the translation unit' with 'the first reference to any of the
+entities that header declares in the translation unit'
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+175
+<td>
+17.6.4.2.1
+<td>
+2
+<td>
+Te
+<td>
+Local types can now be used to instantiate
+templates, but don't have external linkage
+ 
+<td>
+Remove the
+reference to external linkage
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+176
+<td>
+17.6.4.3.3
+<td>
+Footnote 175
+ 
+<td>
+Ed
+<td>
+Reference to
+namespace ::std should be 17.6.4.2
+<td>
+Change
+referfence from 17.6.4.3 to 17.6.4.2
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+177
+<td>
+17.6.4.3.4
+<td>
+3
+<td>
+Ed
+<td>
+Sentence is redundant as double underscores are
+reserved in all contexts by 17.6.4.3.3
+ 
+<td>
+Strike the
+sentence
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+178
+<td>
+17.6.4.8
+<td>
+2
+<td>
+Ed
+<td>
+The last
+sentence of the third bullet "Operations on such types can report a
+failure by throwing an exception unless otherwise specified" is
+redundant as behaviour is already undefined.
+<td>
+Strike the
+sentence
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+179
+<td>
+17.6.4.8
+<td>
+2
+<td>
+Te
+<td>
+According to the 4th bullet there is a problem if
+"if any replacement function or handler function or destructor
+operation throws an exception". There should be no problem throwing
+exceptions so long as they are caught within the function.
+ 
+<td>
+Replace the
+word 'throws' with 'propogates'
+<td>
+ 
+<tr valign="top">
+<td>
+JP 22
+<td>
+17.6.5.7
+<td>
+4th paragraph, 1st line
+<td>
+ed
+<td>
+The statement below describes relation
+among two or more threads using words “between
+threads”: 
+[Note: This means, for example, that implementations can’t
+use a static object for internal purposes without synchronization
+because it could cause a data race even in programs that do not
+explicitly share objects between threads. —end note ]
+In such case, “among” is
+preferred instead of “between”.
+<td>
+Change "between threads" to "among
+threads".
+There are same cases in 17.6.1 paragraph
+2, 17.6.5.7 paragraph 6, 30.1 paragraph 1, 30.3.1 paragraph 1
+also.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+180
+<td>
+17.6.5.10
+<td>
+1,
+4
+<td>
+Te
+<td>
+It should not be possible to strengthen the
+exception specification for virtual functions as this could break
+user code. Note this is not a problem in practice as there are no
+virtual functions with exception specifications in the current
+library, other than empty throw specifications which it is not
+possible to strengthen.
+ 
+<td>
+Add
+restriction that exception specification of virtual functions
+cannot be tightened.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+181
+<td>
+17.6.5.10
+<td>
+Footnote
+186
+<td>
+Te
+<td>
+This footnote is wrong. C library functions do not
+have any exception specification, but might be treated as if they
+had an empty throw specification
+ 
+<td>
+Clarify that
+this note does not mean the functions are genuinely declared with
+the specification, but are treated as-if.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+182
+<td>
+17.6.5.10
+<td>
+Footnote
+188
+<td>
+Te
+<td>
+It is very helpful to assume all exceptions thrown
+by the standard library derive from std::exception. The
+'encouragement' of this note should be made normative.
+ 
+<td>
+Make this
+footnote normative
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+184
+<td>
+18 ->
+30
+<td>
+ 
+<td>
+Ed
+<td>
+The new alias-declaration syntax is generally
+easier to read than a typedef declaration. This is especially true
+for complex types like function pointers.
+ 
+<td>
+Replace all
+typedef declarations in the standard library with
+alias-declarations, except in the standard C library.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 24
+<td>
+18
+<td>
+2nd paragraph, Table 16
+<td>
+ed
+<td>
+Subclauses are listed in Table 16
+as:
+"18.6 Type identification …"
+"18.8 Initializer lists …"
+"18.7 Exception handling …".
+<td>
+
+Sort them in the increasing
+order 
+"18.6 Type identification …"
+"18.7 Exception handling …".
+
+"18.8 Initializer lists
+…"
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 25
+<td>
+18.1
+<td>
+6th paragraph , last line, SEE ALSO
+ 
+<td>
+ed
+<td>
+max_align_t is described in 18.1, so add
+3.11 Alignment as the reference.
+<td>
+Add "3.11, Alignment" to SEE ALSO.
+<td>
+ 
+<tr valign="top">
+<td>
+FR 32
+<td>
+18.2.1 [Numeric limits]
+<td>
+ 
+<td>
+te
+<td>
+The definition of numeric_limits<>
+as requiring a regular type is both conceptually wrong and
+operationally illogical. As we pointed before, this mistake needs
+to be corrected. For example, the template can be left
+unconstrained. In fact this reflects a much more general problem
+with concept_maps/axioms and their interpretations. It appears that
+the current text heavily leans toward experimental academic type
+theory.
+ 
+<td>
+We suggest that a more pragmatic approach, in
+the spirit of C and C++, be taken so that calls to constrained
+function templates are interpreted as assertions on *values*, not
+necessarily semantics assertions on the carrier type.
+<td>
+ 
+<tr valign="top">
+<td>
+DE-16
+<td>
+18.2.1
+<td>
+ 
+<td>
+te
+<td>
+
+DE-16 The class template
+numeric_limits should not
+specify the Regular concept
+requirement for its template parameter, because it contains
+functions returning NaN values for floating-point types; these
+values violate the semantics of EqualityComparable. See also library
+issue 902 in WG21 document N2794 "C++ Standard Library Active
+Issues List (Revision R60)", available at
+http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2794.html
+.
+ 
+<td>
+Specify a concept
+requirement with fewer constraints as appropriate, for example
+SemiRegular.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 26
+<td>
+18.2.1.1
+<td>
+ 
+<td>
+te
+<td>
+numeric_limits does not use
+concept.
+<td>
+Correct as follows.
+ 
+template<class T> class
+numeric_limits<const T>;
+template<class T> class
+numeric_limits<volatile T>;
+template<class T> class
+numeric_limits<const volatile T>;
+ 
+should be
+ 
+template<Regular T> class
+numeric_limits<const T>;
+template<Regular T> class
+numeric_limits<volatile T>;
+template<Regular T> class
+numeric_limits<const volatile T>;
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+DE-17
+<td>
+18.2.6
+<td>
+ 
+<td>
+te
+<td>
+
+DE-17 The class type_index should be removed; it
+provides no additional functionality beyond providing appropriate
+concept maps.
+ 
+<td>
+Specify concept maps for
+"const type_info *" as required by the ordered and unordered
+containers and remove the class type_index.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+185
+<td>
+18.3.1
+<td>
+2
+<td>
+Ed
+<td>
+There is no header <stdint>, it should
+either be <stdint.h> or <cstdint>
+ 
+<td>
+Replace
+<stdint> with <cstdint>
+<td>
+ 
+<tr valign="top">
+<td>
+DE-18
+<td>
+18.4
+<td>
+ 
+<td>
+te
+<td>
+
+DE-18 The proposed C++
+standard makes a considerable number of existing programs that have
+well-defined behavior according to ISO/IEC 14882:2003 have
+undefined behavior without a diagnostic hint to the programmer at
+all. This applies to the presence of threads and to pointer safety
+(the latter was introduced to support garbage collection). In order
+to avoid requiring a full code review for user code, facilities
+should be present that allow the compile-time detection of the
+advanced features of the proposed C++ standard. It is expected that
+C++ implementations will provide a means (for example, a
+command-line switch) to turn off either or both of threads and
+garbage collection support, turning potentially undefined programs
+into well-defined ones. 
+Note: This issue is contributing significantly to Germany's
+overall “no” vote.
+ 
+<td>
+Consider applying the
+changes proposed in WG21 document N2693 "Requirements on programs
+and backwards compatibility", available at
+http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2693.html
+.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+186
+<td>
+18.4
+<td>
+Footnote
+221
+<td>
+Ed
+<td>
+What is the purpose of this comment? The standard
+stream objects (cin, cerr etc.) have a peculiar lifetime that
+extends beyond the program. They may never be destroyed so will not
+be responsible for flushing buffers at the stated time.
+ 
+<td>
+Remove the
+footnote
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+187
+<td>
+18.4
+<td>
+9
+<td>
+Te
+<td>
+The term "thread safe" is not defined nor used in
+this context anywhere else in the standard.
+ 
+<td>
+Clarify the
+intended meaing of "thread safe"
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+188
+<td>
+18.4
+<td>
+12
+<td>
+Te
+<td>
+The function _Exit does not appear to be defined
+in this standard. Should it be added to the table of functions
+included-by-reference to the C standard?
+ 
+<td>
+Depends on
+where _Exit comes from
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+189
+<td>
+18.4,
+18.7
+<td>
+ 
+<td>
+Te
+<td>
+The addition
+of the [[noreturn]] attribute to the language will be an important
+aid for static analysis tools.
+<td>
+The following functions should be declared in C++
+with the [[noreturn]] attribute: abort exit quick_exit terminate
+unexpected rethrow_exception throw_with_nested
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 27
+<td>
+18.4, 18.9, 18.7.2.2, 18.7.3.1
+<td>
+ 
+<td>
+te
+<td>
+There are Standard library functions
+that never return to the caller. They are explained so in the
+Standard but not declared explicitly.
+<td>
+Consider to add the attribute
+[[noreturn]] to such functions,
+ 
+15.5.2 unexpected 
+18.4: abort(), exit(), quick_exit, 
+18.7.2.2: unexpected_handler, 
+18.7.3.1: terminate_handler,
+18.7.6 rethrow_nested
+18.7.6 throw_with_nested 
+18.9: longjmp.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+190
+<td>
+18.5.1
+<td>
+various
+<td>
+Te
+<td>
+It is not
+entirely clear how the current specification acts in the presence
+of a garbage collected implementation.
+<td>
+All deallocation functions taking a pointer
+parameter should have a Precondition : ptr is a safely-derived
+pointer value.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+191
+<td>
+18.5.1.1
+<td>
+4
+<td>
+Ed
+<td>
+According to
+the second bullet, behaviour becomes undefined (for lack of a
+specification) if the user has not yet called
+set_new_handler.
+<td>
+Rephrase the second bullet in terms of a new
+handler being installed, and update any definition of handler
+function necessary to be sure the term 'installed' is
+defined.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+192
+<td>
+18.5.1.2
+<td>
+ 
+<td>
+Te
+<td>
+The declared signature is not compatible with the
+current requirement to throw std::length_error. It is too late to
+weaken the exception specification, so the only other change is to
+preserve new (improved) behaviour is to throw std::bad_alloc, or
+something derived from std::bad_alloc.
+ 
+<td>
+Fix 5.3.4p7
+by required std::bad_alloc rather than std::length_error
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+193
+<td>
+18.5.2.2
+<td>
+2
+<td>
+Te
+<td>
+quick_exit has been added as a new valid way to
+terminate a program in a well defined way
+ 
+<td>
+Change 3rd
+bullet: call either abort(), exit() or quick_exit();
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+194
+<td>
+18.6
+<td>
+ 
+<td>
+Te
+<td>
+The inclusion of type_index and
+hash<type_index> in <typeinfo> brings dependencies into
+<typeinfo> which are inconsistent with the definition of
+freestanding C++ in 17.6.2.4.
+ 
+<td>
+Move
+type_index and hash<type_index> out of <typeinfo> and
+into a new header, <typeindex>.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 28
+<td>
+18.6, 18.7, 19.1
+<td>
+ 
+<td>
+te
+<td>
+Errors reported by Exception classes are
+of types char or std::string only. For example, std::exception is
+declared with char, std::string types, therefore types
+wchar_t/wstring, char16_t/u16string, or char32_t/u32string can not
+be used.
+ 
+<td>
+Consider other types.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 29
+<td>
+18.7.6
+<td>
+ 
+<td>
+te
+<td>
+throw_with_nested does not use
+concept.
+<td>
+Correct as follows.
+template<class T> void
+throw_with_nested(T&& t); // [[noreturn]]
+ 
+should be
+ 
+template<CopyConstructible T> void
+throw_with_nested(T&& t); // [[noreturn]]
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 30
+<td>
+18.7.6
+<td>
+ 
+<td>
+te
+<td>
+To handle nested exceptions strictly,
+error information of tree structure will be required though, the
+nested_exception does not support tree structure. It is
+insufficient as error handling.
+<td>
+Consider nested_exception to support
+tree structure.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 31
+<td>
+18.7.6
+<td>
+ 
+<td>
+te
+<td>
+It is difficult to understand in which
+case nested_exception is applied.
+<td>
+Consider to add a sample program which rethrows
+exception.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+195
+<td>
+18.8
+<td>
+ 
+<td>
+Te
+<td>
+The class definition of std::initializer_list
+contains concept-maps to Range which should be out of the class,
+and in <iterator_concepts> instead. Otherwise, it's not
+possible to use initializer_lists in a freestanding C++
+implementation.
+ 
+<td>
+Delete the
+two concept maps from std::initializer_list.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+196
+<td>
+18.8.3
+<td>
+ 
+<td>
+Te
+<td>
+Concept maps
+for initializer_list to Range should not be in language support
+headers, but instead in iterator concepts.
+<td>
+Remove section 18.8.3 and put it in 24.1.8.1
+instead, so that the concept_maps from initializer_list to Range
+are specified under Range instead of under initializer lists; also,
+so that they're implemented in <iterator_concepts> instead of
+<initializer_list>.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+197
+<td>
+19
+<td>
+ 
+<td>
+Te
+<td>
+All the
+exception classes in this clause take a std::string argument by
+const reference. They should all be overloaded to accept
+std::string by rvalue rerefence for an efficient move as
+well.
+<td>
+Provide a constructor for every exception class in
+clause 19 accepting a std::string by rvalue reference, with the
+semantics that the passed string may be moved.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 32
+<td>
+19.1
+<td>
+ 
+<td>
+te
+<td>
+Messages returned by the member function
+what() of standard exception classes seem difficult to
+judge.
+For example, following messages are
+returned by what() of std::bad_alloc of existing
+implementations:
+ 
+Compiler: Message returned by
+what()
+---------------------------------------------
+Borland C++ 5.6.4: no named exception
+thrown
+Visual C++ 8.0: bad allocation
+Code Warrior 8.0: exception
+g++ 3.4.4: St9exception
+ 
+It is difficult to recognize what exception was
+thrown when using those compilers except Visual C++.
+ 
+<td>
+Consider to add footnote that recommends
+what() returns message easy to recognize what exception was
+thrown.
+<td>
+ 
+<tr valign="top">
+<td>
+US 64
+<td>
+19.3
+<td>
+1
+<td>
+Ge
+<td>
+“ See also: ISO C 7.1.4, 7.2, Amendment 1
+4.3.” It is unclear why this cross reference is here.
+Amendment 1 was to C89, not C99.
+<td>
+
+Delete this cross reference.
+If necessary, expand the main text to include the relevant
+referenced text
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 65
+<td>
+20
+<td>
+ 
+<td>
+te
+<td>
+Scoped allocators and allocator propagation traits
+add a small amount of utility at the cost of a great deal of
+machinery. The machinery is user visible, and it extends to library
+components that don't have any obvious connection to allocators,
+including basic concepts and simple components like pair and
+tuple.
+<td>
+Sketch of proposed resolution: Eliminate
+scoped allocators, replace allocator propagation traits with a
+simple uniform rule (e.g. always propagate on copy and move),
+remove all mention of allocators from components that don't
+explicitly allocate memory (e.g. pair), and adjust container
+interfaces to reflect this simplification.
+Components that I propose eliminating
+include HasAllocatorType<a href=
+"http://wiki.corp.google.com/twiki/bin/edit/Main/HasAllocatorType?topicparent=Main.CppStandardIssues">
+?</a>, is_scoped_allocator, allocator_propagation_map,
+scoped_allocator_adaptor, and ConstructibleAsElement
+<a href=
+"http://wiki.corp.google.com/twiki/bin/edit/Main/ConstructibleAsElement?topicparent=Main.CppStandardIssues">
+?</a>.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+198
+<td>
+20
+<td>
+ 
+<td>
+Ed
+<td>
+The
+organization of clause 20 could be improved to better group related
+items, making the standard easier to navigate.
+<td>
+20.6.7, 20.6.8, 20.6.9 and 20.6.10 should be
+grouped under a section called "operator wrappers" or similar. The
+goal of all 4 subsections combined is to provide a functor for
+every operator in the language. 20.6.17 class template hash should
+numerically appear immediately after the operator wrappers, as they
+are functors that are used in similar ways 20.6.11, 20.6.12,
+20.6.13, 20.6.14, 20.6.15 are strongly related to 20.6.3, and to an
+extent 20.6.2. These should all come under a subheading of
+"function adapters" 20.7.1, 20.7.3, 20.7.4, 20.7.5, 20.7.6, 20.7.7
+and 20.7.10 should all be grouped as subclauses under [20.7.2
+Allocators] [20.7.12 unique_ptr] should be a sub-section of
+[20.7.13 smart pointers] [20.7.13 smart pointers] is important
+enough to have a high level bullet after [20.7 memory], suggest
+renumbering as [20.8 smart pointers] [20.7.13.7 Pointer safety] is
+nothing to do with smart pointers and should become its own
+subclause [20.7.14 Pointer safety] [20.9 date and time functions]
+should be moved under [20.8 time utilities] and retitled [20.8.6 C
+Library] (as per memory management/C Library) [20.6.18
+reference_closure] is fundamentally a language support feature and
+should move to clause 18, see separate comment [20.6.5
+reference_wrapper] should be simplified and moved into [2.2 utility
+components], see separate comment [20.6.4 result_of] should be
+reorganised as a type trait - see separate comment Tuples and pairs
+are closely related so merge tuple and pair into the same subclause
+- see more general comment on this
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+199
+<td>
+20.1.1,
+20.1.2
+<td>
+2
+<td>
+Te
+<td>
+The requirement that programs do not supply
+concept_maps should probably be users do not supply their own
+concept_map specializations. THe program will almost certainly
+supply concept_maps - the standard itself supplies a specialization
+for RvalueOf? references. Note that the term _program_ is defined
+in 3.5p1 and makes no account of the standard library being treated
+differently to user written code.
+ 
+<td>
+Replace the
+term 'program' with 'user'.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+200
+<td>
+20.1.4
+<td>
+ 
+<td>
+Te
+<td>
+All standard
+library use expects Predicates to be CopyConstructible, and this
+should be recognised easily without reatedly stating on every
+use-case.
+<td>
+Either require CopyConstructible<F> as part
+of Predicate, or create a refined concept, StdPredicate, used
+throughout the library that requires CopyConstructible as well as
+Callable. Consider making (Std)Predicate SemiRegular.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+201
+<td>
+20.1.5
+<td>
+ 
+<td>
+Te
+<td>
+The
+Consistency axiom for LessThanComparable will not compile.
+<td>
+Add a requires clause to the Consistency axiomL
+requires HasLessEquals<T> &&
+HasGreaterEquals<T>, or split the Consistency axiom into two
+so that 'basic' consistency can be asserted regardless of the
+<=/>= requirement.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 33
+<td>
+20.1.5
+<td>
+ 
+<td>
+te
+<td>
+LessThanComparable and
+EqualityComparable don't correspond to NaN.
+<td>
+Apply concept_map to these concepts at
+FloatingPointType
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 66
+<td>
+20.1.10
+<td>
+ 
+<td>
+te
+<td>
+Application of the
+"Regular" concept to floating-point types appears to be
+controversial (see long discussion on std-lib reflector).
+<td>
+State that the
+“Regular” concept does not apply to floating-point
+types.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 34
+<td>
+20.2
+<td>
+1st paragraph, 4th line
+ 
+<td>
+ed
+<td>
+Though N2672 pointed at adding
+"#include<initializer_list>", it isn't reflected.
+<td>
+add followings
+#include <initializer_list> // for
+concept_map
+<td>
+ 
+<tr valign="top">
+<td>
+US 67
+<td>
+20.2.1
+<td>
+¶ 5 first
+sent.
+<td>
+ed
+<td>
+Some connective words are
+missing.
+<td>
+Insert
+“corresponding to” before “an lvalue reference
+type.”
+<td>
+ 
+<tr valign="top">
+<td>
+JP 35
+<td>
+20.2.3
+<td>
+6th paragraph, 1st line
+ 
+<td>
+ed
+<td>
+Typo,
+"stdforward" should be "std::forward"
+<td>
+Correct typo.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+202
+<td>
+20.2.4
+<td>
+ 
+<td>
+Ed
+<td>
+The references to pair in the tuple-like access to
+pair functions qualify pair with std::pair even though they are in
+a namespace std block.
+ 
+<td>
+Remove the
+std:: qualification from these references to pair.
+<td>
+ 
+<tr valign="top">
+<td>
+US 68
+<td>
+20.2.12
+<td>
+IntegralLike
+<td>
+te/ed
+<td>
+The code defining the
+context is syntactically incorrect.
+<td>
+Insert a comma in two
+places: at the end of the third line of refinements, and at the end
+of the fourth line of refinements.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+203
+<td>
+20.3.2
+<td>
+1-4
+<td>
+Ed
+<td>
+The ratio_xyz types have a misplaced '}'. For
+example: template <class R1, class R2> struct ratio_add {
+typedef see below} type; ;
+ 
+<td>
+Move the '}'
+to after the typedef: template <class R1, class R2> struct
+ratio_add { typedef see below type; };
+<td>
+ 
+<tr valign="top">
+<td>
+JP 36
+<td>
+20.4.2.1
+<td>
+19th paragraph, 6th line
+ 
+<td>
+ed
+<td>
+Typo.
+"it it" should be "it is"
+<td>
+Correct typo.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+204
+<td>
+20.5
+<td>
+Table
+41
+<td>
+Te
+<td>
+It is not possible to create a variant union based
+on a parameter pack expansion, e.g. to implement a classic
+discriminated union template.
+ 
+<td>
+Restore
+aligned_union template that was removed by LWG issue 856.
+<td>
+ 
+<tr valign="top">
+<td>
+US 69
+<td>
+20.5
+<td>
+ 
+<td>
+ed
+<td>
+This section, dealing with
+tuple<>, should be in the same section as the similar utility
+pair<>.
+<td>
+Restructure Clause 20 so
+as to bring these similar components together.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+205
+<td>
+20.5.3
+<td>
+ 
+<td>
+Te
+<td>
+integral_constant objects should be usable in
+integral-constant-expressions. The addition to the language of
+literal types and the enhanced rules for constant expressions make
+this possible.
+ 
+<td>
+Add a
+constexpr conversion operator to class tempalate integral_constant:
+constexpr operator value_type() { return value; }
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+206
+<td>
+20.5.5
+<td>
+para
+4
+<td>
+Te
+<td>
+Currently the std says: "In order to instantiate
+the template is_convertible<From, To>, the following code
+shall be well formed:" But the code shown is the requirement for
+the result of is_convertible to be a true_type, not a precondition
+on whether the template can be instantiated.
+ 
+<td>
+Change: "In
+order to instantiate the template is_convertible<From, To>,
+the following code shall be well formed:" To: "The template
+is_convertible<From, To> inherits either directly or
+indirectly from true_type if the following code is well
+formed:"
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+207
+<td>
+20.5.6.1
+<td>
+Table
+36
+<td>
+Ed
+<td>
+suffix
+"::type" is missing from the some of the examples.
+<td>
+Change: Example:remove_const<const volatile
+int>::type evaluates to volatile int, whereas
+remove_const<const int*> is const int*. —end example
+To: Example:remove_const<const volatile int>::type evaluates
+to volatile int, whereas remove_const<const int*>::type is
+const int*. —end example And change:
+Example:remove_volatile<const volatile int>::type evaluates
+to const int, whereas remove_volatile<volatile int*> is
+volatile int*. —end example To:
+Example:remove_volatile<const volatile int>::type evaluates
+to const int, whereas remove_volatile<volatile int*>::type is
+volatile int*. —end example And change:
+Example:remove_cv<const volatile int>::type evaluates to int,
+whereas remove_cv<const volatile int*> is const volatile
+int*. —end example To: Example:remove_cv<const volatile
+int>::type evaluates to int, whereas remove_cv<const volatile
+int*>::type is const volatile int*. —end example
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 37
+<td>
+20.5.7
+<td>
+Table 41
+<td>
+ed
+<td>
+Typo.
+There isn't a period at the end of enable_if's
+comments.
+ 
+If B is true, the member typedef type
+shall equal T; otherwise, there shall be no member typedef
+type
+ 
+should be
+ 
+If B is true, the member typedef type
+shall equal T; otherwise, there shall be no member typedef
+type.
+ 
+<td>
+Add ”.”
+<td>
+ 
+<tr valign="top">
+<td>
+US 70
+<td>
+20.6
+<td>
+ 
+<td>
+te
+<td>
+Specifications now
+expressed via narrative text are more accurately and clearly
+expressed via executable code.
+<td>
+
+Wherever concepts are
+available that directly match this section’s type traits,
+express the traits in terms of the concepts instead of via
+narrative text. Where the type traits do not quite match the
+corresponding concepts, bring the two into alignment so as to avoid
+two nearly-identical notions.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 71
+<td>
+20.6.7
+<td>
+Table 51, last row, column
+3
+<td>
+ed
+<td>
+The grammar is
+incorrect.
+<td>
+Change “conversion
+are” to “conversion is”.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 38
+<td>
+20.6.12.1.3
+<td>
+ 
+<td>
+te
+<td>
+
+add the move requirement for
+bind's return type. 
+
+For example, assume following
+th1 and th2,
+ 
+void f(vector<int> v) { } 
+ 
+vector<int> v{ ... }; 
+thread th1([v]{ f(v); }); 
+thread th2(bind(f, v)); 
+ 
+When function object are set to thread, v is moved to th1's lambda
+expression in a Move Constructor of lambda expression becuase th1's
+lambda expression has a Move Constructor. But bind of th2's return
+type doesn't have the requirement of Move, so it may not moved but
+copied.
+Add the requirement of move to get rid
+of this useless copy.
+And also, add the MoveConstructible as well as
+CopyConstructible.
+ 
+<td>
+Add the following requirements. 
+"it
+has a public move constructor that performs a member-wise
+move."
+Add the MoveConstructible.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 39
+<td>
+20.6.16.2
+<td>
+ 
+<td>
+te
+<td>
+There are no requires corresponding to F
+of std::function.
+<td>
+Correct as follows.
+template<class F, Allocator A>
+function(allocator_arg_t, const A&, F);
+template<class F, Allocator A>
+function(allocator_arg_t, const A&, F&&);
+ 
+should be
+ 
+template<class F, Allocator
+A>
+requires CopyConstructible<F>
+&& Callable<F, ArgTypes...>
+&& Convertible<Callable<F,
+ArgTypes...>::result_type, R>
+function(allocator_arg_t, const A&,
+F);
+template<class F, Allocator
+A>
+requires CopyConstructible<F>
+&& Callable<F, ArgTypes...>
+&& Convertible<Callable<F,
+ArgTypes...>::result_type, R>
+function(allocator_arg_t, const A&,
+F&&);
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 40
+<td>
+20.6.16.2
+<td>
+ 
+<td>
+ed
+<td>
+Thougn it's "Allocator Aloc" at other
+places, it's "Allocator A" only std::function constructor template
+parameter.
+<td>
+Correct as follows.
+template<class F, Allocator A>
+function(allocator_arg_t, const A&, F);
+template<class F, Allocator A>
+function(allocator_arg_t, const A&, F&&);
+ 
+should be
+ 
+template<class F, Allocator
+Alloc> function(allocator_arg_t, const Alloc
+&, F);
+template<class F, Allocator Alloc>
+function(allocator_arg_t, const Alloc &,
+F&&);
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 41
+<td>
+20.6.16.2
+<td>
+ 
+<td>
+te
+<td>
+There are no requires corresponding to R
+and Args of UsesAllocator.
+<td>
+Correct as follows.
+template <class R, class...
+Args>
+concept_map
+UsesAllocator<function<R(Args...)>, Alloc> {
+typedef Alloc allocator_type;
+}
+ 
+should be
+ 
+template <Returnable R,
+CopyConstructible... Args>
+concept_map
+UsesAllocator<function<R(Args...)>, Alloc> {
+typedef Alloc allocator_type;
+}
+<td>
+ 
+<tr valign="top">
+<td>
+JP 42
+<td>
+20.6.16.2
+<td>
+ 
+<td>
+ed
+<td>
+The requires are wrong.
+R require Returnable, and ArgTypes
+requires CopyConstructible by a definition of function, then it's a
+mistake to designate followings by MoveConstructible.
+<td>
+Correct as follows.
+ 
+template <MoveConstructible R,
+MoveConstructible... ArgTypes>
+bool operator==(const
+function<R(ArgTypes...)>&, nullptr_t);
+template <MoveConstructible R,
+MoveConstructible... ArgTypes>
+bool operator==(nullptr_t, const
+function<R(ArgTypes...)>&);
+template <MoveConstructible R,
+MoveConstructible... ArgTypes>
+bool operator!=(const
+function<R(ArgTypes...)>&, nullptr_t);
+template <MoveConstructible R,
+MoveConstructible... ArgTypes>
+bool operator!=(nullptr_t, const
+function<R(ArgTypes...)>&);
+template <MoveConstructible R,
+MoveConstructible... ArgTypes>
+void
+swap(function<R(ArgTypes...)>&,
+function<R(ArgTypes...)>&);
+ 
+should be
+ 
+template <Returnable R,
+CopyConstructible... ArgTypes>
+bool operator==(const
+function<R(ArgTypes...)>&, nullptr_t);
+template <Returnable R,
+CopyConstructible... ArgTypes>
+bool operator==(nullptr_t, const
+function<R(ArgTypes...)>&);
+template <Returnable R,
+CopyConstructible... ArgTypes>
+bool operator!=(const
+function<R(ArgTypes...)>&, nullptr_t);
+template <Returnable R,
+CopyConstructible... ArgTypes>
+bool operator!=(nullptr_t, const
+function<R(ArgTypes...)>&);
+template <Returnable R,
+CopyConstructible... ArgTypes>
+void swap(function<R(ArgTypes...)>&,
+function<R(ArgTypes...)>&);
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+208
+<td>
+20.6.17
+<td>
+1
+<td>
+Te
+<td>
+std::hash should be implemented for much more of
+the standard library. In particular for pair, tuple and all the
+standard containers.
+ 
+<td>
+.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+209
+<td>
+20.7
+<td>
+ 
+<td>
+Te
+<td>
+Smart
+pointers cannot be used in constrained templates
+<td>
+Provide constraints for smart pointers
+ 
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+213
+<td>
+20.7.6
+<td>
+ 
+<td>
+Te
+<td>
+std::allocator should be constrained to simplify
+its use on constrained contexts. This library component models
+allocation from free store via the new operator so choose
+constraints to match. The Allocator concept allows for a wider
+variety of allocators that users may choose to supply if their
+allocation model does not require operator new, without impacting
+the requirements of this template.
+ 
+<td>
+The primary
+allocator template should be constrained to require
+ObjectType<T> and FreeStoreAllocatable<T>. Further
+operations to be constrained as required.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+214
+<td>
+20.7.8
+<td>
+ 
+<td>
+Te
+<td>
+raw_storage_iterator needs constraining as an
+iterator adaptor to be safely used in constrained templates
+ 
+<td>
+Constrain the
+raw_storage_iterator template
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+210
+<td>
+20.7.11
+<td>
+ 
+<td>
+Te
+<td>
+Specialized
+algorithms for memory managenment need requirements to be easily
+usable in constrained templates
+<td>
+Provide constraints for all algorithms in
+20.7.11
+ 
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+DE-20
+<td>
+20.7.12
+<td>
+ 
+<td>
+ed
+<td>
+DE-20 The section heading
+and the first sentence use the term "template function", which is
+undefined.
+<td>
+
+Replace "template function"
+by "function template".
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 72
+<td>
+20.7.12
+<td>
+ 
+<td>
+te
+<td>
+bind should support move-only functors
+and bound arguments.
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+DE-21
+<td>
+20.7.12.1.3
+<td>
+ 
+<td>
+te
+<td>
+DE-21 The specification
+for bind claims twice that "the values and types for the bound
+arguments v1, v2, ..., vN are determined as specified below". No
+such specification appears to exist.
+<td>
+Add the missing
+specification in the same section, or add a cross-reference
+indicating the section where the specification appears.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+211
+<td>
+20.7.12.2.3
+<td>
+11
+<td>
+Te
+<td>
+The nullptr_t type was introduced to resolve the
+null pointer literal problem. It should be used for the assignemnt
+operator, as with the constructor and elsewhere through the
+library.
+ 
+<td>
+Change
+signature here and in the synopsis to: unique_ptr&
+operator=(nullptr_t); Strike the sentance an note before the
+Effects clause.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+212
+<td>
+20.7.13.7
+<td>
+ 
+<td>
+Te
+<td>
+The pointer-safety API is nothing to do with smart
+pointers, so does not belong in 20.7.13. In fact it is a set of
+language support features are really belongs in clause 18, with the
+contents declared in a header that deals with language-support of
+memory management.
+ 
+<td>
+Move this
+specification to 18.5. Move the declarations into the header
+<new>.
+<td>
+ 
+<tr valign="top">
+<td>
+DE-22
+<td>
+20.7.16.2
+<td>
+ 
+<td>
+te
+<td>
+DE-22 The conditions for
+deriving from std::unary_function and std::binary_function are
+unclear: The condition would also be satisfied if ArgTypes were
+std::vector<T1>, because it (arguably) "contains" T1.
+<td>
+Consider stating the
+conditions in normative prose instead of in comments in the class
+definition. Use "consists of" instead of "contains". Consider using
+"if and only if" instead of "iff".
+<td>
+ 
+<tr valign="top">
+<td>
+US 73
+<td>
+20.7.18
+<td>
+ 
+<td>
+te
+<td>
+The
+std::reference_closure template is redundant with std::function and
+should be removed.
+ 
+std::reference_closure is
+a premature optimization that provides a limited subset of the
+functionality of std::function intended to improve performance in a
+narrow use case. However, the “parallel application
+performance” benchmark used to motivate the inclusion of
+std::reference_closure was flawed in several ways:
+<ol start="3">
+<li>
+it failed to enable a
+common optimization in std::function (implemented by all vendors),
+exacting a large and unrealistic penalty for copying std::function
+instances, and
+<li>
+it failed to account for
+parallel scheduler overhead or realistically-sized work units, both
+of which would dominate the costs measured by the benchmark in any
+realistic application.</ol>
+ 
+<td>
+Remove 20.7.18
+[func.referenceclosure].
+ 
+Remove 5.1.1 paragraph 12.
+<td>
+ 
+<tr valign="top">
+<td>
+US 74
+<td>
+20.8
+<td>
+ 
+<td>
+te
+<td>
+Scoped allocators
+represent a poor trade-off for standardization, since (1)
+scoped-allocator--aware containers can be implemented outside the
+C++ standard library but used with its algorithms, (2) scoped
+allocators only benefit a tiny proportion of the C++ community
+(since few C++ programmers even use today’s allocators), and
+(3) all C++ users, especially the vast majority of the C++
+community that won’t ever use scoped allocators are forced to
+cope with the interface complexity introduced by scoped allocators.
+In essence, the larger community will suffer to support a very
+small subset of the community who can already implement their own
+data structures outside of the standard library. Therefore, scoped
+allocators should be removed from the working paper.
+Some evidence of the
+complexity introduced by scoped allocators:
+20.3.3, 20.5: large
+increase in the number of pair and tuple constructors
+23: confusing
+“AllocatableElement” requirements throughout.
+ 
+<td>
+Remove support for scoped
+allocators from the working paper. This includes at least the
+following changes:
+ 
+Remove 20.8.3
+[allocator.element.concepts]
+ 
+Remove 20.8.7
+[allocator.adaptor]
+ 
+Remove 20.8.10
+[construct.element]
+ 
+In Clause 23: replace
+requirements naming the AllocatableElement concept with
+requirements naming CopyConstructible, MoveConstructible,
+DefaultConstructible, or Constructible, as appropriate.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 74
+<td>
+20.8.2.2
+<td>
+(a) synopsis (b) after
+¶ 14
+<td>
+te/ed
+<td>
+A concept name is twice
+misspelled.
+<td>
+Change
+“Hasconstructor” to “HasConstructor”
+(twice).
+<td>
+ 
+<tr valign="top">
+<td>
+US 75
+<td>
+20.8.2.2
+<td>
+ 
+<td>
+te
+<td>
+Allocator concepts are
+incomplete
+<td>
+
+See paper:
+http://www.halpernwightsoftware.com/WG21/n2810_allocator_defects.pdf>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 43
+<td>
+20.8.3
+<td>
+ 
+<td>
+ed
+<td>
+Typo.
+"alloc" should be "Alloc"
+<td>
+Correct as follows.
+ 
+auto concept UsesAllocator<typename
+T, typename Alloc> {
+requires Allocator<alloc>;
+typename allocator_type =
+T::allocator_type;
+ 
+should be
+ 
+auto concept UsesAllocator<typename
+T, typename Alloc> {
+requires
+Allocator<Alloc>;
+typename allocator_type =
+T::allocator_type;
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+215
+<td>
+20.8.3.3
+<td>
+6,8
+<td>
+Ed
+<td>
+Extra pair of {}, presumably some formatting code
+gone awry : duration& operator-{-}();
+ 
+<td>
+Remove the {}
+or fix formatting
+<td>
+ 
+<tr valign="top">
+<td>
+US 77
+<td>
+20.8.4
+<td>
+ 
+<td>
+te
+<td>
+Allocator-specific move
+and copy behavior for containers (N2525) complicates a little-used
+and already-complicated portion of the standard library
+(allocators), and breaks the conceptual model of move-constructor
+and move-assignment operations on standard containers being
+efficient operations. The extensions for allocator-specific move
+and copy behavior should be removed from the working paper.
+With the introduction of
+rvalue references, we are teaching programmers that moving from a
+standard container (e.g., a vector<string>) is an efficient,
+constant-time operation. The introduction of N2525 removed that
+guarantee; depending on the behavior of four different traits
+(20.8.4), the complexity of copy and move operations can be
+constant or linear time. This level of customization greatly
+increases the complexity of standard containers, and benefits only
+a tiny fraction of the C++ community.
+ 
+<td>
+Remove 20.8.4.
+ 
+Remove 20.8.5.
+ 
+Remove all references to the facilities in
+20.8.4 and 20.8.5 from clause 23.
+<td>
+ 
+<tr valign="top">
+<td>
+US 78
+<td>
+20.8.12, 20.8.13.2
+<td>
+ 
+<td>
+te
+<td>
+There is
+presently no way to convert directly from a
+<code>shared_ptr</code> to a <code>unique_ptr</code>.
+<td>
+Add an interface that performs the conversion. See
+the attached, Issues with the C++ Standard" paper under Chapter 20,
+"Conversion from <code>shared_ptr</code> to <code>unique_ptr".</code>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 79
+<td>
+20.8.12.2.1
+<td>
+ 
+<td>
+te
+<td>
+[unique.ptr.single.ctor]/5 no longer
+requires for D not to be a pointer type.  This restriction
+needs to be put back in.  Otherwise we have a run time failure
+that could have been caught at compile time:
+ 
+unique_ptr<int, void(*)(void*)>
+p(malloc(sizeof(int)));  // should not compile
+ 
+unique_ptr<int, void(*)(void*)>
+p(malloc(sizeof(int)), free);  // ok
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 44
+<td>
+20.8.13.6
+<td>
+ 
+<td>
+te
+<td>
+The 1st parameter p and 2nd parameter v
+is now shared_ptr<T> *.
+It should be shared_ptr<T>&,
+or if these are shared_ptr<T>* then add the "p shall not be a
+null pointer" at the requires.
+<td>
+Change shared_ptr<T>& or add
+the "p shall not be a null pionter" at the requires.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 45
+<td>
+20.9
+<td>
+ 
+<td>
+te
+<td>
+Rep, Period, Clock and Duration don't
+correspond to concept.
+template <class Rep, class Period =
+ratio<1>> class duration;
+template <class Clock, class Duration =
+typename Clock::duration> class time_point;
+ 
+<td>
+Make concept for Rep, Period, Clock and
+Duration, and fix 20.9 and wait_until and wait_for's template
+parameter at 30.
+<td>
+ 
+<tr valign="top">
+<td>
+US 80
+<td>
+20.9.2.1
+<td>
+Heading
+<td>
+ed
+<td>
+The section heading does
+not describe the contents.
+<td>
+
+Change the heading
+“is_floating_point” to
+“treat_as_floating_point”.
+Optionally adjust the section’s label similarly.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 81
+<td>
+20.9.3
+<td>
+ 
+<td>
+te
+<td>
+chrono::duration is missing the modulous
+operator for both member and non-member arithmetic. This operator
+is useful for finding the position of a duration within a bounded
+time frame. Having it be built in to duration is safer than
+requiring the client to extract and operate directly on the
+duration’s representation as the latter will not enforce the
+correct units of the operation.
+ 
+Ex:
+ 
+milliseconds ms(...);
+microseconds us(...);
+ 
+ms % us; // microseconds
+us % ms; // microseconds
+ms % 5; // milliseconds
+5 % ms; // does not compile
+ 
+<td>
+Add:
+ 
+template <class Rep, class Period =
+ratio<1>>
+class duration {
+public:
+...
+duration&
+operator%(const rep&);
+duration&
+operator%(const duration&);
+..
+};
+ 
+template <class Rep1,
+class Period,
+class Rep2>
+duration<typename
+common_type<
+Rep1, Rep2>::type,
+Period>
+operator%(const
+duration<Rep1, Period>& d, const Rep2& s);
+ 
+template <class Rep1,
+class Period1,
+class Rep2, class
+Period2>
+typename
+common_type<duration<Rep1, Period1>, duration<Rep2,
+Period2>>::type
+operator%(const
+duration<Rep1, Period1>& lhs, const duration<Rep2,
+Period2>& rhs);
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 82
+<td>
+20.9.5.3
+<td>
+after ¶ 1
+<td>
+ed
+<td>
+The code synopsis has a
+minor alignment error.
+<td>
+Align “rep”
+with the other symbols defined in this synopsis.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+216
+<td>
+21
+<td>
+ 
+<td>
+Te
+<td>
+All the
+containers use concepts for their iterator usage, exect for
+basic_string. This needs fixing.
+<td>
+Use concepts
+for iterator template parameters throughout the chapter.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 46
+<td>
+21.2, 21.3
+<td>
+ 
+<td>
+te
+<td>
+The basic_string does not use
+concept.
+<td>
+The "class Alloc" is changed to
+"Allocator Alloc".
+The "class InputIterator" is changed to
+"InputIterator Iter".
+ 
+// 21.3, basic_string:
+template<class charT, class traits =
+char_traits<charT>,
+Allocator Alloc =
+allocator<charT> >
+class basic_string;
+ 
+template<class charT, class traits,
+Allocator Alloc>
+basic_string<charT,traits,Alloc>
+operator+(const
+basic_string<charT,traits,Alloc>& lhs,
+const
+basic_string<charT,traits,Alloc>& rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+basic_string<charT,traits,Alloc>&&
+operator+(basic_string<charT,traits,Alloc>&&
+lhs,
+const
+basic_string<charT,traits,Alloc>& rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+basic_string<charT,traits,Alloc>&&
+operator+(const
+basic_string<charT,traits,Alloc>& lhs,
+basic_string<charT,traits,Alloc>&&
+rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+basic_string<charT,traits,Alloc>&&
+operator+(basic_string<charT,traits,Alloc>&&
+lhs,
+basic_string<charT,traits,Alloc>&&
+rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+basic_string<charT,traits,Alloc>
+operator+(const charT* lhs,
+const
+basic_string<charT,traits,Alloc>& rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+basic_string<charT,traits,Alloc>&&
+operator+(const charT* lhs,
+basic_string<charT,traits,Alloc>&&
+rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+basic_string<charT,traits,Alloc>
+operator+(charT lhs, const
+basic_string<charT,traits,Alloc>& rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+basic_string<charT,traits,Alloc>&&
+operator+(charT lhs,
+basic_string<charT,traits,Alloc>&&
+rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+basic_string<charT,traits,Alloc>
+operator+(const
+basic_string<charT,traits,Alloc>& lhs,
+const charT* rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+basic_string<charT,traits,Alloc>&&
+operator+(basic_string<charT,traits,Alloc>&&
+lhs,
+const charT* rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+basic_string<charT,traits,Alloc>
+operator+(const
+basic_string<charT,traits,Alloc>& lhs, charT
+rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+basic_string<charT,traits,Alloc>&&
+operator+(basic_string<charT,traits,Alloc>&&
+lhs, charT rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+bool operator==(const
+basic_string<charT,traits,Alloc>& lhs,
+const
+basic_string<charT,traits,Alloc>& rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+bool operator==(const charT* lhs,
+const
+basic_string<charT,traits,Alloc>& rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+bool operator==(const
+basic_string<charT,traits,Alloc>& lhs,
+const charT* rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+bool operator!=(const
+basic_string<charT,traits,Alloc>& lhs,
+const
+basic_string<charT,traits,Alloc>& rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+bool operator!=(const charT* lhs,
+const
+basic_string<charT,traits,Alloc>& rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+bool operator!=(const
+basic_string<charT,traits,Alloc>& lhs,
+const charT* rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+bool operator< (const
+basic_string<charT,traits,Alloc>& lhs,
+const
+basic_string<charT,traits,Alloc>& rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+bool operator< (const
+basic_string<charT,traits,Alloc>& lhs,
+const charT* rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+bool operator< (const charT*
+lhs,
+const
+basic_string<charT,traits,Alloc>& rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+bool operator> (const
+basic_string<charT,traits,Alloc>& lhs,
+const
+basic_string<charT,traits,Alloc>& rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+bool operator> (const
+basic_string<charT,traits,Alloc>& lhs,
+const charT* rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+bool operator> (const charT*
+lhs,
+const
+basic_string<charT,traits,Alloc>& rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+bool operator<=(const
+basic_string<charT,traits,Alloc>& lhs,
+const
+basic_string<charT,traits,Alloc>& rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+bool operator<=(const
+basic_string<charT,traits,Alloc>& lhs,
+const charT* rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+bool operator<=(const charT*
+lhs,
+const
+basic_string<charT,traits,Alloc>& rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+bool operator>=(const
+basic_string<charT,traits,Alloc>& lhs,
+const
+basic_string<charT,traits,Alloc>& rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+bool operator>=(const
+basic_string<charT,traits,Alloc>& lhs,
+const charT* rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+bool operator>=(const charT*
+lhs,
+const
+basic_string<charT,traits,Alloc>& rhs);
+ 
+// 21.3.8.8: swap
+template<class charT, class traits,
+Allocator Alloc>
+void
+swap(basic_string<charT,traits,Alloc>& lhs,
+basic_string<charT,traits,Alloc>&
+rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+void
+swap(basic_string<charT,traits,Alloc>&& lhs,
+basic_string<charT,traits,Alloc>&
+rhs);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+void
+swap(basic_string<charT,traits,Alloc>& lhs,
+basic_string<charT,traits,Alloc>&&
+rhs);
+ 
+// 21.3.8.9: inserters and
+extractors
+template<class charT, class traits,
+Allocator Alloc>
+basic_istream<charT,traits>&
+operator>>(basic_istream<charT,traits>&&
+is,
+basic_string<charT,traits,Alloc>&
+str);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+basic_ostream<charT,
+traits>&
+operator<<(basic_ostream<charT,
+traits>&& os,
+const
+basic_string<charT,traits,Alloc>& str);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+basic_istream<charT,traits>&
+getline(basic_istream<charT,traits>&&
+is,
+basic_string<charT,traits,Alloc>&
+str,
+charT delim);
+ 
+template<class charT, class traits,
+Allocator Alloc>
+basic_istream<charT,traits>&
+getline(basic_istream<charT,traits>&&
+is,
+basic_string<charT,traits,Alloc>&
+str);
+ 
+ 
+// 21.3 Class template
+basic_string
+namespace std {
+template<class charT, class traits =
+char_traits<charT>,
+Allocator Alloc =
+allocator<charT> >
+class basic_string {
+public:
+// types:
+typedef traits traits_type;
+typedef typename traits::char_type
+value_type;
+typedef Alloc
+allocator_type;
+typedef typename Alloc::size_type
+size_type;
+typedef typename
+Alloc::difference_type difference_type;
+typedef typename Alloc::reference
+reference;
+typedef typename
+Alloc::const_reference const_reference;
+typedef typename Alloc::pointer
+pointer;
+typedef typename
+Alloc::const_pointer const_pointer;
+typedef implementation-defined iterator;
+// See 23.1
+typedef implementation-defined
+const_iterator; // See 23.1
+typedef
+std::reverse_iterator<iterator> reverse_iterator;
+typedef
+std::reverse_iterator<const_iterator>
+const_reverse_iterator;
+static const size_type npos = -1;
+ 
+// 21.3.2 construct/copy/destroy:
+explicit basic_string(const
+Alloc& a = Alloc());
+basic_string(const basic_string&
+str);
+basic_string(basic_string&&
+str);
+basic_string(const basic_string&
+str, size_type pos, size_type n = npos,
+const Alloc& a =
+Alloc());
+basic_string(const charT* s,
+size_type n, const Alloc& a =
+Alloc());
+basic_string(const charT* s, const
+Alloc& a = Alloc());
+basic_string(size_type n, charT c, const
+Alloc& a = Alloc());
+template<InputIterator
+Iter>
+basic_string(Iter begin,
+Iter end,
+const Alloc& a =
+Alloc());
+basic_string(initializer_list<charT>, const
+Alloc& = Alloc());
+basic_string(const basic_string&,
+const Alloc&);
+basic_string(basic_string&&,
+const Alloc&);
+~basic_string();
+basic_string& operator=(const
+basic_string& str);
+basic_string&
+operator=(basic_string&& str);
+basic_string& operator=(const charT*
+s);
+basic_string& operator=(charT
+c);
+basic_string&
+operator=(initializer_list<charT>);
+ 
+// 21.3.3 iterators:
+...
+ 
+// 21.3.4 capacity:
+...
+ 
+// 21.3.5 element access:
+...
+ 
+// 21.3.6 modifiers:
+...
+ 
+basic_string& append(const
+basic_string& str);
+basic_string& append(const
+basic_string& str, size_type pos,
+size_type n);
+basic_string& append(const charT* s,
+size_type n);
+basic_string& append(const charT*
+s);
+basic_string& append(size_type n,
+charT c);
+template<InputIterator
+Iter>
+basic_string& append(Iter
+first, Iter last);
+basic_string&
+append(initializer_list<charT>);
+void push_back(charT c);
+ 
+basic_string& assign(const
+basic_string& str);
+basic_string&
+assign(basic_string&& str);
+basic_string& assign(const
+basic_string& str, size_type pos,
+size_type n);
+basic_string& assign(const charT* s,
+size_type n);
+basic_string& assign(const charT*
+s);
+basic_string& assign(size_type n,
+charT c);
+template<InputIterator
+Iter>
+basic_string& assign(Iter
+first, Iter last);
+basic_string&
+assign(initializer_list<charT>);
+ 
+basic_string& insert(size_type pos1,
+const basic_string& str);
+basic_string& insert(size_type pos1,
+const basic_string& str,
+size_type pos2, size_type n);
+basic_string& insert(size_type pos,
+const charT* s, size_type n);
+basic_string& insert(size_type pos,
+const charT* s);
+basic_string& insert(size_type pos,
+size_type n, charT c);
+iterator insert(const_iterator p, charT
+c);
+void insert(const_iterator p, size_type
+n, charT c);
+template<InputIterator
+Iter>
+void insert(const_iterator p,
+Iter first, Iter last);
+void insert(const_iterator p,
+initializer_list<charT>);
+ 
+...
+basic_string& replace(size_type
+pos1, size_type n1,
+const basic_string& str);
+basic_string& replace(size_type
+pos1, size_type n1,
+const basic_string& str,
+size_type pos2, size_type n2);
+basic_string& replace(size_type pos,
+size_type n1, const charT* s,
+size_type n2);
+basic_string& replace(size_type pos,
+size_type n1, const charT* s);
+basic_string& replace(size_type pos,
+size_type n1, size_type n2,
+charT c);
+basic_string& replace(iterator i1,
+iterator i2,
+const basic_string& str);
+basic_string& replace(iterator i1,
+iterator i2, const charT* s,
+size_type n);
+basic_string& replace(iterator i1,
+iterator i2, const charT* s);
+basic_string& replace(iterator i1,
+iterator i2,
+size_type n, charT c);
+template<InputIterator
+Iter>
+basic_string& replace(iterator i1,
+iterator i2,
+Iter j1, Iter j2);
+basic_string& replace(iterator,
+iterator, initializer_list<charT>);
+ 
+...
+ 
+// 21.3.7 string operations:
+...
+ 
+template <class charT, class traits,
+Allocator Alloc>
+struct
+constructible_with_allocator_suffix<
+basic_string<charT, traits, Alloc>
+> : true_type { };
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 47
+<td>
+21.3
+<td>
+ 
+<td>
+ed
+<td>
+Typo. Missing ”>”
+template <class charT, class traits,
+Allocator Alloc
+ 
+should be
+ 
+template <class charT, class traits,
+Allocator Alloc>
+ 
+<td>
+Correct typo.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 48
+<td>
+21.3
+<td>
+ 
+<td>
+te
+<td>
+char_traits does not use concept.
+For example, create CharTraits concept
+and change as follows:
+ 
+template<class charT,
+CharTraits traits = char_traits<charT>,
+class Allocator = allocator<charT>
+>
+class basic_string {
+ 
+<td>
+Add a concept for char_traits.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+217
+<td>
+21.3
+<td>
+ 
+<td>
+Ed
+<td>
+basic_string
+refers to constructible_with_allocator_suffix, which I thought was
+removed?
+<td>
+Remove the lines: template <class charT, class
+traits, class Alloc struct constructible_with_allocator_suffix<
+basic_string<charT, traits, Alloc> > : true_type {
+};
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+218
+<td>
+21.3.1
+<td>
+3
+<td>
+Te
+<td>
+The identity "&*(s.begin() + n) ==
+&*s.begin() + n" relies on operator& doing the "right
+thing", which (AFAICS) there is no requirement for. See my comment
+under clauses "23.2.1, 23.2.6" (p1 in both cases) - this is the
+same issue, but I've created a separate comment for basic_string
+because it is in a different chapter.
+ 
+<td>
+See my
+recommendations for "23.2.1, 23.2.6".
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+219
+<td>
+21.3.6.6
+[string.replace]
+<td>
+11
+<td>
+Ed
+<td>
+Effects
+refers to "whose first begin() - i1 elements" However i1 is greater
+than begin()...
+<td>
+Effects
+refers to "whose first i1 - begin() elements"
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+220
+<td>
+21.3.8.9
+<td>
+ 
+<td>
+Te
+<td>
+The operator<< for basic_string takes the
+output stream by r-value reference. This is different from the same
+operator for error_code (19.4.2.6), bitset (20.2.6.3), shared_ptr
+(20.7.13.2.8), complex (26.3.6) and sub_match (28.4)
+ 
+<td>
+Use the same
+reference type for the all the library types. This should be the
+r-value reference. There are other places in the standard where
+TR1, and new classes, did not receive an 'R-value' update.
+<td>
+ 
+<tr valign="top">
+<td>
+FR 33
+<td>
+22.1.1 [locale]
+<td>
+3
+<td>
+ed
+<td>
+ios_base::iostate err = 0;
+ 
+iostate is a bitmask type and so could be
+an enumeration. Probably using
+goodbit is the solution.
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 49
+<td>
+22.1.3.2.2
+<td>
+ 
+<td>
+te
+<td>
+codecvt does not use concept. For
+example, create CodeConvert concept and change as follows.
+template<CodeConvert Codecvt,
+class Elem = wchar_t> class wstring_convert {
+<td>
+Add a concept for codecvt.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 50
+<td>
+22.1.3.2.2
+<td>
+ 
+<td>
+te
+<td>
+Add custom allocator parameter to
+wstring_convert, since we cannot allocate memory for strings from a
+custom allocator.
+<td>
+Correct as follows.
+template<class Codecvt, class Elem =
+wchar_t> class wstring_convert {
+public:
+typedef std::basic_string<char>
+byte_string;
+typedef std::basic_string<Elem>
+wide_string;
+ 
+should be
+ 
+template<class Codecvt, class Elem =
+wchar_t,
+Allocator WideAllocator =
+allocator<Elem>,
+Allocator ByteAllocator =
+allocator<char>>
+class wstring_convert {
+public:
+typedef std::basic_string<char,
+char_traits<char>, ByteAllocator>
+byte_string;
+typedef std::basic_string<Elem,
+char_traits<Elem>, WideAllocator>
+wide_string;
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+FI 4
+<td>
+
+22.2.1.4.1
+22.2.1.4.2
+<td>
+ 
+<td>
+ed
+<td>
+<tt>to_end and to_limit are both used. Only one is
+needed.</tt>
+<td>
+Change to_limit to
+to_end.
+<td>
+ 
+<tr valign="top">
+<td>
+FI 5
+<td>
+<tt>22.2.1.4.2</tt>
+<td>
+#3
+<td>
+ed
+<td>
+
+<tt>[ Note: As a result of operations on state, it
+can return ok or partial and set next == from and to_next != to.
+—end note ]</tt> 
+ 
+
+<tt>"next" should be
+"from_next."</tt>
+
+<tt>Also, the sentence applies to all the examples,
+including do_in and do_out.</tt>
+<tt>Reasoning: When reading one element of
+multibyte source data such as UTF-8, it is possible that from_next
+is incremented, to_next is unaltered, state is altered and return
+value is partial. 
+When reading one element of wide character data, the output can be
+several multibyte characters, so it is possible that from_next is
+unaltered, to_next is advanced, state is altered and return value
+is partial.</tt>
+<td>
+<tt>[ Note: As a result of operations on state,
+do_in and do_out can return</tt> 
+<tt>ok or partial and set from_next
+== from and/or to_next != to. —end</tt> 
+<tt>note ]</tt>
+<td>
+ 
+<tr valign="top">
+<td>
+FI 6
+<td>
+
+22.2.1.5
+See also 22.2.1.4
+(1,2,3)
+<td>
+ 
+<td>
+te
+<td>
+
+<tt>codecvt_byname is only specified to work with
+locale names. There is no built-in means to find a codecvt with a
+character set's name. A locale and a character set are not the
+same. If the user has data which is encoded in a certain character
+set and she wants to create a codecvt which can convert from that
+character set to another one, she must iterate through locales to
+find one, or use external means (iconv, ICU's uconv). Specifying a
+locale with the character set is not a suitable solution, since
+there is no built-in mapping from character sets to locales. It is
+only possible to inquire the character set once the locale is
+known.</tt>
+ 
+<td>
+<tt>There should be a built-in means to find a
+codecvt with a pair of character set names.</tt>
+<td>
+ 
+<tr valign="top">
+<td>
+FI 7
+<td>
+22.2.1.4
+<td>
+1,2,3
+<td>
+ed
+<td>
+
+The word "codeset" is used,
+whereas the word "character set" is used elsewhere in the text. The
+words are intended to convey the same concept, so only one should
+be used (or always both together).
+ 
+<td>
+Change "codeset" to
+"character set."
+<td>
+ 
+<tr valign="top">
+<td>
+JP 51
+<td>
+22.2.5.1.1
+<td>
+7th paragraph, 1st line
+<td>
+ed
+<td>
+A parameter `end’ should be
+`fmtend’. 
+get() function had two `end’ parameters at N2321.
+iter_type get (iter_type s, iter_type
+end, ios_base& f, ios_base::iostate& err, tm* t, const
+char_type* fmt, const char_type *end) const;
+The function prototype of get() has been corrected
+at N2800, but a Requires statement still refers `end’
+parameter.
+ 
+<td>
+Correct as follows.
+Requires: [fmt,end) shall be a valid
+range.
+ 
+should be
+ 
+ 
+Requires: [fmt,fmtend) shall be a valid
+range.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 52
+<td>
+22.2.5.1, 22.2.5.2, 22.2.6.1
+<td>
+ 
+<td>
+te
+<td>
+InputIterator does not use
+concept.
+<td>
+Correct as follows.
+ 
+22.2.5.1
+ 
+template <class charT, class
+InputIterator = istreambuf_iterator<charT> >
+class time_get : public locale::facet,
+public time_base {
+public:
+typedef charT char_type;
+typedef InputIterator iter_type;
+ 
+should be
+ 
+template <class charT,
+InputIterator InputIter = istreambuf_iterator<charT>
+>
+class time_get : public locale::facet,
+public time_base {
+public:
+typedef charT char_type;
+typedef InputIter
+iter_type;
+ 
+ 
+22.2.5.2
+ 
+template <class charT, class
+InputIterator = istreambuf_iterator<charT> >
+class time_get_byname : public
+time_get<charT, InputIterator> {
+public:
+typedef time_base::dateorder
+dateorder;
+typedef InputIterator iter_type;
+ 
+should be
+ 
+template <class charT,
+InputIterator InputIter = istreambuf_iterator<charT>
+>
+class time_get_byname : public
+time_get<charT, InputIter> {
+public:
+typedef time_base::dateorder
+dateorder;
+typedef InputIter
+iter_type;
+ 
+ 
+22.2.6.1
+ 
+template <class charT,
+class InputIterator =
+istreambuf_iterator<charT> >
+class money_get : public locale::facet
+{
+public:
+typedef charT char_type;
+typedef InputIterator iter_type;
+ 
+should be
+ 
+template <class charT,
+InputIterator InputIter =
+istreambuf_iterator<charT> >
+class money_get : public locale::facet
+{
+public:
+typedef charT char_type;
+typedef InputIter
+iter_type;
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 53
+<td>
+22.2.5.3 , 22.2.5.4
+<td>
+ 
+<td>
+te
+<td>
+OutputIterator does not use
+concept.
+<td>
+Correct as follows.
+ 
+22.2.5.3
+ 
+template <class charT, class
+OutputIterator = ostreambuf_iterator<charT> >
+class time_put : public locale::facet
+{
+public:
+typedef charT char_type;
+typedef OutputIterator iter_type;
+ 
+　should be
+ 
+template <class charT,
+OutputIterator OutputIter = ostreambuf_iterator<charT>
+>
+class time_put : public locale::facet
+{
+public:
+typedef charT char_type;
+typedef OutputIter
+iter_type;
+ 
+ 
+22.2.5.4
+ 
+template <class charT, class
+OutputIterator = ostreambuf_iterator<charT> >
+class time_put_byname : public
+time_put<charT, OutputIterator>
+{
+public:
+typedef charT char_type;
+typedef OutputIterator iter_type;
+ 
+should be
+ 
+template <class charT,
+OutputIterator OutputIter = ostreambuf_iterator<charT>
+>
+class time_put_byname : public
+time_put<charT, OutputIter>
+{
+public:
+typedef charT char_type;
+typedef OutputIter iter_type;
+<td>
+ 
+<tr valign="top">
+<td>
+JP 54
+<td>
+23
+<td>
+2nd paragraph, Table 79
+ 
+<td>
+ed
+<td>
+There is not <forward_list> in
+Table 79.
+<td>
+Add <forward_list> between
+<deque> and <list>.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+221
+<td>
+23
+<td>
+Table
+79
+<td>
+Ed
+<td>
+The table is
+missing the new <forward_list> header.
+<td>
+Add <forward_list> to the table for sequence
+containers. Alternative (technical) solution might be to merge
+<forward_list> into <list>.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+222
+<td>
+23
+<td>
+ 
+<td>
+Te
+<td>
+It is not clear what purpose the Requirement
+tables serve in the Containers clause. Are they the definition of a
+library Container? Or simply a conventient shorthand to factor
+common semantics into a single place, simplifying the description
+of each subsequent container? This becomes an issue for
+'containers' like array, which does not meet the
+default-construct-to-empty requirement, or forward_list which does
+not support the size operation. Are these components no longer
+containers? Does that mean the remaining requirements don't apply?
+Or are these contradictions that need fixing, despite being a clear
+design decision?
+ 
+<td>
+Clarify all
+the tables in 23.1 are there as a convenience for documentation,
+rather than a strict set of requirements. Containers should be
+allowed to relax specific requirements if they call attention to
+them in their documentation. The introductory text for array should
+be expanded to mention a default constructed array is not empty,
+and forward_list introduction should mention it does not provide
+the required size operation as it cannot be implemented
+efficiently.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 55
+<td>
+23.1.1
+<td>
+3rd paragraph, 4th line
+ 
+<td>
+ed
+<td>
+It seems that “the
+MinimalAllocator concep” is the typo of “the
+MinimalAllocator concept”.
+<td>
+Change to … models the MinimalAllocator
+concept.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+223
+<td>
+23.1.1
+<td>
+3
+<td>
+Te
+<td>
+The library does not define the MinimalAllocator
+or ScopedAllocator concepts, these were part of an earlier
+Allocators proposal that was rejected.
+ 
+<td>
+Remove the
+references to MinimalAllocator and ScopedAllocator, or add
+definitions for these concepts to clause 20.7.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+224
+<td>
+23.1.1
+<td>
+8
+<td>
+Te
+<td>
+This
+paragraph implicitly requires all containers in clause 23 to
+support allocators, which std::array does not.
+<td>
+Add an 'unless otherwise specified' rider
+somewhere in p8, or move the whole array container from clause 23
+[containers] to clause 20 [utilies] to accompany bitset, pair and
+tuple.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+225
+<td>
+23.1.1
+<td>
+Table
+81
+<td>
+Ed
+<td>
+Inconsistent words used to say the same thing.
+Table 80 describes iterator/const_iterator typedef as returning an
+"iterator type whose value type is T". Table 81 expresses the same
+idea as an "iterator type pointing to T". Express identical ideas
+with the same words to avoid accidentally introducing subtlety and
+confusion
+ 
+<td>
+Change return
+types for X::(const)_reverse_iterator to say "iterator type whose
+value type is (const) T".
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+226
+<td>
+23.1.1
+<td>
+10
+<td>
+Te
+<td>
+<array> must be added to this list. In
+particular it doesn't satisfy: - no swap() function invalidates any
+references, pointers, or iterators referring to the elements of the
+containers being swapped. and probably doesn't satisfy: — no
+swap() function throws an exception.
+ 
+<td>
+If
+<array> remains a container, this will have to also reference
+array, which will then have to say which of these points it
+satisfies.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+227
+<td>
+23.1.1
+<td>
+Table
+80
+<td>
+Ed
+<td>
+The
+post-condition for a = rv uses the word “construction”
+when it means “assignment”
+<td>
+Replace the word “construction” with
+the word “assignment”
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+228
+<td>
+23.1.1
+<td>
+3
+<td>
+Ed
+<td>
+Line 4 contains a spelling mistake in the fragment
+"MinimalAllocator concep."
+ 
+<td>
+Replace
+"concep" with "concept"
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+229
+<td>
+23.1.1
+<td>
+3
+<td>
+Ed
+<td>
+The fragment
+"A container may directly call constructors" is not technically
+correct as constructors are not callable.
+<td>
+Replace "A container may directly call
+constructors and destructors for its stored objects" with something
+similar to "A container may directly construct its stored objects
+and call destructors for its stored objects"
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+230
+<td>
+23.1.2
+<td>
+1
+<td>
+Te
+<td>
+“implementations shall consider the following
+functions to be const” - what does this mean? I don't
+understand what it means by implementations considering the
+functions to be const – surely they are either declared const
+or not?
+ 
+<td>
+Clarify what
+is meant and what requirements an implementation must
+satisfy.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 56
+<td>
+23.1.3
+<td>
+12th paragraph, Table 84
+<td>
+ed
+<td>
+`array’ is unstated in Table 84 -
+Optional sequence container operations.
+<td>
+Add `array’ to Container field for
+the following Expression.
+a.front()
+a.back()
+a[n]
+a.at(n)
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+231
+<td>
+23.1.3
+<td>
+9-11
+<td>
+Te
+<td>
+These paragraphs are redundant now that Concepts
+define what it means to be an Iterator and guide overload
+resolution accordingly.
+ 
+<td>
+Strike
+23.1.3p9-11. Make sure std::basic_string has constraints similar to
+std::vector to meet this old guarantee.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+232
+<td>
+23.1.3
+<td>
+Table
+84
+<td>
+Te
+<td>
+match_results may follow the requirements but is
+not listed a general purpose library container.
+ 
+<td>
+Remove
+reference to match_results against a[n] operation
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+233
+<td>
+23.1.3
+<td>
+Table
+84
+<td>
+Te
+<td>
+Add
+references to the new containers.
+<td>
+Add reference to array to the rows for: a.front(),
+a. back(), a[n] a.at(n). Add reference to forward_list to the rows
+for: a.front(), a.emplace_front(args), a.push_front(t),
+a.push_front(rv), a.pop_front(). Add reference to basic_string to
+the row for: a.at(n).
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+234
+<td>
+23.1.3
+<td>
+Table
+84
+<td>
+Te
+<td>
+Ther reference to iterator in semantics for back
+should also allow for const_iterator when called on a
+const-qualified container. This would be ugly to specify in the 03
+standard, but is quite easy with the addition of auto in this new
+standard.
+ 
+<td>
+Replace
+iterator with auto in semantics for back: { auto tmp = a.end();
+--tmp; return *tmp; }
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+235
+<td>
+23.1.3
+<td>
+1
+<td>
+Ed
+<td>
+“The
+library provides three basic kinds of sequence containers: vector,
+list, and deque” - text appears to be out of date re addition
+of array and forward_list
+<td>
+Change the text to read: “The library
+provides five basic kinds of sequence containers: array, deque,
+forward_list, list and vector”.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+236
+<td>
+23.1.3
+<td>
+2
+<td>
+Ed
+<td>
+[ I've moved (1) into a separate comment because I
+believe it is editorial in the simple sense, whereas (2) and (3)
+are not so straight forward ] (2) “vector is the type of
+sequence container that should be used by default” -- As I
+understand it vector was considered first port of call because the
+things it has in common with the native array make programmers
+(especially those new to the container library) feel like they are
+on familiar territory. However, we now have the array container, so
+I think this should be recommended as the first port of call. (3)
+This paragraph is actually giving guidance on the use of the
+containers and should not be normative text
+ 
+<td>
+Remove this
+paragraph
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+237
+<td>
+23.1.3
+<td>
+2
+<td>
+Ed
+<td>
+vector, list,
+and deque offer the programmer different complexity trade-offs and
+should be used accordingly - this ignores array and
+forward_list
+<td>
+Modify the text to read: "array, deque,
+forward_list, list and vector offer the programmer different
+complexity trade-offs and should be used accordingly"
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+238
+<td>
+23.1.4
+<td>
+6
+<td>
+Te
+<td>
+Leaving it unspecified whether or not iterator and
+const_iterator are the same type is dangerous, as user code may or
+may not violate the One Definition Rule by providing overloads for
+both types. It is probably too late to specify a single behaviour,
+but implementors should document what to expect. Observing that
+problems can be avoided by users restricting themselves to using
+const_iterator, add a note to that effect.
+ 
+<td>
+Change
+'unspecified' to 'implementation defined'. Add "[Note: As
+itererator and const_iterator have identical semantics in this
+case, and iterator is convertible to const_iterator, users can
+avoid violating the One Definition Rule by always using
+const_iterator in their function parameter lists -- end
+note]
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+239
+<td>
+23.1.4
+<td>
+85
+<td>
+Te
+<td>
+It is not
+possible to take a move-only key out of an unordered container,
+such as (multi)set or (multi)map, or the new hashed
+containers.
+<td>
+Add below a.erase(q), a.extract(q), with the
+following notation: a.extract(q), Return type pair<key,
+iterator> Extracts the element pointed to by q and erases it
+from the set. Returns a pair containing the value pointed to by q
+and an iterator pointing to the element immediately following q
+prior to the element being erased. If no such element
+exists,returns a.end().
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+240
+<td>
+23.1.6.1
+<td>
+12
+<td>
+Te
+<td>
+The axiom EmplacePushEquivalence should be
+asserting the stronger contract that emplace and insert return the
+same iterator value, not just iterators that dereference to the
+same value. This is a similar statement that is easier to express
+and should be equivalent - the idea that insert and emplace might
+return iterator values that do not compare equal but point to the
+same element should fail somewhere in the iterator concepts. Also,
+this axiom should be renamed to reflect its connection with insert,
+rather than push_front/push_back,
+ 
+<td>
+Remove the *
+to deference the returned iterator either side of the == in the
+EmplacePushEquivalence axiom, rename the axiom
+EmplacementInsertionEquivalence : requires
+InsertionContainer<C> && Constructible<value_type,
+Args...> axiom EmplacementInsertionEquivalence(C c,
+const_iterator position, Args... args) { emplace(c, position,
+args...) == insert(c, position, value_type(args...)); }
+<td>
+ 
+<tr valign="top">
+<td>
+JP 57
+<td>
+23.1.6.3
+<td>
+1st paragraph, 4th line
+ 
+<td>
+ed
+<td>
+Typo, duplicated "to"
+"to to model insertion container
+concepts."
+<td>
+Remove one.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+241
+<td>
+23.2.1
+<td>
+ 
+<td>
+Te
+<td>
+std::array does not have an allocator, so need to
+document an exception to the requirements of 23.1.1p3
+ 
+<td>
+add exception
+to 23.1.1p3
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+242
+<td>
+23.2.1
+<td>
+3
+<td>
+Ed
+<td>
+std::
+qualification no longer needed for reverse_iterator.
+<td>
+remove std:: qualification from
+std::reverse_iterator<iterator> and
+std::reverse_iterator<const_iterator>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+243
+<td>
+23.2.1
+<td>
+3
+<td>
+Te
+<td>
+Most containers, and types in general have 3
+swaps: swap(T&, T&) swap(T&&, T&) swap(T&,
+T&&) But array only has swap(T&, T&).
+ 
+<td>
+add the other
+two swaps.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+244
+<td>
+23.2.1,
+23.2.6
+<td>
+1
+<td>
+Te
+<td>
+The validity of the expression &a[n] ==
+&a[0] + n is contingent on operator& doing the “right
+thing” (as captured by the CopyConstructible requirements in
+table 30 in C++2003). However this constraint has been lost in the
+Concepts of C++0x. This applies to vector and array (it actually
+applies to string also, but that's a different chapter, so I'll
+file a separate comment there and cross-reference).
+ 
+<td>
+Define a
+ContiguousStrorage and apply it to vector,array and string. The
+Concept (supplied by Alisdair M) looks like this: Concept<
+typename C > ContiguousStrorage { requires Container<C>;
+typename value_type = C::value_type; value_type * data( C ); axiom
+Contiguous { C c; true = equal_ranges( data( c), data(c) + size(c),
+begin(c)); } };
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+245
+<td>
+23.2.3
+<td>
+2
+<td>
+Te
+<td>
+The predicate
+types used in special member function of forward_list should be
+CopyConstructible, as per the algorithms of the same name. Note: an
+alternate solution would be to require these callable concepts to
+be CopyConstructible in clause 20, which would simplify the library
+specification in general. See earlier comment for details, that
+would render this one redundant.
+<td>
+Add CopyConstructible requirement to the following
+signatures: template <Predicate<auto, T> Pred> requires
+CopyConstructible<Pred> void remove_if(Pred pred); template
+<EquivalenceRelation<auto, T> BinaryPredicate> requires
+CopyConstructible<BinaryPredicate> void
+unique(BinaryPredicate binary_pred); template
+<StrictWeakOrder<auto, T> Compare> requires
+CopyConstructible<Compare> void
+merge(forward_list<T,Alloc>&& x, Compare comp);
+template <StrictWeakOrder<auto, T> Compare> requires
+CopyConstructible<Compare> void sort(Compare comp);
+ 
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 58
+<td>
+23.2.3.2
+<td>
+1st line before 1st paragraph
+ 
+<td>
+ed
+<td>
+Unnecessary "{" exists before a word
+iterator like "{iterator before_begin()".
+<td>
+Remove "{"
+<td>
+ 
+<tr valign="top">
+<td>
+JP 59
+<td>
+23.2.4.4
+<td>
+ 
+<td>
+ed
+<td>
+Types of the third and forth parameter
+of splice() are iterator at 23.2.4.4, though types of them are
+const_iterator at 23.2.4. (They are both const_iterator on
+N2350)
+<td>
+Correct as follows.
+void splice(const_iterator position,
+list<T,Allocator>&& x, iterator i);
+void splice(const_iterator position,
+list<T,Allocator>&& x,
+iterator first, iterator last);
+ 
+should be
+ 
+void splice(const_iterator position,
+list<T,Allocator>&& x, const_iterator i);
+void splice(const_iterator position,
+list<T,Allocator>&& x,
+const_iterator first, const_iterator last);
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 83
+<td>
+23.2.6.2
+<td>
+7
+<td>
+ed
+<td>
+"shrink_to_fint" should be
+"shrink_to_fit".
+ 
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+246
+<td>
+23.3.2.2
+<td>
+ 
+<td>
+Ed
+<td>
+The content of this sub-clause is purely trying to
+describe in words the effect of the requires clauses on these
+operations, now that we have Concepts. As such, the desctiption is
+more confusing than the signature itself. The semantic for these
+functions is adequately covered in the requirements tables in
+23.1.4.
+ 
+<td>
+Strike
+23.3.2.2 entirely. (but do NOT strike these signatures from the
+class template definition!)
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+247
+<td>
+24.1
+<td>
+ 
+<td>
+Ge
+<td>
+Iterator concepts are not extensive enough to
+merit a whole new header, and should be merged into
+<concpts>. This is particularly important for supporting the
+new for loop syntax which requires access to the Range concept. The
+required header to enable this syntax shoud have a simple name,
+like <concepts>, rather than something awkward to type like
+<iterator_concepts>.
+ 
+<td>
+Move the
+concepts of <iterator_concepts> into the <concepts>
+header. We take no position on moving the text from Clause 24 to
+Clause 20 though.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+248
+<td>
+24.1
+<td>
+6
+<td>
+Ed
+<td>
+The text "so for any iterator type there is an
+iterator value that points past the last element of a corresponding
+container" is slightly misleading. Iterators can refer into
+generalised ranges and sequences, not just containers. A broader
+term than 'container' should be used.
+ 
+<td>
+Replace the
+reference to container with a more appropriate concept
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+250
+<td>
+24.1.1
+<td>
+ 
+<td>
+Te
+<td>
+A default
+implementation should be supplied for the post-increment operator
+to simplify implementation of iterators by users.
+<td>
+Copy the
+Effects clause into the concept description as the default
+implementation. Assumes a default value for
+postincrement_result
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+251
+<td>
+24.1.1
+<td>
+3
+<td>
+Te
+<td>
+The post-increment operator is dangerous for a
+general InputIterator. The multi-pass guarantees that make it
+meaningful are defined as part of the ForwardIterator refinement.
+Any change will affect only constrained templates that have not yet
+been written, so should not break existing user iterators which
+remain free to add these operations. This change will also affect
+the generalised OutputIterator, although there is no percieved need
+for the post-increment operator in this case either.
+ 
+<td>
+Move
+declaration of postincrement operator and postincrement_result type
+from Interator concept to the ForwardIterator concept
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+252
+ 
+<td>
+24.1.2
+<td>
+3
+<td>
+Ed
+<td>
+istream_iterator is not a class, but a class
+template
+<td>
+Change
+'class' to 'class template' in the note.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+253
+<td>
+24.1.3
+<td>
+1
+<td>
+Ed
+<td>
+First sentance does not make gramatical sense,
+Seems to be missing the words 'if it' by comparison with similar
+sentance in other subsections
+ 
+<td>
+Add the words
+'if it' : "X satisfies the requirements of an output iterator IF IT
+meets the syntactic and semantic requirements"
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+254
+<td>
+24.1.3
+<td>
+5
+<td>
+Te
+<td>
+This postcondition for pre-increment operator
+should be written as an axiom
+ 
+<td>
+Move the
+postcondition into the concept definition as an axiom
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+255
+<td>
+24.1.4
+<td>
+4
+<td>
+Te
+<td>
+This postcondition for pre-increment operator
+should be written as an axiom
+ 
+<td>
+Move the
+postcondition into the concept definition as an axiom
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+256
+<td>
+24.1.5
+<td>
+3, 4,
+5
+<td>
+Te
+<td>
+The
+relationship between pre- and post- decrement should be expressed
+as an axiom.
+<td>
+Move the text specification of pre/post-conditions
+and behaviour into an axiom within the BidirectionalIterator
+concept
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+257
+<td>
+24.1.5
+<td>
+ 
+<td>
+Te
+<td>
+There is a reasonable default for
+postdecrement_result type, which is X. X is required to be regular,
+therefore CopyConstructible and a valid ResultType. Together with
+the next comment this simplifies user defined iterator
+implentations
+ 
+<td>
+Add the
+default : typename postincrement_result = X;
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+258
+<td>
+24.1.5
+<td>
+ 
+<td>
+Te
+<td>
+A default implementation should be supplied for
+the post-decrement operator to simplify implementation of iterators
+by users.
+ 
+<td>
+Copy the
+Effects clause into the concept description as the default
+implementation. Assumes a default value for
+postincrement_result
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+259
+<td>
+24.1.5
+<td>
+ 
+<td>
+Te
+<td>
+postdecrement_result is effectively returning a
+copy of the original iterator value, so should have similar
+constraints, rather than just HasDereference. If Concepts do not
+support this circularity of definition suggest that concepts
+feature may want a little more work
+ 
+<td>
+Add the
+requirement: requires Iterator< postdecrement_result
+>;
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+260
+<td>
+24.1.5
+<td>
+6
+<td>
+Te
+<td>
+The effects
+clause for post-decrement iterator should be available as an axiom
+and a default implementation, where the compiler can make better
+use of it.
+<td>
+Move the Effects clause into the
+BidirectionalIterator concept definition as an axiom, and as the
+default implementation for the operation.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+249
+<td>
+24.1.6
+<td>
+2
+<td>
+Te
+<td>
+The semantic for operator+= should also be
+provided as a default implementation to simplify implementation of
+user-defined iterators
+ 
+<td>
+Copy the text
+from the effects clause into the RandomAccessIterator concept as
+the default implementaiton.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+261
+<td>
+24.1.6
+<td>
+ 
+<td>
+Te
+<td>
+To simplify user defined random access iterator
+types, the subscript_reference type should default to
+reference
+ 
+<td>
+typename
+subscript_reference = reference;
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+262
+<td>
+24.1.6
+<td>
+3,
+4
+<td>
+Te
+<td>
+Effects and
+post-conditions for operator+ are more useful if expressed as
+axioms, and supplied as default implementations.
+<td>
+Move the effects and Postcondition definitions
+into the RandomAccessIterator concept and copy the code in the
+specification as the default implementation of these
+operations.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+263
+<td>
+24.1.6
+<td>
+5
+<td>
+Te
+<td>
+This
+requirement on operator-= would be better expressed as a default
+implementation in the concept, with a matching axiom
+<td>
+Move the specification for operator-= from the
+returns clause into an axiom and default implementation within the
+RandomAccessIterator concept
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+264
+<td>
+24.1.6
+<td>
+6
+<td>
+Te
+<td>
+Effects
+clauses are better expressed as axioms where possible.
+<td>
+Move code in operator- effects clause into
+RandomAccessIterator concept as both a default implementation and
+an axiom
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+265
+<td>
+24.1.6
+<td>
+8
+<td>
+Te
+<td>
+This effects clause is nonesense. It looks more
+like an axiom stating equivalence, and certainly an effects clause
+cannot change the state of two arguments passed by const
+reference
+ 
+<td>
+Strike the
+Effects clause
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+266
+<td>
+24.1.6
+<td>
+9
+<td>
+Te
+<td>
+This sentance
+should be provided as a default definition, along with a matching
+axiom
+<td>
+Move the Returns clause into the spefication for
+RandomAccessIterator operator- as a default implementation. Move
+the Effects clause as the matching axiom.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+267
+<td>
+24.1.6
+<td>
+24.1.6
+<td>
+Te
+<td>
+The code in the Requires clause for
+RandomAccessIterator operator[] would be better expressed as an
+axiom.
+ 
+<td>
+Rewrite the
+Requires clause as an axiom in the RandomAccessIterator
+concept
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+268
+<td>
+24.1.6
+<td>
+12
+<td>
+Ed
+<td>
+This note is potentialy confusing as __far enters
+the syntax as a clear language extension, but the note treats it as
+a regular part of the grammar. It might be better expressed using
+attributes in the current wording.
+ 
+<td>
+Clean up the
+note to either avoid using language extension, or spell out this is
+a constraint to support extensions.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 60
+<td>
+24.1.8
+<td>
+1st paragraph
+<td>
+te
+<td>
+Capability of an iterator is too much
+restricted by concept.
+ 
+Concept of std::Range is defined
+as:
+ 
+concept Range<typename T> {
+InputIterator iterator;
+iterator begin(T&);
+iterator end(T&);
+}
+ 
+So the following code generates an
+error.
+ 
+template <std::Range Rng>
+void sort(Rng& r)
+{
+
+// error! Rng::iterator does
+not satisfy requirements of a random
+
+// access iterator.
+std::sort(begin(r), end(r));
+}
+ 
+std::vector<int> v; //
+vector::iterator is a random access iterator.
+sort(v);
+ 
+This is because the concept of an
+iterator of std::Range is InputIterator. For this reason, a random
+access iterator loses its capability when passed to a std::Range
+parameter.
+ 
+To be able to work the above code, we
+need to write as follows:
+ 
+template <std::Range T>
+requires
+std::RandomAccessIterator<T::iterator> &&
+std::ShuffleIterator<T::iterator>
+&&
+std::LessThanComparable<T::iterator::value_type>
+void sort(T& r)
+{
+sort(begin(r), end(r));
+}
+ 
+std::vector<int> v;
+sort(v);
+ 
+It needs quiet a few amount of codes
+like this only to recover random access capability from
+InputIterator concept.
+ 
+We can write the following valid code
+with Boost.Range, which is implemented with using C++03
+SFINAE.
+ 
+template <class Range>
+void sort(Range& r)
+{
+std::sort(boost::begin(r),
+boost::end(r));
+}
+ 
+std::vector<int> v;
+sort(v); // OK
+ 
+One of the motivation to introduce concepts are
+supporting template programming techniques by language directly to
+eliminate hacky techniques such as tag-dispatch, SFINAE and Type
+Traints. But SFINAE will be kept using because it needs quite a few
+amount of codes without using SFAINAE.
+ 
+<td>
+Add InputRange, OutputRange,
+ForwardRange, BidirectionalRange and RandomAccessRange.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+269
+<td>
+24.3
+<td>
+3
+<td>
+Ed
+<td>
+'decrements for negative n' seems to imply a
+negative number of decrement operations, which is odd.
+ 
+<td>
+Need simple,
+clearer wording
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+270
+<td>
+24.3
+<td>
+4
+<td>
+Te
+<td>
+The reachability constraint in p5 means that a
+negavite result, implying decrements operations in p4, is not
+possible
+ 
+<td>
+Split the two
+overloads into separate descriptions, where reachability is
+permitted to be in either direction for RandomAccessIterator
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+271
+<td>
+24.3
+<td>
+6,7
+<td>
+Te
+<td>
+next/prev return an incremented iterator without
+changing the value of the original iterator. However, even this may
+invalidate an InputIterator. A ForwardIterator is required to
+guarantee the 'multipass' property.
+ 
+<td>
+Replace
+InputIterator constraint with FOrwardIterator in next and prev
+function templates.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+272
+<td>
+24.4
+<td>
+ 
+<td>
+Te
+<td>
+reverse_iterator and move_iterator use different
+formulations for their comparison operations. move_iterator merely
+requires the minimal set of operations, < and ==, from its
+underlying iterator and synthesizes all oprations from these two.
+reverse_iterator relies on the undelying iterator to support all
+comparision operations directly. In practice, move_iterator can
+only be implemented this way as it must support iterator types that
+are merely InputIterators, and so SemiRegular and not Regular.
+However, reserse_iterator has an existing specification and any
+change of semantic could change behaviour of conforming programs
+today - although an iterator that yields different results for (a
+> b) than (b < a) may fall foul of some semantic consistency
+requirements, even if the syntax is met.
+ 
+<td>
+Rephrase the
+reverse_iterator comparison operations using only operators <
+and ==, as per the move_iterator specification.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+274
+<td>
+24.4,
+24.5
+<td>
+ 
+<td>
+Ed
+<td>
+The subclauses for standard iterator adaptors
+could be better organised. There are essentially 3 kinds of
+iterator wrappers provided, stream iterators adapt streams and get
+their own subsection. insert iterators adapt containers, and get
+their own subsection but it is inserted into the middle of 24.4
+Predifined iterators. reverse_iterator and move_iterator adpat
+other iterators, but their presentation is split by insert
+iterators
+ 
+<td>
+Promote
+24.4.2 [insert.iterators] up one level to 24.6. Emphasize that
+insert iterators adapt containers Retarget 24.4 [predef.iterators]
+as iterator adapters for iterator templates that wrap other
+iterators.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+275
+<td>
+24.4.1.1
+<td>
+ 
+<td>
+Te
+<td>
+The constructor template taking a single Iterator
+argument will be selected for Copy Initialization instead of the
+non-template constructor taking a single Iterator argument selected
+by Direct Initialization.
+ 
+<td>
+The
+reverse_iterator template constructor taking a single Iterator
+argument should be explicit.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+276
+<td>
+24.4.1.1
+<td>
+ 
+<td>
+Ed
+<td>
+It is odd to have a mix of declaration stlyes for
+operator+ overloads. Prefer if either all are member functions, or
+all are 'free' functions.
+ 
+<td>
+Make the
+member operators taking a difference_type argument non-member
+operators
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+277
+<td>
+24.4.1.2.1
+<td>
+1
+<td>
+Te
+<td>
+The default constructor default-initializes
+current, rather than value-initializes. This means that when
+Iterator corresponds to a trivial type, the current member is left
+un-initialized, even when the user explictly requests value
+intialization! At this point, it is not safe to perform any
+operations on the reverse_iterator other than assign it a new value
+or destroy it. Note that this does correspond to the basic
+definition of a singular iterator.
+ 
+<td>
+i/ Specify
+value initialization rather than default intialization or ii/
+specify = default; rather than spell out the semantic. This will at
+least allow users to select value initialization and copy the
+iterator value. or iii/ Add a note to the description emphasizing
+the singular nature of a value-initialized reserve iterator.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+278
+<td>
+24.4.1.2.1
+<td>
+3
+<td>
+Te
+<td>
+There is an inconsistency between the constructor
+taking an iterator and the constructor template taking a
+reverse_iterator where one passes by value, and the other by const
+reference. The by-value form is preferred as it allows for
+efficient moving when copy elision fails to kick in.
+ 
+<td>
+Change the
+const reverse_iterator & parameter to
+pass-by-value
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+279
+<td>
+24.4.1.2.12, 24.4.3.2.12
+<td>
+ 
+<td>
+Te
+<td>
+The reason the return type became unspecified is
+LWG issue 386. This reasoning no longer applies as there are at
+least two ways to get the right return type with the new language
+facilities added since the previous standard.
+ 
+<td>
+Specify the
+return type using either decltype or the Iter concept map
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+280
+<td>
+24.4.1.2.4
+<td>
+ 
+<td>
+Ed
+<td>
+The presence of the second iterator value is
+surprising for many readers who underestimate the size of a
+reverse_iterator object. Adding the exposition only member that is
+required by the semantic will reduce confusion.
+ 
+<td>
+Add
+reverse_iterator expsoition only member tmp as a comment to class
+declaration, as a private member
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+281
+<td>
+24.4.1.2.5
+<td>
+ 
+<td>
+Te
+<td>
+The current specification for return value will
+always be a true pointer type, but reverse_iterator supports proxy
+iterators where the pointer type may be some kind of 'smart
+pointer'
+ 
+<td>
+Replace the
+existing returns specification with a copy of the operator*
+specification that returns this->tmp.operator->
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+282
+<td>
+24.4.2.1,
+24.4.2.2.2, 24.4.2.3, 24.4.2.4.2, 24.4.2.5, 24.4.2.6.2
+<td>
+n/a
+<td>
+Te
+<td>
+Insert
+iterators of move-only types will move from lvalues
+<td>
+Add an
+additional constrained overload for operator= that requires
+!CopyConstructible<Cont::value_type> and mark it
+=delete.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+283
+<td>
+24.4.2.5,
+24.4.2.6.4
+<td>
+ 
+<td>
+Te
+<td>
+postincrement
+operator overloads traditionally return by value - insert_iterator
+is declared as return by reference. The change is harmless in this
+case, but either front/back_insert_iterator should take the
+matching change for consistency, or this function should
+return-by-value
+<td>
+change
+operator++(int) overload to return by value, not reference. Affects
+both class summary and operator definition in p
+<td>
+ 
+<tr valign="top">
+<td>
+JP 61
+<td>
+24.4.3.2.1
+<td>
+2nd paragraph, 1st line
+<td>
+ed
+<td>
+Typo.
+"intializing" should be
+"initializing"
+<td>
+Add "i"
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+284
+<td>
+24.5
+<td>
+ 
+<td>
+Te
+<td>
+The stream iterators need constraining with
+concepts/requrires clauses.
+ 
+<td>
+Provide
+constraints
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+285
+<td>
+24.5.1
+<td>
+1,2
+<td>
+Ed
+<td>
+Much of the content of p1 and the whole of p2 is a
+redundant redefinition of InputIterator. It should be
+simplified
+ 
+<td>
+Strike p2.
+Simplify p1 and add a cross-reference to the definition of
+InputIterator concept.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+286
+<td>
+24.5.1
+<td>
+3
+<td>
+Ed
+<td>
+To the casual reader it is not clear if it is
+intended to be able to assign to istream_iterator objects.
+Specifying the copy constructor but relying on the implicit
+copy-assign operator is confusing.
+ 
+<td>
+Either
+provide a similar definition to the copy-assign operator as for the
+copy constructor, or strike the copy constructor
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+287
+<td>
+24.5.1.1
+<td>
+2
+<td>
+Te
+<td>
+It is not clear what the intial state of an
+istream_iterator should be. Is _value_ initialized by reading the
+stream, or default/value initialized? If it is initialized by
+reading the stream, what happens if the initialization is deferred
+until first dereference, when ideally the iterator value should
+have been that of an end-of-stream iterator which is not safely
+dereferencable?
+ 
+<td>
+Specify
+_value_ is initialized by reading the stream, or the iterator takes
+on the end-of-stream value if the stream is empty
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+288
+<td>
+24.5.1.1
+<td>
+3
+<td>
+Ed
+<td>
+The provided
+specification is vacuous, offering no useful information.
+<td>
+Either strike the specification of the copy
+constructor, or simply replace it with an = default
+definition.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+289
+<td>
+24.5.1.2
+<td>
+6
+<td>
+Ed
+<td>
+It is very hard to pick up the correct
+specification for istream_iterator::operator== as the complete
+specification requires reading two quite disconnected paragraphs,
+24.5.1p3, and 24.5.1.2p6. Reading just the specifaction of the
+operation itself suggests that end-of-stream iterators are
+indistinguishable from 'valid' stream iterators, which is a very
+dangerous misreading.
+ 
+<td>
+Merge
+24.5.1p3, equality comparison of end-of-stream-iterators, into
+24.5.1.2p6, the specification of the equality operator for
+istream_iterator.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+290
+<td>
+24.5.2
+<td>
+1
+<td>
+Te
+<td>
+The character type of a string delimiter for an
+ostream_iterator should be const charT *, the type of the elements,
+not char *, a narrow character string.
+ 
+<td>
+Replace char
+* with const charT *
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+291
+<td>
+24.5.2.2
+<td>
+2
+<td>
+Te
+<td>
+ostream_iterator postincrement operator returns by
+reference rather than by value. This may be a small efficiency
+gain, but it is otherwise unconventional. Prefer
+return-by-value.
+ 
+<td>
+ostream_iterator operator++(int);
+<td>
+ 
+<tr valign="top">
+<td>
+FR 34
+<td>
+24.5.3 [istreambuf.iterator]
+<td>
+ 
+<td>
+ed
+<td>
+There are two public sections, and the
+content of the second one is indented with respect to the first. I
+don't it should be.
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+292
+<td>
+24.5.3
+<td>
+1
+<td>
+Ed
+<td>
+Prefer the use of the new nullptr constant to the
+zero literal when using a null pointer in text.
+ 
+<td>
+Change
+istreambuf_iterator(0) to istreambuf_iterator(nullptr)
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+293
+<td>
+24.5.3
+<td>
+2,3,4
+<td>
+Ed
+<td>
+The listed
+paragraphs redundantly redefine an input iterator, and redundancy
+can be a dangerous thing in a specification. Suggest a simpler
+phrasing below.
+<td>
+2. The result of operator*() on an end of stream
+is undefined. For any other iterator value a char_type value is
+returned. 3. Two end of stream iterators are always equal. An end
+of stream iterator is not equal to a non-end of stream iterator. 4.
+As istreambuf_iterator() is an InputIterator but not a
+ForwardIterator, istreambuf_iterators object can be used only for
+one-pass algorithms. It is not possible to assign a character via
+an input iterator.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+294
+<td>
+24.5.3.2
+<td>
+2
+<td>
+Te
+<td>
+Implicit
+converting constructors can be invoked at surprising times, so
+there should always be a good reason for declaring one.
+<td>
+Mark the two single-argument constructors take a
+stream or stream buffer as explicit. The proxy constructor should
+remain implicit. explicit
+istreambuf_iterator(basic_istream<charT,traits>& s)
+throw(); explicit
+istreambuf_iterator(basic_streambuf<charT,traits>* s)
+throw();
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+295
+<td>
+25
+<td>
+ 
+<td>
+Te
+<td>
+THere is a level of redundancy in the library
+specification for many algorithms that can be eliminated with the
+combination of concepts and default parameters for function
+templates. Eliminating redundancy simplified specification and
+reduces the risk of inttroducing accidental inconsistencies.
+ 
+<td>
+Adopt n2743,
+or an update of that paper.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 62
+<td>
+25, 25.3.1.5, 26.3.6.5
+<td>
+ 
+<td>
+te
+<td>
+
+The return types of
+is_sorted_until function and is_heap_until function are iterator.
+But basically, the return type of is_xxx function is bool. And the
+return type of lower_bound function and upper_bound is
+iterator.
+
+So we think that it is
+reasonable to change those two functions.
+ 
+<td>
+Change "is_sorted_until" to
+"sorted_bound"
+Change "is_heap" to "heap_bound"
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+296
+<td>
+25.1.8
+<td>
+1
+<td>
+Te
+<td>
+The 'Returns' of adjacent_find requires only
+HasEqualTo, or a Predicate. Requiring EqualityComparable or
+EquivalenceRelation seems too strong and not useful.
+ 
+<td>
+Change
+EqualityComparable to HasEqualTo and EquivalnceRelation to
+Predicate
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+297
+<td>
+25.2.11
+<td>
+6
+<td>
+Ed
+<td>
+The definition of rotate_copy is very complicated.
+It is equivalent to: return copy(first, middle, copy(middle, last,
+result));
+ 
+<td>
+Change
+'effects' to, returns, requires, complexity to: effects: equivalent
+to: return copy(first, middle, copy(middle, last, result));
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+298
+<td>
+25.2.13
+<td>
+13
+<td>
+Te
+<td>
+partition_point requires a partitioned
+array
+<td>
+requires:
+is_partitioned(first, last, pred) != false;
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+299
+<td>
+25.2.2
+<td>
+ 
+<td>
+Ed
+<td>
+Should be
+consistent in style use of concepts in template parameter lists.
+The auto-OutputIterator sytle used in std::copy is probably
+preferred.
+<td>
+Change way
+signature is declared: template<InputIterator InIter,
+OutputIterator<auto, RvalueOf<InIter::reference>::type>
+OutIter> OutIter move(InIter first, InIter last, OutIter
+result);
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+300
+<td>
+25.2.3
+<td>
+ 
+<td>
+Te
+<td>
+Since publishing the original standard, we have
+learned that swap is a fundamental operation, and several common
+idioms rely on it - especially those related to exception safety.
+As such it belongs in the common <utility> header rather than
+the broader <algorithm> header, and likewise should move to
+clause 20. For backwards compatiblility the algorithm header should
+be required to #include <utility>, which would be covered in
+the resolution of LWG issue 343. There are already dependencies in
+<algorithm> on types declared in this header, so this comment
+does not create a new dependency.
+ 
+<td>
+Move primary
+swap template from <algorithm> into <utility>. Move
+25.2.3 to somewhere under 20.2. Require <algorithm> to
+#include <utility> to access pair and provide legacy support
+for finding swap.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+301
+<td>
+25.2.5
+<td>
+ 
+<td>
+Te
+<td>
+replace and replace_if have the requirement:
+OutputIterator<Iter, Iter::reference> Which implies they need
+to copy some values in the range the algorithm is iterating over.
+This is not however the case, the only thing that happens is const
+T&s might be copied over existing elements (hence the
+OutputIterator<Iter, const T&>
+ 
+<td>
+Remove
+OutputIterator<Iter, Iter::reference> from replace and
+replace_if
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+302
+<td>
+25.3
+<td>
+4
+<td>
+Ed
+<td>
+the concept StrictWeakOrder covers the definition
+of a strict weak ordering, described in paragraph 4.
+ 
+<td>
+Remove 4, and
+mention StrictWeakOrder in paragraph 1.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+303
+<td>
+25.3
+<td>
+6
+<td>
+Ed
+<td>
+This
+paragraph just describes is_partitioned
+<td>
+6 A sequence [start,finish) is partitioned with
+respect to an expression f(e) if is_partitioned(start, finish, e)
+!= false
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+304
+<td>
+25.3.6
+<td>
+ 
+<td>
+Ed
+<td>
+The requires clauses of push_heap, pop_heap and
+make_heap are inconsistently formatted, dispite being
+identical
+ 
+<td>
+Format them
+identically.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+305
+<td>
+25.3.7
+<td>
+1, 9,
+17
+<td>
+Te
+<td>
+The negative
+requirement on IsSameType is a hold-over from an earlier draught
+with a variadic template form of min/max algorith. It is no longer
+necessary.
+<td>
+Strike the
+!IsSameType<T, Compare> constraint on min/max/minmax
+algorithms
+<td>
+ 
+<tr valign="top">
+<td>
+US 84
+<td>
+26
+<td>
+ 
+<td>
+ge
+<td>
+Parts of the numerics chapter are not
+concept enabled.
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+FR 35
+<td>
+26.3 [Complex numbers]
+<td>
+ 
+<td>
+te
+<td>
+Instantiations of the class template
+complex<> have to be allowed for integral types, to reflect
+existing practice and ISO standards (LIA-III).
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+306
+<td>
+26.4
+<td>
+ 
+<td>
+Te
+<td>
+Random number library component cannot be used in
+constrained templates
+ 
+<td>
+Provide
+constraints for the random number library
+<td>
+ 
+<tr valign="top">
+<td>
+JP 63
+<td>
+26.4.8.5.1
+<td>
+ 
+<td>
+te
+<td>
+No constructor of discrete_distribution
+that accepts initializer_list.
+discrete_distribution initialize
+distribution by a given range (iterators), but temporary variable
+of a container or an array is needed in the following case.
+ 
+int ar[] = {1, 2, 3};
+discrete_distribution<> dist(ar,
+ar+3);
+ 
+Other libraries also accept initializer_list, so
+change discrete_distribution library to accept initializer_list
+too.
+ 
+<td>
+Add the following constructer.
+discrete_distribution(initializer_list<result_type>);
+<td>
+ 
+<tr valign="top">
+<td>
+JP 64
+<td>
+26.5.2
+<td>
+ 
+<td>
+te
+<td>
+“valarray<T>& operator+=
+(initializer_list<T>);” is not defined.
+ 
+<td>
+Add valarray<T>& operator+=
+(initializer_list<T>);
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+307
+<td>
+26.7
+<td>
+Footnote
+288
+<td>
+Ed
+<td>
+The footnote refers to TR1, which is not a defined
+term in this standard. Drop the reference to TR1, those templates
+are a regular part of the standard now and how they were introduced
+is no longer relevant.
+ 
+<td>
+Drop the
+reference to TR1.
+<td>
+ 
+<tr valign="top">
+<td>
+US 85
+<td>
+27
+<td>
+ 
+<td>
+ge
+<td>
+The input/output chapter is not concept
+enabled.
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+308
+<td>
+27
+<td>
+ 
+<td>
+Te
+<td>
+iostreams library
+cannot be used from constrained templates
+ 
+<td>
+Provide
+constraints for the iostreams library, clause 27
+<td>
+ 
+<tr valign="top">
+<td>
+JP 65
+<td>
+27.4.4
+<td>
+ 
+<td>
+te
+<td>
+Switch from “unspecified-bool-type”
+to　“explicit operator bool() const”.
+ 
+<td>
+Replace "operator
+unspecified-bool-type() const;" with "explicit operator
+bool() const;"
+<td>
+ 
+<tr valign="top">
+<td>
+JP 66
+<td>
+27.4.4.3
+<td>
+1st paragraph
+<td>
+te
+<td>
+Switch from “unspecified-bool-type”
+to　“explicit operator bool() const”
+ 
+<td>
+Replace "operator
+unspecified-bool-type() const;" with "explicit operator
+bool() const;"
+<td>
+ 
+<tr valign="top">
+<td>
+FR 36
+<td>
+27.6.1.2.2
+[istream.formatted.arithmetic]
+<td>
+1, 2, and 3
+<td>
+ed
+<td>
+iostate err = 0;
+ 
+iostate is a bitmask type and so could be
+an enumeration. Probably using
+goodbit is the solution.
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+FR 37
+<td>
+27.6.1.2.2
+[istream.formatted.arithmetic]
+<td>
+3
+<td>
+ed
+<td>
+else if (lval <
+numeric_limits<int>::min()
+|| numeric_limits<int>::max() <
+lval))
+ 
+The parentheses aren't balanced.
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 67
+<td>
+27.7.1
+<td>
+ 
+<td>
+te
+<td>
+basic_stringbuf dose not use
+concept.
+<td>
+Replace “class Allocator” to
+“Allocator Alloc”.
+ 
+Correct as follows.
+ 
+namespace std {
+template <class charT, class traits =
+char_traits<charT>,
+Allocator Alloc =
+allocator<charT> >
+class basic_stringbuf : public
+basic_streambuf<charT,traits> {
+public:
+...
+ 
+// 27.7.1.1 Constructors:
+explicit
+basic_stringbuf(ios_base::openmode which
+= ios_base::in | ios_base::out);
+explicit basic_stringbuf
+(const
+basic_string<charT,traits,Alloc>& str,
+ios_base::openmode which = ios_base::in
+| ios_base::out);
+basic_stringbuf(basic_stringbuf&&
+rhs);
+ 
+...
+ 
+ 
+// 27.7.1.3 Get and set:
+basic_string<charT,traits,Alloc>
+str() const;
+void str(const
+basic_string<charT,traits,Alloc>& s);
+ 
+...
+};
+ 
+template <class charT, class traits,
+Allocator Alloc>
+void swap(basic_stringbuf<charT,
+traits, Alloc>& x,
+basic_stringbuf<charT, traits,
+Alloc>& y);
+template <class charT, class traits,
+Allocator Alloc>
+void swap(basic_stringbuf<charT,
+traits, Alloc>&& x,
+basic_stringbuf<charT, traits,
+Alloc>& y);
+template <class charT, class traits,
+Allocator Alloc>
+void swap(basic_stringbuf<charT,
+traits, Alloc>& x,
+basic_stringbuf<charT, traits,
+Alloc>&& y);
+}
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 68
+<td>
+27.7.2
+<td>
+ 
+<td>
+te
+<td>
+basic_istringstream dose not use
+concept.
+<td>
+Replace “class Allocator” to
+“Allocator Alloc”.
+ 
+Correct as follows.
+ 
+namespace std {
+template <class charT, class traits =
+char_traits<charT>,
+Allocator Alloc =
+allocator<charT> >
+class basic_istringstream : public
+basic_istream<charT,traits> {
+public:
+typedef charT char_type;
+typedef typename traits::int_type
+int_type;
+typedef typename traits::pos_type
+pos_type;
+typedef typename traits::off_type
+off_type;
+typedef traits traits_type;
+typedef Alloc
+allocator_type;
+ 
+// 27.7.2.1 Constructors:
+explicit
+basic_istringstream(ios_base::openmode which =
+ios_base::in);
+explicit basic_istringstream(
+const
+basic_string<charT,traits,Alloc>& str,
+ios_base::openmode which =
+ios_base::in);
+basic_istringstream(basic_istringstream&&
+rhs);
+ 
+// 27.7.2.2 Assign and swap:
+basic_istringstream&
+operator=(basic_istringstream&& rhs);
+void swap(basic_istringstream&&
+rhs);
+ 
+// 27.7.2.3 Members:
+basic_stringbuf<charT,traits,Alloc>*
+rdbuf() const;
+ 
+basic_string<charT,traits,Alloc>
+str() const;
+void str(const
+basic_string<charT,traits,Alloc>& s);
+ 
+private:
+//
+basic_stringbuf<charT,traits,Alloc> sb; exposition
+only
+};
+ 
+template <class charT, class traits,
+Allocator Alloc>
+void swap(basic_istringstream<charT,
+traits, Alloc>& x,
+basic_istringstream<charT, traits,
+Alloc>& y);
+template <class charT, class traits,
+Allocator Alloc>
+void swap(basic_istringstream<charT,
+traits, Alloc>&& x,
+basic_istringstream<charT, traits,
+Alloc>& y);
+template <class charT, class traits,
+Allocator Alloc>
+void swap(basic_istringstream<charT,
+traits, Alloc>& x,
+basic_istringstream<charT, traits,
+Alloc>&& y);
+}
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 69
+<td>
+27.7.3
+<td>
+ 
+<td>
+te
+<td>
+basic_ostringstream dose not use
+concept.
+<td>
+Replace “class Allocator” to
+“Allocator Alloc”.
+ 
+Correct as follows.
+ 
+namespace std {
+template <class charT, class traits =
+char_traits<charT>,
+Allocator Alloc =
+allocator<charT> >
+class basic_ostringstream : public
+basic_ostream<charT,traits> {
+public:
+// types:
+typedef charT char_type;
+typedef typename traits::int_type
+int_type;
+typedef typename traits::pos_type
+pos_type;
+typedef typename traits::off_type
+off_type;
+typedef traits traits_type;
+typedef Alloc
+allocator_type;
+ 
+// 27.7.3.1
+Constructors/destructor:
+explicit
+basic_ostringstream(ios_base::openmode which =
+ios_base::out);
+explicit basic_ostringstream(
+const
+basic_string<charT,traits,Alloc>& str,
+ios_base::openmode which =
+ios_base::out);
+basic_ostringstream(basic_ostringstream&&
+rhs);
+ 
+// 27.7.3.2 Assign/swap:
+basic_ostringstream&
+operator=(basic_ostringstream&& rhs);
+void swap(basic_ostringstream&&
+rhs);
+ 
+// 27.7.3.3 Members:
+basic_stringbuf<charT,traits,Alloc>*
+rdbuf() const;
+basic_string<charT,traits,Alloc>
+str() const;
+void str(const
+basic_string<charT,traits,Alloc>& s);
+private:
+//
+basic_stringbuf<charT,traits,Alloc> sb; exposition
+only
+};
+ 
+template <class charT, class traits,
+Allocator Alloc>
+void swap(basic_ostringstream<charT,
+traits, Alloc>& x,
+basic_ostringstream<charT, traits,
+Alloc>& y);
+template <class charT, class traits,
+Allocator Alloc>
+void swap(basic_ostringstream<charT,
+traits, Alloc>&& x,
+basic_ostringstream<charT, traits,
+Alloc>& y);
+template <class charT, class traits,
+Allocator Alloc>
+void swap(basic_ostringstream<charT,
+traits, Alloc>& x,
+basic_ostringstream<charT, traits,
+Alloc>&& y);
+}
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 71
+<td>
+27.7.3
+<td>
+ 
+<td>
+ed
+<td>
+Typo.
+"template" is missing in "class
+basic_ostringstream" of the title of the chapter.
+<td>
+Correct as follows.
+27.7.3 Class basic_ostringstream
+ 
+should be
+ 
+27.7.3 Class template
+basic_ostringstream
+<td>
+ 
+<tr valign="top">
+<td>
+JP 72
+<td>
+27.7.4
+<td>
+ 
+<td>
+te
+<td>
+basic_stringstream dose not use
+concept.
+<td>
+Replace "class Allocator" to "Allocator
+Alloc".
+ 
+Correct as follows.
+ 
+namespace std {
+template <class charT, class traits =
+char_traits<charT>,
+Allocator Alloc =
+allocator<charT> >
+class basic_stringstream
+: public
+basic_iostream<charT,traits> {
+public:
+// types:
+typedef charT char_type;
+typedef typename traits::int_type
+int_type;
+typedef typename traits::pos_type
+pos_type;
+typedef typename traits::off_type
+off_type;
+typedef traits traits_type;
+typedef Alloc
+allocator_type;
+ 
+// constructors/destructor
+explicit basic_stringstream(
+ios_base::openmode which =
+ios_base::out|ios_base::in);
+explicit basic_stringstream(
+const
+basic_string<charT,traits,Alloc>& str,
+ios_base::openmode which =
+ios_base::out|ios_base::in);
+basic_stringstream(basic_stringstream&&
+rhs);
+ 
+// 27.7.5.1 Assign/swap:
+void swap(basic_stringstream&&
+rhs);
+ 
+// Members:
+basic_stringbuf<charT,traits,Alloc>*
+rdbuf() const;
+basic_string<charT,traits,Alloc>
+str() const;
+void str(const
+basic_string<charT,traits,Alloc>& str);
+private:
+// basic_stringbuf<charT, traits>
+sb; exposition only
+};
+ 
+template <class charT, class traits,
+Allocator Alloc>
+void swap(basic_stringstream<charT,
+traits, Alloc>& x,
+basic_stringstream<charT, traits,
+Alloc>& y);
+template <class charT, class traits,
+Allocator Alloc>
+void swap(basic_stringstream<charT,
+traits, Alloc>&& x,
+basic_stringstream<charT, traits,
+Alloc>& y);
+template <class charT, class traits,
+Allocator Alloc>
+void swap(basic_stringstream<charT,
+traits, Alloc>& x,
+basic_stringstream<charT, traits,
+Alloc>&& y);
+}
+<td>
+ 
+<tr valign="top">
+<td>
+JP 73
+<td>
+27.8.1.14
+<td>
+ 
+<td>
+te
+<td>
+It is a problem from C++98, fstream cannot appoint
+a filename of wide character string(const wchar_t and const
+wstring&).
+ 
+<td>
+Add interface corresponding to wchar_t,
+char16_t and char32_t.
+<td>
+ 
+<tr valign="top">
+<td>
+US 86
+<td>
+28
+<td>
+ 
+<td>
+ge
+<td>
+The regular expressions chapter is not
+concept enabled.
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+309
+<td>
+28
+<td>
+ 
+<td>
+Te
+<td>
+Regular expressions cannot be used in constrained
+templates
+ 
+<td>
+Provide
+constraints for the regular expression library, clause 28
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+310
+<td>
+28
+<td>
+ 
+<td>
+Te
+<td>
+The regex
+chapter uses iterators in the old pre-concept style, it should be
+changed to use concepts instead.
+<td>
+Use concepts
+for iterator template arguments throughout.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+314
+<td>
+28.4
+<td>
+ 
+<td>
+Te
+<td>
+The swap overloads for regex classes are only
+supplied for l-value references. Other sections of the library (eg
+21 strings or 23 containers) provide two extra overloads taking an
+r-value reference as the first and second argument
+respectively.
+ 
+<td>
+Add the
+missing overloads to 28.4 and the corresponding later sections in
+28 for each swap function. We want to accept AMs paper which
+proposes a single overload with two r-value references
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+315
+<td>
+28.4
+<td>
+p6
+<td>
+Te
+<td>
+6 Effects: string_type str(first, last); return
+use_facet<collate<charT> >(
+getloc()).transform(&*str.begin(), &*str.end()); Is it
+legal to dereference str.end() ?
+ 
+<td>
+Reword to
+effect clause to use legal iterator dereferences
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+316
+<td>
+28.4
+ff
+<td>
+ 
+<td>
+Te
+<td>
+The constructors for regex classes do not have an
+r-value overload.
+ 
+<td>
+Add the
+missing r-value constructors to regex classes.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+317
+<td>
+28.8
+<td>
+ 
+<td>
+Te
+<td>
+basic_string
+has both a constructor and an assignment operator that accepts an
+initializer list, basic_regex should have the same.
+<td>
+In the basic_regex synopsis, after:
+basic_regex& operator=(const charT* ptr); add: basic_regex&
+operator=(initializer_list<charT> il); And after paragraph 20
+add: basic_regex& operator=(initializer_list<charT> il);
+Effects: returns assign(il.begin(), il.end());
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 74
+<td>
+28.8
+<td>
+ 
+<td>
+te
+<td>
+“basic_regx & operator=
+(initializer_list<T>);” is not defined.
+ 
+<td>
+Add basic_regx & operator=
+(initializer_list<T>);
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+318
+<td>
+28.8.2
+<td>
+para
+22
+<td>
+Ed
+<td>
+Constructor definition should appear with the
+other constructors not after assignment ops.
+ 
+<td>
+Move para 22
+to just after para 17.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+319
+<td>
+28.12.2
+<td>
+ 
+<td>
+Te
+<td>
+It was always
+expected that regex_token_iterator would be constructible from an
+array literal: indeed ideally this is the prefered method of
+initializing such an object. However, the best we could do in C++0x
+was: template <std::size_t N>
+regex_token_iterator(BidirectionalIterator a, BidirectionalIterator
+b, const regex_type& re, const int (&submatches)[N],
+regex_constants::match_flag_type m =
+regex_constants::match_default); Now that we have initializer_lists
+we should use them to remove this particular wart.
+<td>
+To the synopsis for regex_token_iterator, after
+template <std::size_t N>
+regex_token_iterator(BidirectionalIterator a, BidirectionalIterator
+b, const regex_type& re, const int (&submatches)[N],
+regex_constants::match_flag_type m =
+regex_constants::match_default); add
+regex_token_iterator(BidirectionalIterator a, BidirectionalIterator
+b, const regex_type& re, initializer_list<int>
+submatches, regex_constants::match_flag_type m =
+regex_constants::match_default); In 28.12.2.1 add the declaration:
+regex_token_iterator(BidirectionalIterator a, BidirectionalIterator
+b, const regex_type& re, initializer_list<int>
+submatches, regex_constants::match_flag_type m =
+regex_constants::match_default); And to the end of para 3 add: The
+forth constructor initializes the member subs to hold a copy of the
+sequence of integer values in the range [submatches.begin(),
+submatches.end()).
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 87
+<td>
+29
+<td>
+ 
+<td>
+ge
+<td>
+The atomics chapter is not concept
+enabled. The adopted paper, N2427, did have those concepts.
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+311
+<td>
+29
+<td>
+ 
+<td>
+Te
+<td>
+Atomic types cannot be used generically in a
+constrained template
+ 
+<td>
+Provide
+constraints for the atomics library, clause 29
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+312
+<td>
+29
+<td>
+ 
+<td>
+Te
+<td>
+The contents
+of the <stdatomic.h> header are not listed anywhere, and
+<cstdatomic> is listed as a C99 header in chapter 17. If we
+intend to use these for compatibility with a future C standard, we
+should not use them now.
+<td>
+Remove
+<cstdatomic> from the C99 headers in table 14. Add a new
+header <atomic> to the headers in table 13. Update chapter 29
+to remove reference to <stdatomic.h> and replace the use of
+<cstdatomic> with <atomic>. If and when WG14 adds
+atomic operations to C we can add corresponding headers to table 14
+with a TR.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 75
+<td>
+29
+<td>
+ 
+<td>
+ed
+<td>
+A definition of enum or struct is the
+style of C using typedef.
+<td>
+Change to a style of C++.
+Correct as follows.
+ 
+29.1
+ 
+namespace std {
+typedef enum memory_order
+{
+memory_order_relaxed,
+memory_order_consume, memory_order_acquire,
+memory_order_release,
+memory_order_acq_rel, memory_order_seq_cst
+} memory_order;
+}
+ 
+should be
+ 
+namespace std {
+enum memory_order {
+memory_order_relaxed,
+memory_order_consume, memory_order_acquire,
+memory_order_release,
+memory_order_acq_rel, memory_order_seq_cst
+};
+}
+ 
+29.3.1
+ 
+namespace std {
+typedef struct atomic_bool
+{
+...
+} atomic_bool;
+}
+ 
+should be
+ 
+namespace std {
+struct atomic_bool {
+...
+};
+}
+ 
+namespace std {
+typedef struct
+atomic_itype {
+...
+} atomic_itype;
+}
+ 
+should be
+ 
+namespace std {
+struct atomic_itype {
+...
+};
+}
+ 
+29.3.2
+ 
+namespace std {
+typedef struct atomic_address
+{
+...
+} atomic_address;
+}
+ 
+should be
+ 
+namespace std {
+struct atomic_address {
+...
+};
+}
+ 
+29.5
+ 
+namespace std {
+typedef struct atomic_flag
+{
+...
+} atomic_flag;
+}
+ 
+should be
+ 
+namespace std {
+struct atomic_flag {
+...
+};
+}
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+313
+<td>
+29.1
+<td>
+ 
+<td>
+Te
+<td>
+seq_cst
+fences don't necessarily guarantee ordering
+http://home.twcny.rr.com/hinnant/cpp_extensions/issues_preview/lwg-active.html#926>
+<td>
+Add a new paragraph after 29.1 [atomics.order]p5
+that says For atomic operations A and B on an atomic object M,
+where A and B modify M, if there are memory_order_seq_cst fences X
+and Y such that A is sequenced before X, Y is sequenced before B,
+and X precedes Y in S, then B occurs later than A in the
+modifiction order of M.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 88
+<td>
+29.2
+<td>
+ 
+<td>
+te
+<td>
+The "lockfree" facilities do not tell the
+programmer enough.
+<td>
+Expand the "lockfree" facilities. See
+the attached paper "Issues with the C++ Standard" under Chapter 29,
+"atomics.lockfree doesn't tell the programmer enough"
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 89
+<td>
+29.3.1
+<td>
+Table 122
+<td>
+te
+<td>
+The types in the table "Atomics for
+standard typedef types" should be typedefs, not classes. These
+semantics are necessary for compatibility with C.
+ 
+<td>
+Change the classes to typedefs.
+<td>
+Google
+<tr valign="top">
+<td>
+US 90
+<td>
+29.4
+<td>
+ 
+<td>
+te
+<td>
+Are atomic functions allowed to have non-volatile
+overloads?
+<td>
+Allow non-volatile overloads. See the
+attached paper "Issues with the C++ Standard, under Chapter 29,
+"Are atomic functions allowed to have non-volatile
+overloads?"
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 91
+<td>
+29.4
+<td>
+ 
+<td>
+te
+<td>
+Whether or not a failed compare_exchange is a RMW
+operation (as used in 1.10 [intro.multithread]) is unclear.
+<td>
+Make failing compare_exchange operations
+not
+be RMW. See the attached
+paper under "atomic RMW status of failed
+compare_exchange"
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 92
+<td>
+29.4
+<td>
+ 
+<td>
+te
+<td>
+The effect of memory_order_consume with atomic RMW
+operations is unclear.
+<td>
+Follow the lead of fences
+[atomics.fences], and promote memory_order_consume to
+memory_order_acquire with RMW operations.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 76
+<td>
+30
+<td>
+ 
+<td>
+ed
+<td>
+A description for "Throws:
+Nothing." are not unified.
+At the part without throw,
+"Throws: Nothing." should be described.
+<td>
+Add "Throws: Nothing." to the
+following.
+30.2.1.6 , 1st paragraph
+30.3.3.1 , 4th paragraph
+30.3.3.2.1 , 6th paragraph
+30.4.1 , 7th and 8th paragraph
+30.4.2 ,
+6th, 7th,19th,21th and 25th paragraph
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 93
+<td>
+30
+<td>
+ 
+<td>
+ge
+<td>
+The thread chapter is not concept
+enabled.
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+320
+ 
+<td>
+30
+<td>
+ 
+<td>
+Te
+<td>
+Threads
+library cannot be used in constrained templates
+<td>
+Provide
+constraints for the threads library, clause 30
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+321
+<td>
+30
+<td>
+ 
+<td>
+Ed
+<td>
+Throughout this clause, the term Requires: is used
+to introduce compile time requirements, which we expect to be
+replaced with concepts and requires in code. Run-time preconditions
+are introduced with the term "Preconditions:" which is not a
+defined part of the library documentation structure (17.5.2.4).
+However, this is exactly the direction that BSI would like to see
+the organisation move, replacing Requires: clauses with
+Preconditions: clasues throught the library. See comment against
+clause 17 for more details.
+ 
+<td>
+Decument
+Preconditions: paragraphs in 17.5.2.4, and use consistently through
+rest of the library.
+<td>
+ 
+<tr valign="top">
+<td>
+US 94
+<td>
+30.1.2
+<td>
+1
+<td>
+te
+<td>
+The first sentence of para
+1 suggests that no other library function is permitted to call
+operating system or low level APIs.
+<td>
+
+Rewrite para 1 as: “
+Some functions described in this Clause are
+specified to throw exceptions of type system_error
+(19.4.5 ). Such exceptions shall be thrown if a call to an
+operating system or underlying API results in an error that
+prevents the library function from satisfying its postconditions or
+from returning a meaningful value.”
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 95
+<td>
+30.1.3
+<td>
+1
+<td>
+te
+<td>
+“native_handle_type” is a typedef, not a
+class member.
+<td>
+Several classes described in this Clause have a
+member native_handle (of type native_handle_type) . The
+presence of this member and its
+semantics is implementation defined. [ Note: This member allows
+implementations to provide access to implementation details. The
+name of the member and the type are specified to facilitate
+portable compile-time detection. Actual use of this member or the
+corresponding type is inherently non-portable. —end note
+]
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+US 96
+<td>
+30.1.4
+<td>
+2
+<td>
+te
+<td>
+There is no definition
+here for monotonic clock.
+<td>
+Implementations should use a monotonic
+clock to measure time for these functions. A monotonic clock
+measures real time, but cannot be set, and is guaranteed to have no
+negative clock jumps.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+322
+<td>
+30.1.4
+<td>
+2
+<td>
+Te
+<td>
+Not all systms can provide a monotonic clock. How
+are they expected to treat a _for function?
+ 
+<td>
+Add at least
+a note explaining the intent for systems that do not support a
+monotonic clock.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+323
+<td>
+30.2.1
+<td>
+1
+<td>
+Te
+<td>
+The presence of a non-explicit variadic template
+constructor alongside an explicit single-argument constructor can
+lead to behaviour that is not intended: the variadic constructor
+will be selected for implicit conversions, defeating the purpose of
+the explicit single-argument constructor. Additionally the
+single-argument constructor is redundant; the variadic constructor
+can provide identical functionality with one *fewer* copies if the
+supplied func is an lvalue.
+ 
+<td>
+Mark
+constructor template <class F, class ...Args>
+thread(F&& f, Args&&... args); as explicit and
+remove the single-argument constructor.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+324
+<td>
+30.2.1.1
+<td>
+ 
+<td>
+Te
+<td>
+thread::id objects should be as useable in hashing
+containers as they are in ordered associative containers.
+ 
+<td>
+Add thread::id support for std::hash
+ 
+ 
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 77
+<td>
+30.2.1.2
+<td>
+ 
+<td>
+te
+<td>
+"CopyConstructible" and "MoveConstructible" in
+"Requires: F and each Ti in Args shall be CopyConstructible
+if an lvalue and otherwise MoveConstructible." are reflected by
+interface.
+ 
+<td>
+Add a concept for constructor of
+thread.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 78
+<td>
+30.2.1.2
+<td>
+4th paragraph, 1st line
+ 
+<td>
+ed
+<td>
+In "F and each Ti in Args", 'Ti' is not
+clear.
+<td>
+Replace "Ti" with "args"
+<td>
+ 
+<tr valign="top">
+<td>
+US 97
+<td>
+30.2.1.3
+<td>
+1
+<td>
+te
+<td>
+detach-on-destruction may
+result in “escaped” threads accessing objects with
+bounded lifetime after the end of their lifetime.
+<td>
+See document WG21
+N2802=08-0312 written by Hans Boehm.
+<td>
+ 
+<tr valign="top">
+<td>
+US 98
+<td>
+30.2.1.3, 30.2.1.4
+<td>
+ 
+<td>
+ 
+<td>
+The current defined behavior for the std::thread
+destructor is to detach the thread. Unfortunately, this behavior
+exposes programmers to tricky, hard-to-diagnose, undefined
+behavior.
+<td>
+Change destruction behavior to undefined
+behavior, with a note strongly encouraging termination. See the
+attached paper "Issues with the C++ Standard" under Chapter 30,
+"Implicit thread detach is harmful".
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+325
+<td>
+30.3.3
+<td>
+2
+<td>
+Te
+<td>
+We believe
+constexpr literal values should be a more natural expression of
+empty tag types than extern objects as it should improve the
+compilers ability to optimize the empty object away
+completely.
+<td>
+Replace the extern declarations: extern const
+defer_lock_t defer_lock; extern const try_to_lock_t try_to_lock;
+extern const adopt_lock_t adopt_lock; with constexpr values
+constexpr defer_lock_t defer_lock{}; constexpr try_to_lock_t
+try_to_lock{}; constexpr adopt_lock_t adopt_lock{};
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+326
+<td>
+30.3.3.2.1
+<td>
+7
+<td>
+Te
+<td>
+The precondition that the mutex is not owned by
+this thread offers introduces the risk of un-necessary undefined
+behaviour into the program. The only time it matters whether the
+current thread owns the mutex is in the lock operation, and that
+will happen subsequent to construction in this case. The lock
+operation has the identical pre-condition, so there is nothing
+gained by asserting that precondition earlier and denying the
+program the right to get into a valid state before calling
+lock.
+ 
+<td>
+Strike
+30.3.3.2.1p7
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+327
+<td>
+30.3.3.2.2
+<td>
+4, 9, 14,
+19
+<td>
+Te
+<td>
+Not clear what the specification for error
+condition resource_deadlock_would_occur means. It is perfectly
+possible for this thread to own the mutex without setting owns to
+true on this specific lock object. It is also possible for lock
+operations to succeed even if the thread does own the mutex, if the
+mutex is recursive. Likewise, if the mutex is not recursive and the
+mutex has been locked externally, it is not always possible to know
+that this error condition should be raised, depending on the host
+operating system facilities. It is possible that 'i.e.' was
+supposed to be 'e.g.' and that suggests that recursive locks are
+not allowed. That makes sense, as the exposition-only member owns
+is boolean and not a integer to count recursive locks.
+ 
+<td>
+Add a
+precondition !owns. Change the 'i.e.' in the error condition to be
+'e.g.' to allow for this condition to propogate deadlock detection
+by the host OS.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+328
+<td>
+30.3.3.2.2
+<td>
+20
+<td>
+Te
+<td>
+There is a
+missing precondition that owns is true, or an if(owns) test is
+missing from the effect clause
+<td>
+Add a precondition that owns == true. Add an error
+condition to detect a violation, rather than yield undefined
+behaviour.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+329
+<td>
+30.5
+<td>
+ 
+<td>
+Te
+<td>
+future,
+promise and packaged_task provide a framework for creating future
+values, but a simple function to tie all three components together
+is missing. Note that we only need a *simple* facility for C++0x.
+Advanced thread pools are to be left for TR2.
+<td>
+Provide a simple function along the lines of:
+template< typename F, typename ... Args > requires
+Callable< F, Args... > future< Callable::result_type >
+async( F&& f, Args && ... ); Semantics are similar
+to creating a thread object with a packaged_task invoking f with
+forward<Args>(args...) but details are left unspecified to
+allow different scheduling and thread spawning implementations. It
+is unspecified whether a task submitted to async is run on its own
+thread or a thread previously used for another async task. If a
+call to async succeeds, it shall be safe to wait for it from any
+thread. The state of thread_local variables shall be preserved
+during async calls. No two incomplete async tasks shall see the
+same value of this_thread::get_id(). [Note: this effectively forces
+new tasks to be run on a new thread, or a fixed-size pool with no
+queue. If the library is unable to spawn a new thread or there are
+no free worker threads then the async call should fail.]
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+330
+<td>
+30.5.1
+<td>
+ 
+<td>
+Ed
+<td>
+30.5.1 (and
+then 30.5.7) refer to a specialisation of
+constructible_with_allocator_prefix<> However this trait is
+not in the CD, so references to it should be removed.
+<td>
+Remove the reference to
+constructible_with_allocator_prefix in 30.5.1 Remove paragraph
+30.5.7
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 79
+<td>
+30.5.1
+<td>
+ 
+<td>
+te
+<td>
+The concept of UsesAllocator and
+Allocator should be used.
+<td>
+Correct as follows.
+ 
+template <class R, class
+Alloc>
+struct
+uses_allocator<promise<R>, Alloc>;
+template <class R>
+struct
+constructible_with_allocator_prefix<promise<R>
+>;
+ 
+should be
+ 
+template<class R, Allocator
+Alloc>
+concept_map UsesAllocator<promise<R>,
+Alloc>;
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+331
+<td>
+30.5.3
+<td>
+ 
+<td>
+Te
+<td>
+Not clear what it means for a public constructor
+to be 'exposition only'. If the intent is purely to support the
+library calling this constructor then it can be made private and
+accessed through friendship. Otherwise it should be documented for
+public consumption.
+ 
+<td>
+Declare the
+constructor as private with a note about intended friendship, or
+remove the exposition-only comment and document the
+semantics.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+332
+<td>
+30.5.4
+<td>
+ 
+<td>
+Ed
+<td>
+It is not clear without reference to the original
+proposal how to use a future. In particular, the only way for the
+user to construct a future is via the promise API which is
+documented after the presentation of future. Most library clauses
+feature a small description of their components and intended use,
+it would be most useful in this case.
+ 
+<td>
+Provide a
+small introductory paragraph, docuenting intended purpose of the
+future class template and the way futures can only be created via
+the promise API.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+333
+<td>
+30.5.4
+<td>
+5
+<td>
+Ge
+<td>
+We expect the
+complicated 3-signature specifcation for future::get() to be
+simplified to a single signature with a requires clause by the
+application of concepts.
+<td>
+Requires
+fully baked concepts for clause 30
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+334
+<td>
+30.5.4
+<td>
+5
+<td>
+Te
+<td>
+Behaviour of get() is undefined if calling get()
+while not is_ready(). The intent is that get() is a blocking call,
+and will wait for the future to become ready.
+ 
+<td>
+Effects: If
+is_ready() would return false, block on the asynchronous result
+associated with *this.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+335
+<td>
+30.5.4
+<td>
+ 
+<td>
+Te
+<td>
+std::unique_future is MoveConstructible, so you
+can transfer the association with an asynchronous result from one
+instance to another. However, there is no way to determine whether
+or not an instance has been moved from, and therefore whether or
+not it is safe to wait for it. std::promise<int> p;
+std::unique_future<int> uf(p.get_future());
+std::unique_future<int> uf2(std::move(uf)); uf.wait(); //
+oops, uf has no result to wait for.
+ 
+<td>
+Add a
+"waitable()" function to unique_future (and shared_future) akin to
+std::thread::joinable(), which returns true if there is an
+associated result to wait for (whether or not it is ready). Then we
+can say: if(uf.waitable()) uf.wait();
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+336
+<td>
+30.5.4
+<td>
+ 
+<td>
+Te
+<td>
+It is possible to transfer ownership of the
+asynchronous result from one unique_future instance to another via
+the move-constructor. However, it is not possible to transfer it
+back, and nor is it possible to create a default-constructed
+unique_future instance to use as a later move target. This unduly
+limits the use of unique_future in code. Also, the lack of a
+move-assignment operator restricts the use of unique_future in
+containers such as std::vector - vector::insert requires
+move-assignable for example.
+ 
+<td>
+Add a default
+constructor with the semantics that it creates a unique_future with
+no associated asynchronous result. Add a move-assignment operator
+which transfers ownership.
+<td>
+ 
+<tr valign="top">
+<td>
+JP 80
+<td>
+30.5.4 , 30.5.5
+<td>
+ 
+<td>
+ed
+<td>
+Typo, duplicated ">"
+"class Period>>"
+ 
+<td>
+Remove one
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+337
+<td>
+30.5.5
+<td>
+ 
+<td>
+Te
+<td>
+shared_future should support an efficient move
+constructor that can avoid unnecessary manipulation of a reference
+count, much like shared_ptr
+ 
+<td>
+Add a move
+constructor
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+338
+<td>
+30.5.5
+<td>
+ 
+<td>
+Te
+<td>
+shared_future
+is currently CopyConstructible, but not CopyAssignable. This is
+inconsistent with shared_ptr, and will surprise users. Users will
+then write work-arounds to provide this behaviour. We should
+provide it simply and efficiently as part of shared_future. Note
+that since the shared_future member functions for accessing the
+state are all declared const, the original usage of an immutable
+shared_future value that can be freely copied by multiple threads
+can be retained by declaring such an instance as "const
+shared_future".
+<td>
+Remove "=delete" from the copy-assignment operator
+of shared_future. Add a move-constructor
+shared_future(shared_future&& rhs), and a move-assignment
+operator shared_future& operator=(shared_future&& rhs).
+The postcondition for the copy-assignment operator is that *this
+has the same associated state as rhs. The postcondition for the
+move-constructor and move assignment is that *this has the same
+associated as rhs had before the constructor/assignment call and
+that rhs has no associated state.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+339
+<td>
+30.5.6
+<td>
+6,
+7
+<td>
+Te
+<td>
+Move
+assignment is goiing in the wrong direction, assigning from *this
+to the passed rvalue, and then returning a reference to an unusable
+*this
+<td>
+Strike 6. 7 Postcondition: associated state of
+*this is the same as the associated state of rhs before the call.
+rhs has no associated state.
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+340
+<td>
+30.5.6
+<td>
+11, 12,
+13
+<td>
+Te
+<td>
+There is an implied postcondition that the state
+of the promise is transferred into the future leaving the promise
+with no associated state. It should be spelled out.
+ 
+<td>
+Postcondition: *this has no associated
+state.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+341
+<td>
+30.5.6
+<td>
+ 
+<td>
+Te
+<td>
+promise::swap
+accepts its parameter by lvalue reference. This is inconsistent
+with other types that provide a swap member function, where those
+swap functions accept an rvalue reference
+<td>
+Change
+promise::swap to take an rvalue reference.
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+342
+<td>
+30.5.6
+<td>
+ 
+<td>
+Te
+<td>
+std::promise is missing a non-member overload of
+swap. This is inconsistent with other types that provide a swap
+member function
+ 
+<td>
+Add a
+non-member overload void swap(promise&& x,promise&&
+y){ x.swap(y); }
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+343
+<td>
+30.5.6
+<td>
+3
+<td>
+Te
+<td>
+The move
+constructor of a std::promise object does not need to allocate any
+memory, so the move-construct-with-allocator overload of the
+constructor is superfluous.
+<td>
+Remove the constructor with the signature template
+<class Allocator> promise(allocator_arg_t, const
+Allocator& a, promise& rhs);
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+JP 81
+<td>
+30.5.8
+<td>
+ 
+<td>
+ed
+<td>
+There are not requirements for F and a
+concept of Allocator dose not use.
+<td>
+Correct as follows.
+ 
+template <class F>
+explicit packaged_task(F f);
+template <class F, class
+Allocator>
+explicit packaged_task(allocator_arg_t,
+const Allocator& a, F f);
+template <class F>
+explicit packaged_task(F&&
+f);
+template <class F, class
+Allocator>
+explicit packaged_task(allocator_arg_t,
+const Allocator& a, F&& f);
+ 
+should be
+ 
+template <class F>
+requires CopyConstructible<F>
+&& Callable<F, ArgTypes...>
+&& Convertible<Callable<F,
+ArgTypes...>::result_type, R>
+explicit packaged_task(F f);
+ 
+template <class F, Allocator
+Alloc>
+requires CopyConstructible<F>
+&& Callable<F, ArgTypes...>
+&& Convertible<Callable<F,
+ArgTypes...>::result_type, R>
+explicit packaged_task(allocator_arg_t,
+const Alloc& a, F f);
+ 
+template <class F>
+requires CopyConstructible<F>
+&& Callable<F, ArgTypes...>
+&& Convertible<Callable<F,
+ArgTypes...>::result_type, R>
+explicit packaged_task(F&&
+f);
+ 
+template <class F, Allocator
+Alloc>
+requires CopyConstructible<F>
+&& Callable<F, ArgTypes...>
+&& Convertible<Callable<F,
+ArgTypes...>::result_type, R>
+explicit packaged_task(allocator_arg_t, const
+Alloc& a, F&& f);
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+DE-23
+<td>
+Annex B
+<td>
+p2
+<td>
+te
+<td>
+
+DE-23 Recursive use of
+constexpr functions appears to be permitted. Since such functions
+may be required to be evaluated at compile-time, Annex B
+"implementation quantities" should specify a maximum depth of
+recursion.
+ 
+<td>
+In Annex B, specify a
+recursion depth of 256 or a larger value.
+<td>
+ 
+<tr valign="top">
+<td>
+DE-24
+<td>
+Annex B
+<td>
+p2
+<td>
+te
+<td>
+
+DE-24 The number of
+placeholders for "bind" is implementation-defined in 20.7.12.1.4,
+but no minimum is suggested in Annex B.
+ 
+<td>
+Add a miminum of 10
+placeholders to Annex B.
+<td>
+ 
+<tr valign="top">
+<td>
+DE-25
+<td>
+Annex B
+<td>
+p2
+<td>
+te
+<td>
+
+DE-25 Specifying a minimum of
+17 recursively nested template instantiations is too small for
+practical purposes. The limit is too high to effectively limit
+compiler resource usage, see
+http://ubiety.uwaterloo.ca/~tveldhui/papers/2003/turing.pdf . The
+conclusion is that the metric "number of recursively nested
+template instantiations" is inapposite.
+ 
+<td>
+Remove the bullet
+"Recursively nested template instantiations [17]".
+<td>
+ 
+<tr valign="top">
+<td>
+FR 38
+<td>
+C.2 [diffs.library]
+<td>
+1
+<td>
+ed
+<td>
+What is ISO/IEC 1990:9899/DAM 1? My guess
+is that's a typo for ISO/IEC
+9899/Amd.1:1995 which I'd have expected to
+be referenced here (the tables
+make reference to things which were
+introduced by Amd.1).
+ 
+<td>
+One need probably a reference to the
+document which introduce char16_t and
+char32_t in C (ISO/IEC TR
+19769:2004?).
+<td>
+ 
+<tr valign="top">
+<td>
+UK 
+344
+<td>
+Appendix
+D
+<td>
+ 
+<td>
+Ge
+<td>
+It is
+desirable to allow some mechanism to support phasing out of
+deprecated features in the future. Allowing compilers to implement
+a mode where deprecated features are not available is a good first
+step.
+<td>
+Add to the
+definition of deprecated features permission for compilers to
+maintain a conditionally supported mode where deprecated features
+can be disabled, so long as they also default to a mode where all
+deprecated features are supported.
+<td>
+ 
+<tr valign="top">
+<td>
+FR 39
+<td>
+Index
+<td>
+ 
+<td>
+ed
+<td>
+Some definitions seem not indexed (such as
+/trivially copyable/ or
+/sequenced before/), indexing them would
+be useful (and marking specially the page -- say bold or italic --
+which reference to the definition would increase the usefulness;
+having a separate index of all definitions is something which could
+also be considered).
+ 
+<td>
+ 
+<td>
+ 
+<tr valign="top">
+<td>
+ 
+<td>
+ 
+<td>
+ 
+<td>
+ 
+<td>
+ 
+<td>
+ 
+<td>
+ </table></div>
\ No newline at end of file

Next message: bdawes_at_[hidden]: "[Boost-commit] svn:boost r51562 - sandbox/committee/LWG"
Previous message: bdawes_at_[hidden]: "[Boost-commit] svn:boost r51560 - sandbox/committee/LWG"

Date view	Thread view	Subject view	Author view

Boost-Commit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk