Boost-Commit :

Date view	Thread view	Subject view	Author view

Subject: [Boost-commit] svn:boost r51560 - sandbox/committee/LWG
From: bdawes_at_[hidden]
Date: 2009-03-03 08:23:37

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

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

Log:
cleanup
Text files modified:
sandbox/committee/LWG/0xCD1_Comments.html | 19873 +++++++++++++++++++--------------------
1 files changed, 9924 insertions(+), 9949 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:23:34 EST (Tue, 03 Mar 2009)
@@ -24,91 +24,91 @@
<DIV TYPE=HEADER>
 <TABLE BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0 style="border-collapse: collapse">
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 1
 </TD>
- <TD WIDTH=77>
- 
+ <TD>
+ 
 2
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 3
 </TD>
- <TD WIDTH=33>
- 
+ <TD>
+ 
 4
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 5
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 6
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 7
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 MB1 
 
 </TD>
- <TD WIDTH=77>
- 
+ <TD>
+ 
 Clause
 No./ Subclause No./ Annex (e.g.
 3.1)
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 Paragraph/ Figure/Table/Note (e.g.
 Table 1)
 </TD>
- <TD WIDTH=33>
- 
+ <TD>
+ 
 Type
 of com-ment2
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 Comment (justification for
 change) by the MB
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 Proposed change by the MB
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 Disposition
- 
+ 
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 1
 </TD>
- <TD WIDTH=77>
- General
+ <TD>
+ General
 Comment
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 ge
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 Interactions
 between several new features appear obscure, and very few examples
@@ -120,102 +120,102 @@
 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US 1
+ <TD>
+ US 1
 </TD>
- <TD WIDTH=77>
- 1-16
+ <TD>
+ 1-16
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- ge/te
+ <TD>
+ ge/te
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- CA-1
+ <TD>
+ CA-1
 </TD>
- <TD WIDTH=77>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ge
+ <TD>
+ Ge
 </TD>
- <TD WIDTH=307>
- There
+ <TD>
+ There
 are quite a number of defects for the current CD recorded in
 SC22/WG21-N2803 and N2806
 </TD>
- <TD WIDTH=270>
- Consider
+ <TD>
+ Consider
 these comments and update ISO/IEC CD 14882 accordingly
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- DE-1
+ <TD>
+ DE-1
 </TD>
- <TD WIDTH=77>
- 1
+ <TD>
+ 1
 through 16
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- ge/te
+ <TD>
+ ge/te
 </TD>
- <TD WIDTH=307>
- DE-1
+ <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
@@ -223,241 +223,241 @@
 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2791.html
 .
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- CH
+ <TD>
+ CH
 2
 </TD>
- <TD WIDTH=77>
- all
+ <TD>
+ all
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 issues on the issues lists shall be addressed before the standard
 becomes final.
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US 3
+ <TD>
+ US 3
 </TD>
- <TD WIDTH=77>
- all
+ <TD>
+ all
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- Latin
+ <TD>
+ Latin
 abbreviations are presented incorrectly.
 </TD>
- <TD WIDTH=270>
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 3
 </TD>
- <TD WIDTH=77>
- 1
+ <TD>
+ 1
 [intro.scope]
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
+ <TD>
 ed
 </TD>
- <TD WIDTH=307>
+ <TD>
 C++
 is split at the end of line.
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US 4
+ <TD>
+ US 4
 </TD>
- <TD WIDTH=77>
- 1.1
+ <TD>
+ 1.1
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- There
+ <TD>
+ There
 is a bad line break in "C++".
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK
+ <TD>
+ UK
 1
 </TD>
- <TD WIDTH=77>
- 1.1
+ <TD>
+ 1.1
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- List
+ <TD>
+ List
 of additional facilities over C has been extended with this
 standard, so should be mentioned in the introductory material.
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 the following to the list in 1.1p2: atomic operations concurrency
 alignment control user-defined literals attributes 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 4
 </TD>
- <TD WIDTH=77>
- 1.2
+ <TD>
+ 1.2
 [intro.refs]
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
+ <TD>
 ed
 </TD>
- <TD WIDTH=307>
+ <TD>
 Is
 the lack of reference to ISO/CEI 9899/AC3:2007 voluntary?
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK
+ <TD>
+ UK
 2
 </TD>
- <TD WIDTH=77>
- 1.2
+ <TD>
+ 1.2
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- ...
+ <TD>
+ ...
 not sure ...
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK
+ <TD>
+ UK
 3
 </TD>
- <TD WIDTH=77>
- 1.3.1
+ <TD>
+ 1.3.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 definition of an argument does not seem to cover many assumed use
 cases, and we believe that is not intentional.
 </TD>
- <TD WIDTH=270>
- Revise
+ <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
@@ -469,633 +469,633 @@
 arguments? what about concepts, requires clauses and concept_map
 instantiations? What about user-defined literals where parens are
 not used?
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK
+ <TD>
+ UK
 4
 </TD>
- <TD WIDTH=77>
- 1.3.3
+ <TD>
+ 1.3.3
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- This
+ <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 WIDTH=270>
- ...
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 5
 </TD>
- <TD WIDTH=77>
- 1.3.4
+ <TD>
+ 1.3.4
 [defns.dynamic.type]
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 te
 </TD>
- <TD WIDTH=307>
+ <TD>
 "The
 dynamic type of an rvalue expression is its static type." Is
 this true with rvalue references?
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US 5
+ <TD>
+ US 5
 </TD>
- <TD WIDTH=77>
- 1.3.5
+ <TD>
+ 1.3.5
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 wording is unclear as to whether it is the input or the
 implementation "that is not a well-formed program".
 </TD>
- <TD WIDTH=270>
- Reword
+ <TD>
+ Reword
 to clarify that it is the input that is here considered not
 well-formed.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 6
 </TD>
- <TD WIDTH=77>
- 1.3.6
+ <TD>
+ 1.3.6
 [defns.impl.defined]
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 ed
 </TD>
- <TD WIDTH=307>
+ <TD>
 There
 is a page break between the title and the paragraph.
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 7
 </TD>
- <TD WIDTH=77>
- 1.3.13
+ <TD>
+ 1.3.13
 [defns.undefined]
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 ed
 </TD>
- <TD WIDTH=307>
+ <TD>
 [intro.execution]/5
 explicitly allows non causal undefined behaviour,
 </TD>
- <TD WIDTH=270>
+ <TD>
 Adding
 it to the note outlying possible undefined behaviours.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US 6
+ <TD>
+ US 6
 </TD>
- <TD WIDTH=77>
- 1.3.14
+ <TD>
+ 1.3.14
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- ge
+ <TD>
+ ge
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- Clearly
+ <TD>
+ Clearly
 state whether or not Unspecified behavior includes undefined
 behavior.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 8
 </TD>
- <TD WIDTH=77>
- 1.4
+ <TD>
+ 1.4
 [intro.compliance]
 </TD>
- <TD WIDTH=69>
- 8
+ <TD>
+ 8
 </TD>
- <TD WIDTH=33>
+ <TD>
 ed
 </TD>
- <TD WIDTH=307>
+ <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 WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK
+ <TD>
+ UK
 5
 </TD>
- <TD WIDTH=77>
- 1.5
+ <TD>
+ 1.5
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ge
+ <TD>
+ Ge
 </TD>
- <TD WIDTH=307>
- Missing
+ <TD>
+ Missing
 checklist of implementation defined behaviour (see ISO/IEC TR
 10176, 4.1.1p6)
 </TD>
- <TD WIDTH=270>
- Provide
+ <TD>
+ Provide
 a new annex with the missing checklist
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK
+ <TD>
+ UK
 6
 </TD>
- <TD WIDTH=77>
- 1.5
+ <TD>
+ 1.5
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ge
+ <TD>
+ Ge
 </TD>
- <TD WIDTH=307>
- Missing
+ <TD>
+ Missing
 annex describing potential incompatibility to previous edition of
 the standard (see ISO/IEC TR 10176, 4.1.1p9)
 </TD>
- <TD WIDTH=270>
- Provide
+ <TD>
+ Provide
 a new annex with the missing documentation. See n2733(08-0243) for
 a starting point
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 7
 </TD>
- <TD WIDTH=77>
- 1.5
+ <TD>
+ 1.5
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- There
+ <TD>
+ There
 is no mention of Clause 17.
 </TD>
- <TD WIDTH=270>
- Include
+ <TD>
+ Include
 Clause 17 among the list of Clauses that specify the Standard
 Library.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 8
 </TD>
- <TD WIDTH=77>
- 1.5
+ <TD>
+ 1.5
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
+ <TD>
 The
 paragraph omits to mention concepts and concept maps among its
 list of entities defined in the Standard Library.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Mention
+ <TD>
+ Mention
 concepts and concept maps among the list of entities.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US 9
+ <TD>
+ US 9
 </TD>
- <TD WIDTH=77>
- 1.6
+ <TD>
+ 1.6
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 The syntax description does
 not account for lines that wrap.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US 10
+ <TD>
+ US 10
 </TD>
- <TD WIDTH=77>
- 1.7
+ <TD>
+ 1.7
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 term thread is used before defined.
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 Reference
 1.10 [intro.multithread].
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 11
 </TD>
- <TD WIDTH=77>
- 1.7
+ <TD>
+ 1.7
 </TD>
- <TD WIDTH=69>
- ¶
+ <TD>
+ ¶
 3 last sent.
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 phrase “threads of execution” should be accompanied by
 a reference to [intro.multithread].
 </TD>
- <TD WIDTH=270>
- Insert
+ <TD>
+ Insert
 the recommended reference.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 12
 </TD>
- <TD WIDTH=77>
- 1.7
+ <TD>
+ 1.7
 </TD>
- <TD WIDTH=69>
- ¶
+ <TD>
+ ¶
 3 first sent.
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- A
+ <TD>
+ A
 memory location is not an object as the sentence claims.
 </TD>
- <TD WIDTH=270>
- Clarify
+ <TD>
+ Clarify
 that a memory location “holds” an object rather than
 that it “is” an object.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 13
 </TD>
- <TD WIDTH=77>
- 1.7
+ <TD>
+ 1.7
 </TD>
- <TD WIDTH=69>
- ¶
+ <TD>
+ ¶
 3 last sent.
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- It
+ <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 WIDTH=270>
- Provide
+ <TD>
+ Provide
 either a better definition of “separate” or reword
 (this and subsequent paragraphs) to avoid this term.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 14
 </TD>
- <TD WIDTH=77>
- 1.7
+ <TD>
+ 1.7
 </TD>
- <TD WIDTH=69>
- ¶
+ <TD>
+ ¶
 4
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Delete
+ <TD>
+ Delete
 the “no matter…” phrase, or resolve the
 contradiction in a different way.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 15
 </TD>
- <TD WIDTH=77>
- 1.7
+ <TD>
+ 1.7
 </TD>
- <TD WIDTH=69>
- ¶
+ <TD>
+ ¶
 5
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- A
+ <TD>
+ A
 struct does not “contain” memory locations.
 </TD>
- <TD WIDTH=270>
- Reword
+ <TD>
+ Reword
 so that a struct is “held in” one or more memory
 locations.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 16
 </TD>
- <TD WIDTH=77>
- 1.9
+ <TD>
+ 1.9
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Remove/replace
+ <TD>
+ Remove/replace
 various occurrences of "sequence" in 1.9.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK
+ <TD>
+ UK
 8
 </TD>
- <TD WIDTH=77>
- 1.9
+ <TD>
+ 1.9
 </TD>
- <TD WIDTH=69>
- 5
+ <TD>
+ 5
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- With
+ <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 WIDTH=270>
- Update
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK
+ <TD>
+ UK
 7
 </TD>
- <TD WIDTH=77>
- 1.9
+ <TD>
+ 1.9
 </TD>
- <TD WIDTH=69>
- 6
+ <TD>
+ 6
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Does
+ <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
@@ -1103,69 +1103,69 @@
 multiple sequences are constrained by the memory model and
 happens-before relationships defined in 1.10
 </TD>
- <TD WIDTH=270>
- Replace
+ <TD>
+ Replace
 'sequence' with 'sequences'.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 9
 </TD>
- <TD WIDTH=77>
- 1.9
+ <TD>
+ 1.9
 [intro.execution]
 </TD>
- <TD WIDTH=69>
- 16
+ <TD>
+ 16
 </TD>
- <TD WIDTH=33>
+ <TD>
 ed
 </TD>
- <TD WIDTH=307>
+ <TD>
 This
 example use int *v while the other examples seems to use notation
 like int* v.
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 17
 </TD>
- <TD WIDTH=77>
- 1.10
+ <TD>
+ 1.10
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Ge
+ <TD>
+ Ge
 </TD>
- <TD WIDTH=307>
- This
+ <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 WIDTH=270>
+ <TD>
 Replace
 first sentence of para 1 as follows:
- 
+ 
 Under
 a hosted implementation, a C++ program can have more
 than one thread of
@@ -1177,39 +1177,39 @@
 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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK
+ <TD>
+ UK
 9
 </TD>
- <TD WIDTH=77>
- 2.1
+ <TD>
+ 2.1
 </TD>
- <TD WIDTH=69>
- 2,
+ <TD>
+ 2,
 4
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Undefined
+ <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 WIDTH=270>
- Replace
+ <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
@@ -1217,63 +1217,63 @@
 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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK
+ <TD>
+ UK
 10
 </TD>
- <TD WIDTH=77>
- 2.1
+ <TD>
+ 2.1
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Implementation
+ <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 WIDTH=270>
- How
+ <TD>
+ How
 the compiler treats non-empty sequences of whitespace should be
 left unspecified, rather than implementation-defined.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 10
 </TD>
- <TD WIDTH=77>
- 2.1
+ <TD>
+ 2.1
 [lex.phases]/5 and 2.2 [lex.charset]/3
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 te
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 [defns.multibyte]
 "the extended character set."
@@ -1307,723 +1307,723 @@
 implementation defined char set.
 
 
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 UK 
 
- 11
+ 11
 </TD>
- <TD WIDTH=77>
- 2.3
+ <TD>
+ 2.3
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Trigraphs
+ <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 WIDTH=270>
- Deprecate
+ <TD>
+ Deprecate
 the whole of 2.3 and move it to appendix D.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 UK 
 
- 12
+ 12
 </TD>
- <TD WIDTH=77>
- 2.4,
+ <TD>
+ 2.4,
 2.8
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- This
+ <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 WIDTH=270>
- Replace
+ <TD>
+ Replace
 undefined behaviour with conditionally supported behaviour with
 implementation defined semantics.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 18
 </TD>
- <TD WIDTH=77>
- 2.4
+ <TD>
+ 2.4
 </TD>
- <TD WIDTH=69>
- ¶
+ <TD>
+ ¶
 2
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 paragraph begins with an empty line.
 </TD>
- <TD WIDTH=270>
- Delete
+ <TD>
+ Delete
 the empty line.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 11
 </TD>
- <TD WIDTH=77>
- 2.4
+ <TD>
+ 2.4
 [lex.pptokens]
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
+ <TD>
 ed
 </TD>
- <TD WIDTH=307>
+ <TD>
 There
 are spurious empty lines.
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 12
 </TD>
- <TD WIDTH=77>
- 2.5
+ <TD>
+ 2.5
 [lex.digraph] and 2.11 [lex.key]/2
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 te
 </TD>
- <TD WIDTH=307>
+ <TD>
 The
 alternative representations are reserved as such even in
 attribute. Is that what is wanted?
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FI
+ <TD>
+ FI
 2
 </TD>
- <TD WIDTH=77>
- 2.5
+ <TD>
+ 2.5
 </TD>
- <TD WIDTH=69>
+ <TD>
 Table
 2
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- Add
+ <TD>
+ Add
 eq, for spelling out == in order to distinguish it from the
 assignment operator.
 </TD>
- <TD WIDTH=270>
- See
+ <TD>
+ See
 eq-keyword.doc, eq-keyword.ppt
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 UK 
 
- 13
+ 13
 </TD>
- <TD WIDTH=77>
- 2.9
+ <TD>
+ 2.9
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- This
+ <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 WIDTH=270>
- Add
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 UK 
 
- 14
+ 14
 </TD>
- <TD WIDTH=77>
- 2.11
+ <TD>
+ 2.11
 </TD>
- <TD WIDTH=69>
- table
+ <TD>
+ table
 3
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 table is nearly sorted, but not quite. It was sorted in previous
 versions of the standard.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Sort
+ <TD>
+ Sort
 the table.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 1
 </TD>
- <TD WIDTH=77>
- 2.11
+ <TD>
+ 2.11
 </TD>
- <TD WIDTH=69>
- Table
+ <TD>
+ Table
 3
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- Keywords
+ <TD>
+ Keywords
 in the table are listed disorderly. Also, a part of a frame of the
 table is not drawn.
 </TD>
- <TD WIDTH=270>
- Sort
+ <TD>
+ Sort
 it in alphabetical order. Complete the table frame.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 19
 </TD>
- <TD WIDTH=77>
- 2.13.1
+ <TD>
+ 2.13.1
 </TD>
- <TD WIDTH=69>
- Table
+ <TD>
+ Table
 5, rows “l or L” and “ll or LL”
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 final entry in the last column (“unsigned long int”)
 is incorrect.
 </TD>
- <TD WIDTH=270>
- Replace
+ <TD>
+ Replace
 the incorrect entries by “unsigned long long int”.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 20
 </TD>
- <TD WIDTH=77>
- 2.13.1,
+ <TD>
+ 2.13.1,
 2.13.3
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- Long
+ <TD>
+ Long
 strings of digits in literals are a continuing problem in the
 production and maintenance of programs.
 </TD>
- <TD WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 UK 
 
- 15
+ 15
 </TD>
- <TD WIDTH=77>
- 2.13.2
+ <TD>
+ 2.13.2
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Inconsistency
+ <TD>
+ Inconsistency
 between definition of a multicharacter literal and a wide
 character literal containing multiple c-chars.
 </TD>
- <TD WIDTH=270>
- Define
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 UK 
 
- 16
+ 16
 </TD>
- <TD WIDTH=77>
- 2.13.2
+ <TD>
+ 2.13.2
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Not
+ <TD>
+ Not
 immediately clear why the question mark needs escaping. A note
 would help.
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 a note explaining that the ? character may need escaping to avoid
 accidentally creating a trigraph.
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 2
 </TD>
- <TD WIDTH=77>
- 2.13.4
+ <TD>
+ 2.13.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 1st
 paragraph, 2nd
 line
- 
+ 
 
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- Typo, R"..." should
+ <TD>
+ Typo, R"..." should
 be R"[...]"
 </TD>
- <TD WIDTH=270>
- Correct
+ <TD>
+ Correct
 typo.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 3
 </TD>
- <TD WIDTH=77>
- 2.13.4
+ <TD>
+ 2.13.4
 </TD>
- <TD WIDTH=69>
- 2nd
+ <TD>
+ 2nd
 paragraph
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- We
+ <TD>
+ We
 think that the explanation of d-char-sequence is not enough.
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 Add the following.
 <OL>
- <LI>
+ <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>
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 4
 </TD>
- <TD WIDTH=77>
- 2.13.4
+ <TD>
+ 2.13.4
 </TD>
- <TD WIDTH=69>
- 3rd
+ <TD>
+ 3rd
 paragraph, 1st line of example
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <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]";
+ c]";
 </TD>
- <TD WIDTH=270>
- Correct
+ <TD>
+ Correct
 typo.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 21
 </TD>
- <TD WIDTH=77>
- 2.13.4
+ <TD>
+ 2.13.4
 </TD>
- <TD WIDTH=69>
- ¶
+ <TD>
+ ¶
 3
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 paragraph, marked as a Note, contains an embedded example not
 marked as such.
 </TD>
- <TD WIDTH=270>
- Denote
+ <TD>
+ Denote
 the code (and perhaps also its commentary) as an Example.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 22
 </TD>
- <TD WIDTH=77>
- 2.13.4
+ <TD>
+ 2.13.4
 </TD>
- <TD WIDTH=69>
- ¶
+ <TD>
+ ¶
 3
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 code does not have the effect predicted by its accompanying
 narrative.
 </TD>
- <TD WIDTH=270>
- Append
+ <TD>
+ Append
 a backslash to the first line of the code.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 5
 </TD>
- <TD WIDTH=77>
- 2.13.4
+ <TD>
+ 2.13.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 11th
 paragraph, Table 7
- 
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- It
+ <TD>
+ It
 is not explicit how to combine raw-string and non-raw-string.
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 rules containing raw-string in the table 7.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 13
 </TD>
- <TD WIDTH=77>
- 2.13.4
+ <TD>
+ 2.13.4
 [lex.string]
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
+ <TD>
 ed
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 Shouldn't
 the assert be
 assert(std::strcmp(p,
 "a\nb\nc") == 0);
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 UK 
 
- 17
+ 17
 </TD>
- <TD WIDTH=77>
- 2.13.4
+ <TD>
+ 2.13.4
 </TD>
- <TD WIDTH=69>
- 10
+ <TD>
+ 10
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- It
+ <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
@@ -2033,38 +2033,38 @@
 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 WIDTH=270>
- (asssuming
+ <TD>
+ (asssuming
 deprecated conversion to non-const array is removed or can be
 turned off) Strike the sentence on undefined behaviour.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 UK 
 
- 18
+ 18
 </TD>
- <TD WIDTH=77>
- 2.13.4
+ <TD>
+ 2.13.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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
@@ -2074,11 +2074,11 @@
 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 WIDTH=270>
- Define
+ <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
@@ -2086,70 +2086,70 @@
 type specifier in the same way that the R prefix does, supporting
 u8I, uI, UI and LI.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 UK 
 
- 19
+ 19
 </TD>
- <TD WIDTH=77>
- 2.13.4
+ <TD>
+ 2.13.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Refactor
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 14
 </TD>
- <TD WIDTH=77>
- 3
+ <TD>
+ 3
 [basic]
 </TD>
- <TD WIDTH=69>
- 7
+ <TD>
+ 7
 </TD>
- <TD WIDTH=33>
+ <TD>
 ed
 </TD>
- <TD WIDTH=307>
+ <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 WIDTH=270>
+ <TD>
 
 Would
 prefer
@@ -2165,27 +2165,27 @@
 as
 some names denotes entities declared after the first occurrence.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 15
 </TD>
- <TD WIDTH=77>
- 3
+ <TD>
+ 3
 [basic]
 </TD>
- <TD WIDTH=69>
- 8
+ <TD>
+ 8
 </TD>
- <TD WIDTH=33>
+ <TD>
 ed
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 /operator-function-id/,
 /conversion-function-id/, /template-id/ are followed by a space
@@ -2194,399 +2194,399 @@
 
 
 </TD>
- <TD WIDTH=270>
+ <TD>
 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 UK
- 20
+ 20
 </TD>
- <TD WIDTH=77>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ge
+ <TD>
+ Ge
 </TD>
- <TD WIDTH=307>
- Chapter
+ <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 WIDTH=270>
- Change
+ <TD>
+ Change
 the title to "Basic definitions".
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 UK 
 
- 21
+ 21
 </TD>
- <TD WIDTH=77>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Concepts
+ <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 WIDTH=270>
- Rename
+ <TD>
+ Rename
 the chapter Basic ???. THe note in p2 specifically needs similar
 rewording
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 UK 
 
- 22
+ 22
 </TD>
- <TD WIDTH=77>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=69>
- 6
+ <TD>
+ 6
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- References
+ <TD>
+ References
 are frequently considered variables, but this definition only
 applies to objects.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 "or reference" after both uses of "object"
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 UK 
 
- 23
+ 23
 </TD>
- <TD WIDTH=77>
- 3.1
+ <TD>
+ 3.1
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- alias-declarations
+ <TD>
+ alias-declarations
 are not definitions and should be added to the list
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 alias-declaration after typedef declaration.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 UK 
 
- 24
+ 24
 </TD>
- <TD WIDTH=77>
- 3.1
+ <TD>
+ 3.1
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Add
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 UK 
 
- 25
+ 25
 </TD>
- <TD WIDTH=77>
- 3.1
+ <TD>
+ 3.1
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Example
+ <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 WIDTH=270>
- Remove
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 UK 
 
- 26
+ 26
 </TD>
- <TD WIDTH=77>
- 3.2
+ <TD>
+ 3.2
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- THe
+ <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 WIDTH=270>
- Either
+ <TD>
+ Either
 include references in the definition of 'variable' (see earlier
 comment) or add reference to the list in this paragraph.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 UK 
 
- 27
+ 27
 </TD>
- <TD WIDTH=77>
- 3.2
+ <TD>
+ 3.2
 </TD>
- <TD WIDTH=69>
- 4
+ <TD>
+ 4
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- A
+ <TD>
+ A
 class type must be complete when catching exceptions, even by
 reference or pointer. See 15.3.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 "when used in an exception-handler (15.3)" to the list.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 16
 </TD>
- <TD WIDTH=77>
- 3.3
+ <TD>
+ 3.3
 [Declarative regions and scopes.]
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 te
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 The
 scope of function parameters is defined, but what is the scope of
 template parameters?
- 
+ 
 
 </TD>
- <TD WIDTH=270>
+ <TD>
 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 UK
- 28
+ 28
 </TD>
- <TD WIDTH=77>
- 3.3.1
+ <TD>
+ 3.3.1
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Class
+ <TD>
+ Class
 templates are not classes, so we should include this case.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- ammend
+ <TD>
+ ammend
 "class" to "class or class template"
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 UK
- 29
+ 29
 </TD>
- <TD WIDTH=77>
- 3.3.10
+ <TD>
+ 3.3.10
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- operators
+ <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 WIDTH=270>
- Add
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 17
 </TD>
- <TD WIDTH=77>
- 3.5
+ <TD>
+ 3.5
 [Program and linkage]
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 te
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 This
 section does not specify whether concept names have linkage.
@@ -2595,153 +2595,153 @@
 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 WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 30
 </TD>
- <TD WIDTH=77>
- 3.5
+ <TD>
+ 3.5
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- This
+ <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 WIDTH=270>
- Add
+ <TD>
+ Add
 a note to clarify that concepts don't need linkage.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 31
 </TD>
- <TD WIDTH=77>
- 3.5
+ <TD>
+ 3.5
 </TD>
- <TD WIDTH=69>
- 4
+ <TD>
+ 4
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- What
+ <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 WIDTH=270>
- Clarify
+ <TD>
+ Clarify
 rules for namespaces inside nested namespaces, or remove the
 restriction.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 23
 </TD>
- <TD WIDTH=77>
- 3.5
+ <TD>
+ 3.5
 </TD>
- <TD WIDTH=69>
- 6
+ <TD>
+ 6
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 Bad paragraph break.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 18
 </TD>
- <TD WIDTH=77>
- 3.5
+ <TD>
+ 3.5
 [basic.link]
 </TD>
- <TD WIDTH=69>
- 6
+ <TD>
+ 6
 </TD>
- <TD WIDTH=33>
+ <TD>
 ed
 </TD>
- <TD WIDTH=307>
+ <TD>
 The
 paragraph number is not aligned with the text.
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 19
 </TD>
- <TD WIDTH=77>
- 3.6
+ <TD>
+ 3.6
 [Start and termination]
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 te
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 This
 section completely ignores the real world and practical case of
@@ -2756,183 +2756,183 @@
 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 32
 </TD>
- <TD WIDTH=77>
- 3.6.1
+ <TD>
+ 3.6.1
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Do
+ <TD>
+ Do
 we really want to allow: constexpr int main() { return 0; } as a
 valid program?
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 constexpr to the list of ill-formed things to annotate main
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 24
 </TD>
- <TD WIDTH=77>
- 3.6.1
+ <TD>
+ 3.6.1
 </TD>
- <TD WIDTH=69>
- 4
+ <TD>
+ 4
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- std::quick_exit
+ <TD>
+ std::quick_exit
 is not referenced.
 </TD>
- <TD WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 25
 </TD>
- <TD WIDTH=77>
- 3.6.3
+ <TD>
+ 3.6.3
 </TD>
- <TD WIDTH=69>
- ¶
+ <TD>
+ ¶
 2 last sent.
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 parenthesized phrase, introduced via “i.e.” is in the
 nature of an example.
 </TD>
- <TD WIDTH=270>
- Change
+ <TD>
+ Change
 “i.e.” to “e.g.”
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 6
 </TD>
- <TD WIDTH=77>
- 3.7.4.1
+ <TD>
+ 3.7.4.1
 </TD>
- <TD WIDTH=69>
- 4th
+ <TD>
+ 4th
 paragraph, 4th
 line
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- Correct
+ <TD>
+ Correct
 typo.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- DE-3
+ <TD>
+ DE-3
 </TD>
- <TD WIDTH=77>
- 3.7.4.3
+ <TD>
+ 3.7.4.3
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
+ <TD>
 DE-3
 It is unclear whether the following code has well-defined
 behavior; none of the bullets in the second paragraph seem to
@@ -2944,93 +2944,93 @@
 delete
 &i;
 </TD>
- <TD WIDTH=270>
- Clarify
+ <TD>
+ Clarify
 that &i is considered a safely-derived pointer value.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 26
 </TD>
- <TD WIDTH=77>
- 3.8
+ <TD>
+ 3.8
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 and 5
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- Use
+ <TD>
+ Use
 of object fields during destruction is excessively and erroneously
 constrained.
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 See the attached document
 "Issues with the C++ Standard" under Chapter 3 "Use
 of objects, especially from other threads, during destruction".
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 27
 </TD>
- <TD WIDTH=77>
- 3.9
+ <TD>
+ 3.9
 </TD>
- <TD WIDTH=69>
- ¶
+ <TD>
+ ¶
 9 first sent.
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- There
+ <TD>
+ There
 is a superfluous/extraneous “and”.
 </TD>
- <TD WIDTH=270>
- Delete
+ <TD>
+ Delete
 “and” from the phrase “and std::nullptr_t”.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 20
 </TD>
- <TD WIDTH=77>
- 3.9
+ <TD>
+ 3.9
 [Types]
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 te
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 The
 phrase 'effective type' is defined and used in a way that is
@@ -3042,41 +3042,41 @@
 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 7
 </TD>
- <TD WIDTH=77>
- 3.9.2
+ <TD>
+ 3.9.2
 </TD>
- <TD WIDTH=69>
- 3rd
+ <TD>
+ 3rd
 paragraph, 13th
 line
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- over-aligned
+ <TD>
+ over-aligned
 type was added as new notion. So it is preferable to add the link
 after that.
 </TD>
- <TD WIDTH=270>
- 
+ <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
@@ -3088,65 +3088,65 @@
 pointer value for an over-aligned type(3.11).—end
 note ]
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 28
 </TD>
- <TD WIDTH=77>
- 3.9.3
+ <TD>
+ 3.9.3
 </TD>
- <TD WIDTH=69>
- ¶
+ <TD>
+ ¶
 5 first sent.
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
+ <TD>
 The
 closing braces of the first two sets are preceded by extraneous
 space.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Delete
+ <TD>
+ Delete
 the extra spaces.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- DE
+ <TD>
+ DE
 4
 </TD>
- <TD WIDTH=77>
- 4.2
+ <TD>
+ 4.2
 </TD>
- <TD WIDTH=69>
- p2
+ <TD>
+ p2
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- DE-4
+ <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 WIDTH=270>
+ <TD>
 Consider
 applying the proposed resolution presented in core issue 693 in
 WG21 document N2714 “C++ Standard Core Language Active
@@ -3155,36 +3155,36 @@
 ; 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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- CH
+ <TD>
+ CH
 1
 </TD>
- <TD WIDTH=77>
- 4.9
+ <TD>
+ 4.9
 and 5.2.9
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- With
+ <TD>
+ With
 respect to the target type, pointer to members should behave like
 normal pointers (least surprise principle).
 </TD>
- <TD WIDTH=270>
+ <TD>
 The
 standard should allow implicit conversions from ``pointer to
 member of <TT>T</TT> of type
@@ -3193,624 +3193,624 @@
 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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- DE-5
+ <TD>
+ DE-5
 </TD>
- <TD WIDTH=77>
- 4.11,
+ <TD>
+ 4.11,
 5.3.1, 5.5
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- DE-5
+ <TD>
+ DE-5
 Ref-qualification has not been integrated with pointer-to-members.
 </TD>
- <TD WIDTH=270>
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 33
 </TD>
- <TD WIDTH=77>
- 4.13
+ <TD>
+ 4.13
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- We
+ <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 WIDTH=270>
- Replace
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 34
 </TD>
- <TD WIDTH=77>
- 4.13
+ <TD>
+ 4.13
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- 6th
+ <TD>
+ 6th
 bullet, "the rank of char" - first letter should be
 capitalised for consistency with the other bullets
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- The
+ <TD>
+ The
 rank of char
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 36
 </TD>
- <TD WIDTH=77>
- 5.1
+ <TD>
+ 5.1
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Primary
+ <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 WIDTH=270>
- Delete
+ <TD>
+ Delete
 this paragraph.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 37
 </TD>
- <TD WIDTH=77>
- 5.1
+ <TD>
+ 5.1
 </TD>
- <TD WIDTH=69>
- 11
+ <TD>
+ 11
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Member
+ <TD>
+ Member
 function templates are not member functions, so should also be
 listed in the 3rd bullet
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 member function templates to the 3rd bullet
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 38
 </TD>
- <TD WIDTH=77>
- 5.1
+ <TD>
+ 5.1
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- this
+ <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 WIDTH=270>
- ...
+ <TD>
+ ...
 words to follow ...
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 8
 </TD>
- <TD WIDTH=77>
- 5.1
+ <TD>
+ 5.1
 </TD>
- <TD WIDTH=69>
- 7th
+ <TD>
+ 7th
 paragraph, Syntax rules
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <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
+ decltype(v)::value_type
 i = 0; // int i = 0;
 </TD>
- <TD WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 9
 </TD>
- <TD WIDTH=77>
- 5.1.1
+ <TD>
+ 5.1.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <TD>
+ 
 Add move capture in a lambda
 expression.
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 10
 </TD>
- <TD WIDTH=77>
- 5.1.1
+ <TD>
+ 5.1.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <TD>
+ 
 Add result_type to the syntax
 of an unnamed function object generated by a lambda expression.
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 29
 </TD>
- <TD WIDTH=77>
- 5.1.1
+ <TD>
+ 5.1.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 The standard does not state
 whether or not direct recursion of lambdas is possible.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 30
 </TD>
- <TD WIDTH=77>
- 5.1.1
+ <TD>
+ 5.1.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 31
 </TD>
- <TD WIDTH=77>
- 5.1.1
+ <TD>
+ 5.1.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 45
 </TD>
- <TD WIDTH=77>
- 5.1.1
+ <TD>
+ 5.1.1
 </TD>
- <TD WIDTH=69>
- para
+ <TD>
+ para
 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Lambda
+ <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 WIDTH=270>
- Change
+ <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 "
@@ -3819,91 +3819,91 @@
 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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 US 32
- 
+ 
 
 </TD>
- <TD WIDTH=77>
- 5.1.1
+ <TD>
+ 5.1.1
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 The final italic "this"
 in the paragraph should be a teletype "this".
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 39
 </TD>
- <TD WIDTH=77>
- 5.1.1
+ <TD>
+ 5.1.1
 </TD>
- <TD WIDTH=69>
- 11
+ <TD>
+ 11
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- This
+ <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 WIDTH=270>
- Add
+ <TD>
+ Add
 "F has an implicitly-declared destructor".
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 40
 </TD>
- <TD WIDTH=77>
- 5.1.1
+ <TD>
+ 5.1.1
 </TD>
- <TD WIDTH=69>
- 12
+ <TD>
+ 12
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- If
+ <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
@@ -3912,37 +3912,37 @@
 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 WIDTH=270>
- If
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 41
 </TD>
- <TD WIDTH=77>
- 5.1.1
+ <TD>
+ 5.1.1
 </TD>
- <TD WIDTH=69>
- 12
+ <TD>
+ 12
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- For
+ <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*
@@ -3951,102 +3951,102 @@
 surprising results. Also, relying on the idea of implicitly
 slicing objects is uncomfortable.
 </TD>
- <TD WIDTH=270>
- Replace
+ <TD>
+ Replace
 inheritance with implicit conversion.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 42
 </TD>
- <TD WIDTH=77>
- 5.1.1
+ <TD>
+ 5.1.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- A
+ <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 WIDTH=270>
- Add
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 43
 </TD>
- <TD WIDTH=77>
- 5.1.1
+ <TD>
+ 5.1.1
 </TD>
- <TD WIDTH=69>
- 12
+ <TD>
+ 12
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- ...
+ <TD>
+ ...
 provvide exceptions in the right places ...
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 44
 </TD>
- <TD WIDTH=77>
- 5.1.1
+ <TD>
+ 5.1.1
 </TD>
- <TD WIDTH=69>
- 12
+ <TD>
+ 12
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- There
+ <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
@@ -4054,195 +4054,195 @@
 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 WIDTH=270>
- Extend
+ <TD>
+ Extend
 reference_closure requirement to cover [this] lambdas. Consider a
 simple syntax for creating such bound expressions.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 46
 </TD>
- <TD WIDTH=77>
- 5.1.1
+ <TD>
+ 5.1.1
 </TD>
- <TD WIDTH=69>
- para
+ <TD>
+ para
 12
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Replace
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- DE-6
+ <TD>
+ DE-6
 </TD>
- <TD WIDTH=77>
- 5.1.1,
+ <TD>
+ 5.1.1,
 20.7.18
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- DE-6
+ <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 WIDTH=270>
- In
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- DE-7
+ <TD>
+ DE-7
 </TD>
- <TD WIDTH=77>
- 5.1.1
+ <TD>
+ 5.1.1
 </TD>
- <TD WIDTH=69>
- p10
+ <TD>
+ p10
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- DE-7
+ <TD>
+ DE-7
 The note at the end of paragraph 10 appears to be garbled.
 </TD>
- <TD WIDTH=270>
- Remove
+ <TD>
+ Remove
 "or references" in the note.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- DE-8
+ <TD>
+ DE-8
 </TD>
- <TD WIDTH=77>
- 5.1.1
+ <TD>
+ 5.1.1
 </TD>
- <TD WIDTH=69>
- p10
+ <TD>
+ p10
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- DE-8
+ <TD>
+ DE-8
 The construction of the function call operator signature is
 missing specifications for the ref-qualifier and the
 attribute-specifier.
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 bullets that say that the ref-qualifier and the
 attribute-specifier are absent.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 33
 </TD>
- <TD WIDTH=77>
- 5.1.1
+ <TD>
+ 5.1.1
 </TD>
- <TD WIDTH=69>
- 11
+ <TD>
+ 11
 </TD>
- <TD WIDTH=33>
- Ge
+ <TD>
+ Ge
 </TD>
- <TD WIDTH=307>
- There is no
+ <TD>
+ There is no
 definition of “move constructor” or “move
 operation”
 </TD>
- <TD WIDTH=270>
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- DE-9
+ <TD>
+ DE-9
 </TD>
- <TD WIDTH=77>
- 5.1.1
+ <TD>
+ 5.1.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- DE-9
+ <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
@@ -4250,617 +4250,617 @@
 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2791.html
 .
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 a few well-chosen examples.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 52
 </TD>
- <TD WIDTH=77>
- 5.2
+ <TD>
+ 5.2
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- This
+ <TD>
+ This
 paragraph seens out of place, assignment expressions are covered
 in 5.17
 </TD>
- <TD WIDTH=270>
- Move
+ <TD>
+ Move
 p3 to subsection 5.17
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 53
 </TD>
- <TD WIDTH=77>
- 5.2.1
+ <TD>
+ 5.2.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Insert
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 59
 </TD>
- <TD WIDTH=77>
- 5.2.2
+ <TD>
+ 5.2.2
 </TD>
- <TD WIDTH=69>
- 7
+ <TD>
+ 7
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- When
+ <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 WIDTH=270>
- Clarify
+ <TD>
+ Clarify
 that this sentence only applies where the ellipsis is used.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 60
 </TD>
- <TD WIDTH=77>
- 5.2.5
+ <TD>
+ 5.2.5
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- In
+ <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 WIDTH=270>
- Add
+ <TD>
+ Add
 "and" before vq
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 61
+ <TD>
+ UK 61
 </TD>
- <TD WIDTH=77>
- 5.2.5
+ <TD>
+ 5.2.5
 </TD>
- <TD WIDTH=69>
- p1
+ <TD>
+ p1
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Together
+ <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 WIDTH=270>
- Clarify
+ <TD>
+ Clarify
 in footnote 60 that this will not happen if the whole expression
 is an unevaluated operand.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 62
 </TD>
- <TD WIDTH=77>
- 5.2.5
+ <TD>
+ 5.2.5
 </TD>
- <TD WIDTH=69>
- 4
+ <TD>
+ 4
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- In
+ <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 WIDTH=270>
- Replace
+ <TD>
+ Replace
 'not an lvalue' with 'is an rvalue'.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- DE-10
+ <TD>
+ DE-10
 </TD>
- <TD WIDTH=77>
- 5.2.5
+ <TD>
+ 5.2.5
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- DE-10
+ <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 WIDTH=270>
- Adjust
+ <TD>
+ Adjust
 the presentation of the types involved as appropriate.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 63
+ <TD>
+ UK 63
 </TD>
- <TD WIDTH=77>
- 5.2.6
+ <TD>
+ 5.2.6
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Paragraph
+ <TD>
+ Paragraph
 2 is missing its number.
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 one.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 64
 </TD>
- <TD WIDTH=77>
- 5.2.7
+ <TD>
+ 5.2.7
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- A
+ <TD>
+ A
 new name R is introduced for use in paragraphs 3 and 4. But R is
 the same as T.
 </TD>
- <TD WIDTH=270>
- Replace
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 65
 </TD>
- <TD WIDTH=77>
- 5.2.7
+ <TD>
+ 5.2.7
 </TD>
- <TD WIDTH=69>
- 8
+ <TD>
+ 8
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- In
+ <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 WIDTH=270>
- Replace
+ <TD>
+ Replace
 "an lvalue referring to" with "reference",
 twice.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 66
 </TD>
- <TD WIDTH=77>
- 5.2.8
+ <TD>
+ 5.2.8
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- typeid
+ <TD>
+ typeid
 may return "an implementation-defined class derived from std
 :: type_info". The derivation must be public.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- an
+ <TD>
+ an
 implementation-defined class publicly derived from std ::
 type_info
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 67
 </TD>
- <TD WIDTH=77>
- 5.2.9
+ <TD>
+ 5.2.9
 </TD>
- <TD WIDTH=69>
- 1,
+ <TD>
+ 1,
 2, 3
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Paragraph
+ <TD>
+ Paragraph
 1 specifies when the result of static_cast is an lvalue; repeating
 it is unnecessary.
 </TD>
- <TD WIDTH=270>
- In
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 54
 </TD>
- <TD WIDTH=77>
- 5.2.10
+ <TD>
+ 5.2.10
 </TD>
- <TD WIDTH=69>
- 3,
+ <TD>
+ 3,
 6
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Para
+ <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 WIDTH=270>
- In
+ <TD>
+ In
 para 6, replace unspecified with implementation-defined.
 Alternatively, delete paragraph 3, since individual cases are
 labelled appropriately.
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 55
 </TD>
- <TD WIDTH=77>
- 5.2.10
+ <TD>
+ 5.2.10
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- dynamic_cast
+ <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 WIDTH=270>
- Strike
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 56
 </TD>
- <TD WIDTH=77>
- 5.2.10
+ <TD>
+ 5.2.10
 </TD>
- <TD WIDTH=69>
- 5
+ <TD>
+ 5
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Add:
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 57
+ <TD>
+ UK 57
 </TD>
- <TD WIDTH=77>
- 5.2.10
+ <TD>
+ 5.2.10
 </TD>
- <TD WIDTH=69>
- 8
+ <TD>
+ 8
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Conditionally
+ <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 WIDTH=270>
- Add:
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 58
 </TD>
- <TD WIDTH=77>
- 5.2.11
+ <TD>
+ 5.2.11
 </TD>
- <TD WIDTH=69>
- 9
+ <TD>
+ 9
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Casting
+ <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 WIDTH=270>
- Replace
+ <TD>
+ Replace
 lvalue with "lvalue or rvalue" twice.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 US 34
- 
+ 
 
 </TD>
- <TD WIDTH=77>
- 5.3
+ <TD>
+ 5.3
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 list of unary operator should be in teletype font.
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 68
 </TD>
- <TD WIDTH=77>
- 5.3.1
+ <TD>
+ 5.3.1
 </TD>
- <TD WIDTH=69>
- 2-9
+ <TD>
+ 2-9
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- All
+ <TD>
+ All
 the unary operands other than * return rvalues - but this is not
 stated.
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 a paragraph 1a "The following unary operators all produce
 results that are rvalues."
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 69
 </TD>
- <TD WIDTH=77>
- 5.3.1
+ <TD>
+ 5.3.1
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- If
+ <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
@@ -4869,66 +4869,66 @@
 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 WIDTH=270>
- ...
+ <TD>
+ ...
 unknown ...
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 70
 </TD>
- <TD WIDTH=77>
- 5.3.3
+ <TD>
+ 5.3.3
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Change
+ <TD>
+ Change
 "an enumeration type" to "an enumeration type whose
 underlying type is not fixed".
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 71
 </TD>
- <TD WIDTH=77>
- 5.3.4
+ <TD>
+ 5.3.4
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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
@@ -4936,31 +4936,31 @@
 instance. For consistency, use the same form of initiailization
 for the deduction as the new expression.
 </TD>
- <TD WIDTH=270>
- Replace
+ <TD>
+ Replace
 T x = e; with T x(e);
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 72
 </TD>
- <TD WIDTH=77>
- 5.3.4
+ <TD>
+ 5.3.4
 </TD>
- <TD WIDTH=69>
- 7
+ <TD>
+ 7
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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
@@ -4969,425 +4969,425 @@
 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 WIDTH=270>
- Throw
+ <TD>
+ Throw
 std::bad_alloc instead of std::length_error.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 73
 </TD>
- <TD WIDTH=77>
- 5.3.4
+ <TD>
+ 5.3.4
 </TD>
- <TD WIDTH=69>
- 6
+ <TD>
+ 6
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- A
+ <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 WIDTH=270>
- Add
+ <TD>
+ Add
 'literal' before 'class type'
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 74
 </TD>
- <TD WIDTH=77>
- 5.3.4
+ <TD>
+ 5.3.4
 </TD>
- <TD WIDTH=69>
- 8
+ <TD>
+ 8
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- operators,
+ <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 WIDTH=270>
- Change
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 35
 </TD>
- <TD WIDTH=77>
- 5.3.4
+ <TD>
+ 5.3.4
 </TD>
- <TD WIDTH=69>
- 9
+ <TD>
+ 9
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Missing
+ <TD>
+ Missing
 period in middle of paragraph between "in the scope of T"
 and "If this lookup fails"
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 a period between "in the scope of T" and "If this
 lookup fails"
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 75
 </TD>
- <TD WIDTH=77>
- 5.3.5
+ <TD>
+ 5.3.5
 </TD>
- <TD WIDTH=69>
- 8
+ <TD>
+ 8
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- A
+ <TD>
+ A
 paragraph strarting with [Note... is easily skipped when reading,
 missing the normative text at the end.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Swap
+ <TD>
+ Swap
 order of the note and normative text.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 21
 </TD>
- <TD WIDTH=77>
- 5.3.6
+ <TD>
+ 5.3.6
 [Alignof
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 te
 </TD>
- <TD WIDTH=307>
+ <TD>
 Should
 not the type of alignof-expression be of type std::max_align_t?
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 35
 </TD>
- <TD WIDTH=77>
- 5.8
+ <TD>
+ 5.8
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 and 3
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 47
 </TD>
- <TD WIDTH=77>
- 5.14
+ <TD>
+ 5.14
 / 5.15
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Why
+ <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 WIDTH=270>
- Pick
+ <TD>
+ Pick
 one form of wording as 'the best' and apply it in both places.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 48
 </TD>
- <TD WIDTH=77>
- 5.18
+ <TD>
+ 5.18
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Add:
+ <TD>
+ Add:
 [Note: There are no guarantees on the order of value computation
 for an overloaded comma operator -- end note]
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 49
 </TD>
- <TD WIDTH=77>
- 5.19
+ <TD>
+ 5.19
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Is
+ <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 WIDTH=270>
- Add
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 50
+ <TD>
+ UK 50
 </TD>
- <TD WIDTH=77>
- 5.19
+ <TD>
+ 5.19
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Change
+ <TD>
+ Change
 "effective integral type" to "effective integral or
 enumeration type" in the 4th bullet, 1st sub-bullet.
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 51
 </TD>
- <TD WIDTH=77>
- 5.19
+ <TD>
+ 5.19
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- typeid
+ <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 WIDTH=270>
- Strike
+ <TD>
+ Strike
 the words "whose operand is of a polymorphic class type"
 on the bullet for typeid expressions.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 76
 </TD>
- <TD WIDTH=77>
- 6.3
+ <TD>
+ 6.3
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Do
+ <TD>
+ Do
 we really need two different terms that say the same thing?
 </TD>
- <TD WIDTH=270>
- Pick
+ <TD>
+ Pick
 either 'block' or 'compound statement' as the preferred term and
 use it consistently throughout the standard.
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 22
 </TD>
- <TD WIDTH=77>
- 6.4.2
+ <TD>
+ 6.4.2
 [The switch statement]
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 te
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 The
 constant-expression in
@@ -5408,166 +5408,166 @@
 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 77
 </TD>
- <TD WIDTH=77>
- 6.5
+ <TD>
+ 6.5
 </TD>
- <TD WIDTH=69>
- 5
+ <TD>
+ 5
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Profide
+ <TD>
+ Profide
 a cross-reference for the terms: i/o operation, synchronize
 operation and atomic operation 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 11
 </TD>
- <TD WIDTH=77>
- 6.5.4
+ <TD>
+ 6.5.4
 </TD>
- <TD WIDTH=69>
- 1st
+ <TD>
+ 1st
 paragraph, 5th
 line
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- There
+ <TD>
+ There
 is no _RangeT type in the equivalent code to “range-base
 for” statement. It existed in N2049.
 </TD>
- <TD WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 78
 </TD>
- <TD WIDTH=77>
- 6.5.4
+ <TD>
+ 6.5.4
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Including
+ <TD>
+ Including
 the header <iterator_concepts> is far too unwieldy to enable
 an important and (expected to be) frequently used syntax.
 </TD>
- <TD WIDTH=270>
- Merge
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 79
 </TD>
- <TD WIDTH=77>
- 6.5.4
+ <TD>
+ 6.5.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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.
@@ -5575,71 +5575,71 @@
 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 WIDTH=270>
- When
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- DE-11
+ <TD>
+ DE-11
 </TD>
- <TD WIDTH=77>
- 6.9
+ <TD>
+ 6.9
 </TD>
- <TD WIDTH=69>
- p1
+ <TD>
+ p1
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
+ <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 WIDTH=270>
- State
+ <TD>
+ State
 that such a late-checked block has the same meaning as if the late_check
 keyword were absent.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 80
 </TD>
- <TD WIDTH=77>
- 7
+ <TD>
+ 7
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Many
+ <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
@@ -5648,325 +5648,325 @@
 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 WIDTH=270>
- Strike
+ <TD>
+ Strike
 the first sentence.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 81
 </TD>
- <TD WIDTH=77>
- 7
+ <TD>
+ 7
 </TD>
- <TD WIDTH=69>
- 4
+ <TD>
+ 4
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- String
+ <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 WIDTH=270>
- Add
+ <TD>
+ Add
 a note: Multiple adjacent string literals may be used instead of a
 single /string-literal/; see [lex.phases].
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 82
 </TD>
- <TD WIDTH=77>
- 7
+ <TD>
+ 7
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Paragraph
+ <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 WIDTH=270>
- Add
+ <TD>
+ Add
 "scoped enumeration" to the list in the second sentence.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 83
 </TD>
- <TD WIDTH=77>
- 7.1
+ <TD>
+ 7.1
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Not
+ <TD>
+ Not
 sure. I understand the rule, just not how to say it.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 84
 </TD>
- <TD WIDTH=77>
- 7.1
+ <TD>
+ 7.1
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Delete
+ <TD>
+ Delete
 the production (including the duplicate in A6)
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FI
+ <TD>
+ FI
 3
 </TD>
- <TD WIDTH=77>
- 7.1
+ <TD>
+ 7.1
 </TD>
- <TD WIDTH=69>
- [dcl.spec.auto]
+ <TD>
+ [dcl.spec.auto]
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
+ <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 WIDTH=270>
- See
+ <TD>
+ See
 restricted-auto.ppt
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 85
 </TD>
- <TD WIDTH=77>
- 7.1.1
+ <TD>
+ 7.1.1
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- ...
+ <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 WIDTH=270>
- Replace
+ <TD>
+ Replace
 "global" with "namespace scope".
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 86
 </TD>
- <TD WIDTH=77>
- 7.1.1
+ <TD>
+ 7.1.1
 </TD>
- <TD WIDTH=69>
- 2,3
+ <TD>
+ 2,3
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Deprecate
+ <TD>
+ Deprecate
 current usage of the register keyword.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 87
 </TD>
- <TD WIDTH=77>
- 7.1.1
+ <TD>
+ 7.1.1
 </TD>
- <TD WIDTH=69>
- 1,
+ <TD>
+ 1,
 4, 5
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Why
+ <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 WIDTH=270>
- Drop
+ <TD>
+ Drop
 requirement to combine static keyword with thread_local at
 block-scope inside a function definition.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 36
 </TD>
- <TD WIDTH=77>
- 7.1.1
+ <TD>
+ 7.1.1
 </TD>
- <TD WIDTH=69>
- 4
+ <TD>
+ 4
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 The permission to use
 thread_local static data members is missing.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 the static members as a permitted use.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 23
 </TD>
- <TD WIDTH=77>
- 7.1.5
+ <TD>
+ 7.1.5
 [constexpr]
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 te
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 'constexpr'
 functions should be allowed to take const reference parameters, as
@@ -5991,41 +5991,41 @@
 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 12
 </TD>
- <TD WIDTH=77>
- 7.1.5
+ <TD>
+ 7.1.5
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
+ <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
@@ -6033,16 +6033,16 @@
 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
@@ -6052,147 +6052,147 @@
 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 WIDTH=270>
- 
+ <TD>
+ 
 Allow constexpr recursion.
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 37
 </TD>
- <TD WIDTH=77>
- 7.1.6.1
+ <TD>
+ 7.1.6.1
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 89
 </TD>
- <TD WIDTH=77>
- 7.1.6.1
+ <TD>
+ 7.1.6.1
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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
@@ -6213,68 +6213,68 @@
 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 WIDTH=270>
- Make
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 90
 </TD>
- <TD WIDTH=77>
- 7.1.6.2
+ <TD>
+ 7.1.6.2
 </TD>
- <TD WIDTH=69>
- para
+ <TD>
+ para
 1 and table 9
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Add
+ <TD>
+ Add
 a row to table 9 mentioning simple-template-id and punting to
 clause 14 (cf decltype(expression)).
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 91
 </TD>
- <TD WIDTH=77>
- 7.1.6.2
+ <TD>
+ 7.1.6.2
 </TD>
- <TD WIDTH=69>
- 4
+ <TD>
+ 4
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- 5.1/5
+ <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."
@@ -6287,139 +6287,139 @@
 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 WIDTH=270>
- Insert
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 92
 </TD>
- <TD WIDTH=77>
- 7.1.6.3
+ <TD>
+ 7.1.6.3
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Either
+ <TD>
+ Either
 strike the note or add reference to 11.4/3 and/or mention of
 "friend T;".
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 93 
 
 </TD>
- <TD WIDTH=77>
- 7.1.6.3
+ <TD>
+ 7.1.6.3
 </TD>
- <TD WIDTH=69>
- Grammar
+ <TD>
+ Grammar
 before para 1
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- In
+ <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 WIDTH=270>
- Change
+ <TD>
+ Change
 to keyword font
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 94
 </TD>
- <TD WIDTH=77>
- 7.1.6.4
+ <TD>
+ 7.1.6.4
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- The
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 95
 </TD>
- <TD WIDTH=77>
- 7.1.6.4
+ <TD>
+ 7.1.6.4
 </TD>
- <TD WIDTH=69>
- 4
+ <TD>
+ 4
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- (See
+ <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
@@ -6429,36 +6429,36 @@
 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 WIDTH=270>
- Change
+ <TD>
+ Change
 "in a new-type-id" to "in a new-type-id or type-id
 in a new-expression".
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 24
 </TD>
- <TD WIDTH=77>
- 7.1.6.4
+ <TD>
+ 7.1.6.4
 [auto specifier]
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 te
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 Now
 that 'auto' is finally used in its most obvious sense to state
@@ -6511,345 +6511,345 @@
 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 38
 </TD>
- <TD WIDTH=77>
- 7.2
+ <TD>
+ 7.2
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 The discussion of attribute
 specifiers should be a separate paragraph.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 39
 </TD>
- <TD WIDTH=77>
- 7.2
+ <TD>
+ 7.2
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- As
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 13
 </TD>
- <TD WIDTH=77>
- 7.2
+ <TD>
+ 7.2
 </TD>
- <TD WIDTH=69>
- paragraph
+ <TD>
+ paragraph
 3
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- Replace
+ <TD>
+ Replace
 the description, "same underlying type", with "same
 as underlying type of (previous) declaration."
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 96
 </TD>
- <TD WIDTH=77>
- 7.2
+ <TD>
+ 7.2
 </TD>
- <TD WIDTH=69>
- 7
+ <TD>
+ 7
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- enum
+ <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 WIDTH=270>
- Add
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 97
 </TD>
- <TD WIDTH=77>
- 7.2
+ <TD>
+ 7.2
 </TD>
- <TD WIDTH=69>
- 9
+ <TD>
+ 9
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Missing
+ <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 WIDTH=270>
- Add
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 98
 </TD>
- <TD WIDTH=77>
- 7.2
+ <TD>
+ 7.2
 </TD>
- <TD WIDTH=69>
- 5
+ <TD>
+ 5
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- It
+ <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 WIDTH=270>
- Add
+ <TD>
+ Add
 a TransformationTrait to 20.5.6 that returns the underlying type
 of an enumeration type.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 99
 </TD>
- <TD WIDTH=77>
- 7.2
+ <TD>
+ 7.2
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- It
+ <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 WIDTH=270>
- Move
+ <TD>
+ Move
 "an enumeration declared by an opaque-enum-declaration ... is
 a complete type" from the note to normative text.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 14
 </TD>
- <TD WIDTH=77>
- 7.3.1
+ <TD>
+ 7.3.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <TD>
+ 
 Add the description of the
 behavior when a member that was defined with same name in other
 namespace was referred.
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 100
 </TD>
- <TD WIDTH=77>
- 7.3.3
+ <TD>
+ 7.3.3
 </TD>
- <TD WIDTH=69>
- 10
+ <TD>
+ 10
 and 13
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Para
+ <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
@@ -6857,34 +6857,34 @@
 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 WIDTH=270>
- Delete
+ <TD>
+ Delete
 para 10, moving its example into para 13.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 101
 </TD>
- <TD WIDTH=77>
- 7.3.3
+ <TD>
+ 7.3.3
 </TD>
- <TD WIDTH=69>
- 20
+ <TD>
+ 20
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- If
+ <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
@@ -6892,70 +6892,70 @@
 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 WIDTH=270>
- Allow
+ <TD>
+ Allow
 typename for non-dependent names iff they refer to a type.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- DE-12
+ <TD>
+ DE-12
 </TD>
- <TD WIDTH=77>
- 7.3.3
+ <TD>
+ 7.3.3
 </TD>
- <TD WIDTH=69>
- p15
+ <TD>
+ p15
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
+ <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 WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 25
 </TD>
- <TD WIDTH=77>
- 7.3.3
+ <TD>
+ 7.3.3
 [The using declaration]
 </TD>
- <TD WIDTH=69>
- Paragraph
+ <TD>
+ Paragraph
 21
 </TD>
- <TD WIDTH=33>
+ <TD>
 te
 </TD>
- <TD WIDTH=307>
+ <TD>
 The
 syntax for concept map alias is unnecessarily both confused and
 verbose.
 </TD>
- <TD WIDTH=270>
+ <TD>
 
 We
 strongly suggest simplifications, e.g.
@@ -6970,62 +6970,62 @@
 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 102
 </TD>
- <TD WIDTH=77>
- 7.3.4
+ <TD>
+ 7.3.4
 </TD>
- <TD WIDTH=69>
- 6
+ <TD>
+ 6
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- This
+ <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 WIDTH=270>
- Move
+ <TD>
+ Move
 the example to paragraph 7, and/or replace it with an appropriate
 example.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 40
 </TD>
- <TD WIDTH=77>
- 7.6
+ <TD>
+ 7.6
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 The
 list of attributes is missing an attribute to indicate that a
 function with a <CODE>
@@ -7034,68 +7034,68 @@
 unexpected()</CODE>
 catch clause generated. This attribute was a motivating example
 for the attribute syntax, and its omission is surprising.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 the attribute.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 41
 </TD>
- <TD WIDTH=77>
- 7.6
+ <TD>
+ 7.6
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 A common problem is
 unintentionally declaring a new virtual member function instead of
 overriding a base virtual member function.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- An
+ <TD>
+ An
 attribute stating intent to override would enable better
 diagnostics.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 26
 </TD>
- <TD WIDTH=77>
+ <TD>
 7.6
 [Attributes]
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 ed
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 Are
 they part of object types or not? The section does not appear to
@@ -7103,60 +7103,60 @@
 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FI
+ <TD>
+ FI
 1
 </TD>
- <TD WIDTH=77>
- 7.6
+ <TD>
+ 7.6
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- Add
+ <TD>
+ Add
 override-attribute for functions in order to avoid mistakes when
 overriding functions.
 </TD>
- <TD WIDTH=270>
- See
+ <TD>
+ See
 override-attribute.doc, override-attribute.ppt
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 27
 </TD>
- <TD WIDTH=77>
+ <TD>
 7.6.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 te
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 This
 section specifies that no name lookup is performed on any
@@ -7175,32 +7175,32 @@
 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 103
 </TD>
- <TD WIDTH=77>
- 7.6.1
+ <TD>
+ 7.6.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Attributes
+ <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
@@ -7209,125 +7209,125 @@
 Adding this support to attributes would remove the remaining need,
 and support similar attributes in the future.
 </TD>
- <TD WIDTH=270>
- Add:
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 104
 </TD>
- <TD WIDTH=77>
- 7.6.1
+ <TD>
+ 7.6.1
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- It
+ <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 WIDTH=270>
- 7.6.1p1
+ <TD>
+ 7.6.1p1
 should move up one level to become 7.6p1. There grammar should
 remain under 7.6.1
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 105
 </TD>
- <TD WIDTH=77>
- 7.6.1
+ <TD>
+ 7.6.1
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Allowing
+ <TD>
+ Allowing
 only one level of namespaces in attributes seems unnecessarily
 limiting.
 </TD>
- <TD WIDTH=270>
- To:
+ <TD>
+ To:
 attribute-scoped-token: attribute-namespace :: identifier add
 attribute-namespace :: attribute-scoped-token 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 106
 </TD>
- <TD WIDTH=77>
- 7.6.2
+ <TD>
+ 7.6.2
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Extensive
+ <TD>
+ Extensive
 use of alignment and related terms without cross reference.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 cross-reference to 3.11.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 15
 </TD>
- <TD WIDTH=77>
- 7.6.2
+ <TD>
+ 7.6.2
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
+ <TD>
 An
 abbreviation of 7.6.2 should be “[decl.attr.align]”
 instead of “[dcl.align]”. Section name
@@ -7337,110 +7337,110 @@
 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 WIDTH=270>
- Change
+ <TD>
+ Change
 "[dcl.align]" of 7.6.2 to "[decl.attr.align]".
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 107
 </TD>
- <TD WIDTH=77>
- 7.6.3
+ <TD>
+ 7.6.3
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- While
+ <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 WIDTH=270>
- Adda
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 108
 </TD>
- <TD WIDTH=77>
- 7.6.4
+ <TD>
+ 7.6.4
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- It
+ <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 WIDTH=270>
- Strike
+ <TD>
+ Strike
 "no diagnostic required" and the associated footnote.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 42
 </TD>
- <TD WIDTH=77>
- 7.6.4
+ <TD>
+ 7.6.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <TD>
+ 
 Modify
 the semantics of <CODE>
 [[final]]</CODE>
@@ -7448,122 +7448,122 @@
 C++ Standard" under Chapter 7 "Meaning of <CODE>
 [[final]]</CODE>
 attribute applied to classes".
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 109
 </TD>
- <TD WIDTH=77>
- 7.6.5
+ <TD>
+ 7.6.5
 </TD>
- <TD WIDTH=69>
- 4
+ <TD>
+ 4
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 example code refers in comments to "Compilation unit" A
 and B. The term should be "Translation unit" (2/1)
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Replace
+ <TD>
+ Replace
 "Compilation" with "Translation" in two places
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=77>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 110
 </TD>
- <TD WIDTH=77>
- 7.6.5
+ <TD>
+ 7.6.5
 </TD>
- <TD WIDTH=69>
- 4
+ <TD>
+ 4
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Change
+ <TD>
+ Change
 the type of foo_head to atomic<foo *>[].
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 43
 </TD>
- <TD WIDTH=77>
- 8
+ <TD>
+ 8
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 With
 the introduction of late-specified return types for functions and
 lambda expressions, we now have three different syntaxes for
@@ -7573,99 +7573,99 @@
 auto</CODE>
 keyword is used in one, but also used differently in variable
 definitions.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Some
+ <TD>
+ Some
 simplification is needed.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 111
 </TD>
- <TD WIDTH=77>
- 8.3.5
+ <TD>
+ 8.3.5
 </TD>
- <TD WIDTH=69>
- 13
+ <TD>
+ 13
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Example
+ <TD>
+ Example
 missing closing bracket in template<typename... T> void f(T
 (* ...t)(int, int);
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 closing bracket like this: template<typename... T> void f(T
 (* ...t)(int, int));
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 44
 </TD>
- <TD WIDTH=77>
- 8.3.5
+ <TD>
+ 8.3.5
 </TD>
- <TD WIDTH=69>
- 13
+ <TD>
+ 13
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 In the Example, "template
 void f(T (* ...t)(int, int);" is missing a close parenthesis.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- It
+ <TD>
+ It
 presumably should read: "template void f(T (* ...t))(int,
 int);".
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
+ <TD>
 
 US
 45
 </TD>
- <TD WIDTH=77>
+ <TD>
 
 8.3.5
 </TD>
- <TD WIDTH=69>
+ <TD>
 
 13
 </TD>
- <TD WIDTH=33>
+ <TD>
 
 te
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 At
 present, function parameter packs can only occur at the end of a
@@ -7710,7 +7710,7 @@
 parameter-declaration-list should be considered non-deduced
 contexts.
 </TD>
- <TD WIDTH=270>
+ <TD>
 
 
 In
@@ -7772,94 +7772,94 @@
 
 
 </TD>
- <TD WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- DE-13
+ <TD>
+ DE-13
 </TD>
- <TD WIDTH=77>
- 8.4
+ <TD>
+ 8.4
 
 
 </TD>
- <TD WIDTH=69>
- p2
+ <TD>
+ p2
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- DE-13
+ <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 WIDTH=270>
- Properly
+ <TD>
+ Properly
 quote the grammar from 8.3.5.
 </TD>
- <TD WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 16
 </TD>
- <TD WIDTH=77>
- 8.5
+ <TD>
+ 8.5
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 15th
 paragraph, 1st
 line
- 
+ 
 
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 Typo, duplicated "in"
- "The
+ "The
 initialization that occurs in in the forms"
 </TD>
- <TD WIDTH=270>
- Remove
+ <TD>
+ Remove
 one.
 </TD>
- <TD WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
+ <TD>
 
 US
 46
 </TD>
- <TD WIDTH=77>
+ <TD>
 
 8.5.3
 </TD>
- <TD WIDTH=69>
+ <TD>
 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 
 te
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 The
 ability for an rvalue reference to bind to an lvalue opens a
@@ -7888,7 +7888,7 @@
 
 
 </TD>
- <TD WIDTH=270>
+ <TD>
 
 Prohibit
 rvalue references from binding to lvalues.
@@ -7922,121 +7922,121 @@
 for 12.1, 12.4, 12.8, but restricted to special functions in that
 comment. (See US NN).
 </TD>
- <TD WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 49
 </TD>
- <TD WIDTH=77>
- 8.5.4
+ <TD>
+ 8.5.4
 </TD>
- <TD WIDTH=69>
- 6
+ <TD>
+ 6
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- In
+ <TD>
+ In
 the Example, the comments could be improved.
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 See the attached paper "Issues
 with the C++ Standard" under "Editorial Issues" and
 "8.5.4/6".
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 112
 </TD>
- <TD WIDTH=77>
- 9
+ <TD>
+ 9
 </TD>
- <TD WIDTH=69>
- 4-9
+ <TD>
+ 4-9
 </TD>
- <TD WIDTH=33>
- Ge
+ <TD>
+ Ge
 </TD>
- <TD WIDTH=307>
- We
+ <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 WIDTH=270>
- Add
+ <TD>
+ Add
 appropriate forward references to 14.9.4
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 113
 </TD>
- <TD WIDTH=77>
- 9.4.2
+ <TD>
+ 9.4.2
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Mis-applied
+ <TD>
+ Mis-applied
 edit from the paper n2756
 </TD>
- <TD WIDTH=270>
- The
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
+ <TD>
 
 US
 50
 </TD>
- <TD WIDTH=77>
+ <TD>
 
 12.1,
 12.4, 12.8
 </TD>
- <TD WIDTH=69>
+ <TD>
 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 
 te
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 Implicitly-declared
 default constructors, destructors, copy constructors, and copy
@@ -8067,7 +8067,7 @@
 
 
 </TD>
- <TD WIDTH=270>
+ <TD>
 
 
 In
@@ -8104,90 +8104,90 @@
 
 
 </TD>
- <TD WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 28
 </TD>
- <TD WIDTH=77>
+ <TD>
 
 12.6.1
 [Explicit initialization]
 
 
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 te
 </TD>
- <TD WIDTH=307>
+ <TD>
 This
 section, in particular the example with `g' appears contradictory
 with the syntax for uniform initialization.
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 51
 </TD>
- <TD WIDTH=77>
- 12.6.2
+ <TD>
+ 12.6.2
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 The discussion of delegating
 constructors should be in its own paragraph.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 114
 </TD>
- <TD WIDTH=77>
- 12.6.2
+ <TD>
+ 12.6.2
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Despite
+ <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
@@ -8196,8 +8196,8 @@
 braced-init-list would allow the user to choose between copy and
 direct initialization
 </TD>
- <TD WIDTH=270>
- Ammend
+ <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
@@ -8207,58 +8207,58 @@
 direct-initialization, OR COPY-INITIALIZATION IF THE OPTIONAL = IS
 PRESENT BETWEEN THE MEM-INITIALIZER-ID and the BRACED-INIT-LIST.
 [Example:...
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 52
 </TD>
- <TD WIDTH=77>
- 13.5.8
+ <TD>
+ 13.5.8
 </TD>
- <TD WIDTH=69>
- ¶
+ <TD>
+ ¶
 5
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- A
+ <TD>
+ A
 word is misspelled.
 </TD>
- <TD WIDTH=270>
- Change
+ <TD>
+ Change
 “shal” to “shall”.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 115
 </TD>
- <TD WIDTH=77>
- 14
+ <TD>
+ 14
 </TD>
- <TD WIDTH=69>
- 6-11
+ <TD>
+ 6-11
 </TD>
- <TD WIDTH=33>
- Ge
+ <TD>
+ Ge
 </TD>
- <TD WIDTH=307>
- Exported
+ <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
@@ -8268,267 +8268,267 @@
 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 WIDTH=270>
- Consider
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 116
 </TD>
- <TD WIDTH=77>
- 14
+ <TD>
+ 14
 </TD>
- <TD WIDTH=69>
- 6-11
+ <TD>
+ 6-11
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Is
+ <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 WIDTH=270>
- Either
+ <TD>
+ Either
 prohibit exporting concept map templates, or more directly address
 what it means to export a concept map.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 117
 </TD>
- <TD WIDTH=77>
- 14
+ <TD>
+ 14
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Ge
+ <TD>
+ Ge
 </TD>
- <TD WIDTH=307>
- It
+ <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 WIDTH=270>
- Allow
+ <TD>
+ Allow
 template aliases to be declared inside a function scope, and
 consider scoped concept maps.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 118
 </TD>
- <TD WIDTH=77>
- 14
+ <TD>
+ 14
 </TD>
- <TD WIDTH=69>
- 6-11
+ <TD>
+ 6-11
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Exported
+ <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 WIDTH=270>
- Create
+ <TD>
+ Create
 a new subclause [temp.export] containing 14p6-11. Move 14p12 ahead
 of this subclause.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 119
 </TD>
- <TD WIDTH=77>
- 14
+ <TD>
+ 14
 </TD>
- <TD WIDTH=69>
- 4
+ <TD>
+ 4
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Does
+ <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 WIDTH=270>
- Add
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 120
 </TD>
- <TD WIDTH=77>
- 14.1
+ <TD>
+ 14.1
 </TD>
- <TD WIDTH=69>
- 9
+ <TD>
+ 9
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- As
+ <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 WIDTH=270>
- Insert
+ <TD>
+ Insert
 “(8.3.5)” after “parameter pack” 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 121
 </TD>
- <TD WIDTH=77>
- 14.1
+ <TD>
+ 14.1
 </TD>
- <TD WIDTH=69>
- 18
+ <TD>
+ 18
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 example (that follows the normative text) has no begin example
 marker
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Prefix
+ <TD>
+ Prefix
 the example code with "[ Example:" 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 29
 </TD>
- <TD WIDTH=77>
+ <TD>
 
 14.3
 [Template arguments]
 
 
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 te
 </TD>
- <TD WIDTH=307>
+ <TD>
 Constant
 expressions of any literal type should be allowed as template
 arguments.
 </TD>
- <TD WIDTH=270>
+ <TD>
 
 
 </TD>
- <TD WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
+ <TD>
 
 US
 53
 </TD>
- <TD WIDTH=77>
+ <TD>
 
 14.5.1
 </TD>
- <TD WIDTH=69>
+ <TD>
 
 5
 </TD>
- <TD WIDTH=33>
+ <TD>
 
 te
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 
 If
@@ -8561,7 +8561,7 @@
 will get an implicitly-defined copy constructor that performs a
 copy of the pointers.
 </TD>
- <TD WIDTH=270>
+ <TD>
 
 Add
 to 14.5.1p5:
@@ -8575,61 +8575,61 @@
 template arguments for its template parameters) will be declared
 as a deleted function (8.4).
 </TD>
- <TD WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 122
 </TD>
- <TD WIDTH=77>
- 14.5.3
+ <TD>
+ 14.5.3
 </TD>
- <TD WIDTH=69>
- 4
+ <TD>
+ 4
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Variadic
+ <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 WIDTH=270>
- Add
+ <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 WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 30
 </TD>
- <TD WIDTH=77>
+ <TD>
 14.5.7
 [Template aliases]
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 te
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 When
 are two template alias names equivalent?
@@ -8674,347 +8674,347 @@
 
 
 </TD>
- <TD WIDTH=270>
+ <TD>
 
 
 </TD>
- <TD WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 17
 </TD>
- <TD WIDTH=77>
- 14.7.2
+ <TD>
+ 14.7.2
 </TD>
- <TD WIDTH=69>
- 2nd
+ <TD>
+ 2nd
 paragraph, 15th
 line
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- Replace
+ <TD>
+ Replace
 "from" with "forming"
 </TD>
- <TD WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- DE-14
+ <TD>
+ DE-14
 </TD>
- <TD WIDTH=77>
- 14.7.3
+ <TD>
+ 14.7.3
 
 
 </TD>
- <TD WIDTH=69>
- p1
+ <TD>
+ p1
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- DE-14
+ <TD>
+ DE-14
 The bulleted list neither addresses "member function template
 of a class" nor "member class template of a class".
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 the respective bullets.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 18
 </TD>
- <TD WIDTH=77>
- 14.7.3
+ <TD>
+ 14.7.3
 </TD>
- <TD WIDTH=69>
- 2nd
+ <TD>
+ 2nd
 paragraph, 2nd
 line
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 Typo,
- 
+ 
 any namespace from its
 enclosing namespace set
- 
+ 
 
 
- 
+ 
 should be
- 
+ 
 
 
- 
+ 
 any
 namespace 
 forming
 its enclosing namespace set
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Replace
+ <TD>
+ Replace
 "from" with "forming"
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 19
 </TD>
- <TD WIDTH=77>
- 14.8.2
+ <TD>
+ 14.8.2
 </TD>
- <TD WIDTH=69>
- 6th
+ <TD>
+ 6th
 paragraph, 1st
 line
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 Typo, duplicated "is"
- 
+ 
 "At
 certain points in the template argument deduction process it is
 is necessary"
- 
+ 
 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 Remove one
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 54
 </TD>
- <TD WIDTH=77>
+ <TD>
 14.9
 [concept],
- 14.10
+ 14.10
 [temp.constrained]
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- ge
+ <TD>
+ ge
 </TD>
- <TD WIDTH=307>
- Concepts is
+ <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 WIDTH=270>
- I
+ <TD>
+ I
 propose no specific change here. 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 55
 </TD>
- <TD WIDTH=77>
- 14.9.1
+ <TD>
+ 14.9.1
 </TD>
- <TD WIDTH=69>
- ¶
+ <TD>
+ ¶
 6
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 paragraph number is in the wrong place, causing a grammar rule to
 be indented more than its fellows.
 </TD>
- <TD WIDTH=270>
- Move
+ <TD>
+ Move
 the paragraph number so as to follow the grammar rules, thus
 numbering the single sentence, “The body of a concept …
 .”
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 56
 </TD>
- <TD WIDTH=77>
- 14.9.1
+ <TD>
+ 14.9.1
 </TD>
- <TD WIDTH=69>
- ¶
+ <TD>
+ ¶
 6
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 sentence contains two references to 14.9.1.3 [concept.req].
 </TD>
- <TD WIDTH=270>
- Change
+ <TD>
+ Change
 the second such reference (at the end of the sentence) to 14.9.1.4
 [concept.axiom].
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 57
 </TD>
- <TD WIDTH=77>
- 14.9.1.4
+ <TD>
+ 14.9.1.4
 </TD>
- <TD WIDTH=69>
- ¶
+ <TD>
+ ¶
 3
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- A
+ <TD>
+ A
 word is misplaced, changing the intended meaning.
 </TD>
- <TD WIDTH=270>
- Change
+ <TD>
+ Change
 “only find … if” to “find … only
 if”.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 58
 </TD>
- <TD WIDTH=77>
- 14.9.1.4
+ <TD>
+ 14.9.1.4
 </TD>
- <TD WIDTH=69>
- ¶
+ <TD>
+ ¶
 3
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 listed phrases are not grammatically parallel.
 </TD>
- <TD WIDTH=270>
- Insert
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
+ <TD>
 
 US
 59
 </TD>
- <TD WIDTH=77>
+ <TD>
 
 14.9.1.4
 </TD>
- <TD WIDTH=69>
+ <TD>
 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 
 te
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 Axioms
 are under-specified and provide little benefit to programmers, so
@@ -9029,7 +9029,7 @@
 that many axioms written by programmers (including those specified
 in the candidate draft) will be incorrect.
 </TD>
- <TD WIDTH=270>
+ <TD>
 
 Remove
 clause 14.9.1.4 [concept.axiom]
@@ -9086,28 +9086,28 @@
 
 
 </TD>
- <TD WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 31
 </TD>
- <TD WIDTH=77>
+ <TD>
 14.9.1.4
 [Axioms]
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 te
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 This
 section states that an axiom-definition defines a new semantics
@@ -9134,31 +9134,31 @@
 
 
 </TD>
- <TD WIDTH=270>
+ <TD>
 
 
 </TD>
- <TD WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- DE-15
+ <TD>
+ DE-15
 </TD>
- <TD WIDTH=77>
- 14.9.1.4
+ <TD>
+ 14.9.1.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- DE-15
+ <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
@@ -9167,34 +9167,34 @@
 EqualityComparable), but IEEE floating-point types have special
 values such as NaN violating the axioms.
 </TD>
- <TD WIDTH=270>
- Remove
+ <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 WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 123
 </TD>
- <TD WIDTH=77>
- 14.9.1.4
+ <TD>
+ 14.9.1.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- auto
+ <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
@@ -9202,63 +9202,63 @@
 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 WIDTH=270>
- Add
+ <TD>
+ Add
 a paragraph making axioms ill-formed inside an auto concept.
 </TD>
- <TD WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 UK 124
- 
+ 
 
 </TD>
- <TD WIDTH=77>
- 14.9.1.4
+ <TD>
+ 14.9.1.4
 </TD>
- <TD WIDTH=69>
- 6
+ <TD>
+ 6
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Spelling
+ <TD>
+ Spelling
 mistake, double-e in were.
 </TD>
- <TD WIDTH=270>
- weere
+ <TD>
+ weere
 -> were
 </TD>
- <TD WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 125
 </TD>
- <TD WIDTH=77>
- 14.9.1.4
+ <TD>
+ 14.9.1.4
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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
@@ -9266,208 +9266,208 @@
 defefinition' is to support declaring the equivalence of
 statements, a context where the operator will not actually be
 evaluated.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Define
+ <TD>
+ Define
 the semantics of the implicitly declared comparison operators, or
 restrict their usage to declaring equivalence between statements.
 </TD>
- <TD WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 126
 </TD>
- <TD WIDTH=77>
- 14.9.4
+ <TD>
+ 14.9.4
 </TD>
- <TD WIDTH=69>
- 41
+ <TD>
+ 41
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- This
+ <TD>
+ This
 paragraph contains the only definition of the underlying_type
 member - but it's a note, so not normative.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Move
+ <TD>
+ Move
 the second sentence to the Requires clause in paragraph 42.
 </TD>
- <TD WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 127
 </TD>
- <TD WIDTH=77>
- 14.9.4
+ <TD>
+ 14.9.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Provide
+ <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 WIDTH=270>
- Provide
+ <TD>
+ Provide
 the diagram. 
 
 </TD>
- <TD WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 128
 </TD>
- <TD WIDTH=77>
- 14.9.4
+ <TD>
+ 14.9.4
 </TD>
- <TD WIDTH=69>
- 4
+ <TD>
+ 4
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- It
+ <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 WIDTH=270>
- A
+ <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 WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 20
 </TD>
- <TD WIDTH=77>
- 14.9.4
+ <TD>
+ 14.9.4
 </TD>
- <TD WIDTH=69>
- 2nd
+ <TD>
+ 2nd
 paragraph
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <TD>
+ 
 Add TriviallyCopyableType that
 is trivially copyable type as concept.
 </TD>
- <TD WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 129
 </TD>
- <TD WIDTH=77>
- 14.10.1,
+ <TD>
+ 14.10.1,
 20.1.2
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- It
+ <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 WIDTH=270>
- Remove
+ <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 WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
+ <TD>
 
 US
 60
 </TD>
- <TD WIDTH=77>
+ <TD>
 
 14.10.1
 </TD>
- <TD WIDTH=69>
+ <TD>
 
 1
 </TD>
- <TD WIDTH=33>
+ <TD>
 
 te
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 The
 use of && as the separator for a list of requirements has
@@ -9480,7 +9480,7 @@
 changing the separator to ‘,’ would eliminate a
 significant source of confusion.
 </TD>
- <TD WIDTH=270>
+ <TD>
 
 Replace
 
@@ -9521,224 +9521,224 @@
 
 
 </TD>
- <TD WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 130
 </TD>
- <TD WIDTH=77>
- 15.1
+ <TD>
+ 15.1
 </TD>
- <TD WIDTH=69>
- 4
+ <TD>
+ 4
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- With
+ <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 WIDTH=270>
- Update
+ <TD>
+ Update
 sentence to allow for exceptions held in excpetion_ptr objects. 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 131
 </TD>
- <TD WIDTH=77>
- 15.3
+ <TD>
+ 15.3
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- A
+ <TD>
+ A
 handler catching its parameter by rvalue-reference is
 syntactically valid, but will never be activated.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Disallow
+ <TD>
+ Disallow
 handlers catching by rvalue-reference.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 132
 </TD>
- <TD WIDTH=77>
- 15.3
+ <TD>
+ 15.3
 </TD>
- <TD WIDTH=69>
- 16
+ <TD>
+ 16
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- There
+ <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 WIDTH=270>
- Rewite
+ <TD>
+ Rewite
 using copy-initialization rather than directly invoking the copy
 constructor 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 133
 </TD>
- <TD WIDTH=77>
- 15.4
+ <TD>
+ 15.4
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Template
+ <TD>
+ Template
 aliases have the same semantics as a typedef so should also be
 disallowed
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- add
+ <TD>
+ add
 "or alias-declaration" after "shall not appear in a
 typedef declaration". 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 134
 </TD>
- <TD WIDTH=77>
- 15.4
+ <TD>
+ 15.4
 </TD>
- <TD WIDTH=69>
- 6
+ <TD>
+ 6
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 sentance "An exception-specification can also include the
 class std::bad_exception (18.7.2.1)." is redundant.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Either
+ <TD>
+ Either
 strike the quoted sentance, or add a note explaining why it is
 worth calling special attention to this class. 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 135
 </TD>
- <TD WIDTH=77>
- 15.4
+ <TD>
+ 15.4
 </TD>
- <TD WIDTH=69>
- 8
+ <TD>
+ 8
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Unclear
+ <TD>
+ Unclear
 if std::unexpected is called before or after the function
 arguments have been destroyed
 </TD>
- <TD WIDTH=270>
- Clarify
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 136
 </TD>
- <TD WIDTH=77>
- 15.4
+ <TD>
+ 15.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ge
+ <TD>
+ Ge
 </TD>
- <TD WIDTH=307>
- Exception
+ <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
@@ -9746,8 +9746,8 @@
 the requirement to call the runtime unexpected mechanism was
 relaxed in this case.
 </TD>
- <TD WIDTH=270>
- Move
+ <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
@@ -9756,383 +9756,383 @@
 are always disabled. 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 137
 </TD>
- <TD WIDTH=77>
- 15.5
+ <TD>
+ 15.5
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- There
+ <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 WIDTH=270>
- Add
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 138
 </TD>
- <TD WIDTH=77>
- 15.5.1
+ <TD>
+ 15.5.1
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 third bullet is redundant with the first, as it is a subset of the
 same conditions.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Merge
+ <TD>
+ Merge
 the third bullet into the first bullet as a note or example. 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 139
 </TD>
- <TD WIDTH=77>
- 15.5.1
+ <TD>
+ 15.5.1
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- According
+ <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 WIDTH=270>
- Strike
+ <TD>
+ Strike
 the word 'user' from the first bullet point. 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 140
 </TD>
- <TD WIDTH=77>
- 15.5.2
+ <TD>
+ 15.5.2
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Add
+ <TD>
+ Add
 a note highlighting the default behaviour of std::unexpected if
 the user does not supply a hander-function 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 141
 </TD>
- <TD WIDTH=77>
- 15.6
+ <TD>
+ 15.6
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- This
+ <TD>
+ This
 whole subclause is redundant due to 15.1p5 and 15.3p17
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Strike
+ <TD>
+ Strike
 15.6 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 142
 </TD>
- <TD WIDTH=77>
- 16.3.5
+ <TD>
+ 16.3.5
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- This
+ <TD>
+ This
 paragraph opens with "[ Note" but has no corresponding
 "end note ]"
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 "end note ]"
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 143
 </TD>
- <TD WIDTH=77>
- 16.3.5
+ <TD>
+ 16.3.5
 </TD>
- <TD WIDTH=69>
- 7
+ <TD>
+ 7
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Example
+ <TD>
+ Example
 uses #define t(x,y.z) x ## y ## z
 </TD>
- <TD WIDTH=270>
- Change
+ <TD>
+ Change
 "x,y.z" to "x,y,z"
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 2
 </TD>
- <TD WIDTH=77>
- 17-30
+ <TD>
+ 17-30
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- ge/te
+ <TD>
+ ge/te
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- Appropriate
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 2
 </TD>
- <TD WIDTH=77>
- General
+ <TD>
+ General
 Comment
 </TD>
- <TD WIDTH=69>
- Library
+ <TD>
+ Library
 </TD>
- <TD WIDTH=33>
+ <TD>
 ge
 </TD>
- <TD WIDTH=307>
+ <TD>
 The
 adoption of the library `constexpr' proposal was not reflected in
 the draft, despite formal WG21 committee vote.
 </TD>
- <TD WIDTH=270>
- FR
+ <TD>
+ FR
 2
 </TD>
- <TD WIDTH=157>
- General
+ <TD>
+ General
 Comment
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 61
 </TD>
- <TD WIDTH=77>
- 17
+ <TD>
+ 17
 onward
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 concepts core language feature is applied to only some of the
 Standard Library clauses, and even then not always consistently.
 </TD>
- <TD WIDTH=270>
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- CA-2
+ <TD>
+ CA-2
 </TD>
- <TD WIDTH=77>
- 17
+ <TD>
+ 17
 Library
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ge
+ <TD>
+ Ge
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <TD>
+ 
 Fix the standard library so
 that “Concepts” are used appropriately in the library.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
+ <TD>
 
 US
 62
 </TD>
- <TD WIDTH=77>
+ <TD>
 
 17-30
 </TD>
- <TD WIDTH=69>
+ <TD>
 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 
 ge
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 Provide
 concepts and requirements clauses for all standard library
@@ -10140,73 +10140,73 @@
 
 
 </TD>
- <TD WIDTH=270>
+ <TD>
 
 
 </TD>
- <TD WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 63
 </TD>
- <TD WIDTH=77>
+ <TD>
 17-30
- 
+ 
 
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 behavior of the library in the presence of threads is incompletely
 specified.
- For
+ 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
+ Another
 example: does simultaneous access using operator at() to different
 characters in the same non-const string really introduce a data
 race?
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- DE-2
+ <TD>
+ DE-2
 </TD>
- <TD WIDTH=77>
- 17
+ <TD>
+ 17
 through 30
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- DE-2
+ <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
@@ -10214,1057 +10214,1057 @@
 apparently has not been reviewed for marking non-single-parameter
 constructors as "explicit".
 </TD>
- <TD WIDTH=270>
- Consider
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 21
 </TD>
- <TD WIDTH=77>
- 
+ <TD>
+ 
 
 
- 
+ 
 17 Library
- 
+ 
 21.2, 21.4,
- 27.2,
+ 27.2,
 27.6, 27.7, 27.8.1, 28.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 144
 </TD>
- <TD WIDTH=77>
- 17.1
+ <TD>
+ 17.1
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- List
+ <TD>
+ List
 of contents of library should be extened to cover new clauses
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 "regular expressions, atomic operations and threads" 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 145
 </TD>
- <TD WIDTH=77>
- 17.1
+ <TD>
+ 17.1
 </TD>
- <TD WIDTH=69>
- 6
+ <TD>
+ 6
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 Summary
 of numeric facilities should mention random numbers
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 random number framework to the list of library facilities
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 146
 </TD>
- <TD WIDTH=77>
- 17.1
+ <TD>
+ 17.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Add
+ <TD>
+ Add
 a summary paragraph for regular expressions
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 a summary paragraph for regular expressions 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 147
 </TD>
- <TD WIDTH=77>
- 17.1
+ <TD>
+ 17.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Add
+ <TD>
+ Add
 a summary paragraph for threads
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 a summary paragraph for threads 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 148
 </TD>
- <TD WIDTH=77>
- 17.2
+ <TD>
+ 17.2
 </TD>
- <TD WIDTH=69>
- Table
+ <TD>
+ Table
 12
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Table
+ <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 WIDTH=270>
- Make
+ <TD>
+ Make
 sure tables are rendered in the section to which they relate.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 149
 </TD>
- <TD WIDTH=77>
- 17.3
+ <TD>
+ 17.3
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- For
+ <TD>
+ For
 consistency with narrow-oriented and wide-oriented streams, we
 should add terms for streams of Unicode character sequences
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Define
+ <TD>
+ Define
 Utf16-oriented stream classes and Uft32-oriented stream classes
 for streams of char16_t/char32_t values.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 150
 </TD>
- <TD WIDTH=77>
- 17.3
+ <TD>
+ 17.3
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <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
@@ -11273,8 +11273,8 @@
 singular iterators suggest the term 'singular object' or 'the
 object is in a singular state'.
 </TD>
- <TD WIDTH=270>
- Define
+ <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
@@ -11284,780 +11284,780 @@
 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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 151
 </TD>
- <TD WIDTH=77>
- 17.3.1
+ <TD>
+ 17.3.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Missing
+ <TD>
+ Missing
 crossreference to 17.3.17 [defns.repositional.stream]
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 cross-reference in the existing empty brackets 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 152
 </TD>
- <TD WIDTH=77>
- 17.3.12
+ <TD>
+ 17.3.12
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Object
+ <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 WIDTH=270>
- Clarify
+ <TD>
+ Clarify
 terms and usage
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 153
 </TD>
- <TD WIDTH=77>
- 17.3.17
+ <TD>
+ 17.3.17
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- If
+ <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 WIDTH=270>
- Strike
+ <TD>
+ Strike
 the word 'only'. A note might be added to reinforce the intent 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 UK 154
- 
+ 
 
 </TD>
- <TD WIDTH=77>
- 17.3.20
+ <TD>
+ 17.3.20
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Missing
+ <TD>
+ Missing
 definition of a stable partition algorithm
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 definition from 25.2.12p7 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 155
 </TD>
- <TD WIDTH=77>
- 17.3.3
+ <TD>
+ 17.3.3
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Add
+ <TD>
+ Add
 clause 28 to list that use this definition of character
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 clause 28 to list that use this definition of character 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 156
 </TD>
- <TD WIDTH=77>
- 17.3.4
+ <TD>
+ 17.3.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Add
+ <TD>
+ Add
 regular expressions to set of templates using character container
 type
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 regular expressions to set of templates using character container
 type 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 157
 </TD>
- <TD WIDTH=77>
- 17.5.2.2
+ <TD>
+ 17.5.2.2
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Add
+ <TD>
+ Add
 concepts to the ordered list of presentation
- 
+ 
 
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 concepts into the sequence
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 158
 </TD>
- <TD WIDTH=77>
- 17.5.2.2
+ <TD>
+ 17.5.2.2
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- templates
+ <TD>
+ templates
 are neither classes nor functions
 </TD>
- <TD WIDTH=270>
- Replace
+ <TD>
+ Replace
 'classes' and 'functions' with 'classes and class templates' and
 'functions and function templates' 
 
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 159
 </TD>
- <TD WIDTH=77>
- 17.5.2.4
+ <TD>
+ 17.5.2.4
 </TD>
- <TD WIDTH=69>
- Footnote
+ <TD>
+ Footnote
 152
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- This
+ <TD>
+ This
 informative footnote was relevant in 1998, not 2008. The term
 'existing vendors' may imply something different now
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Strike
+ <TD>
+ Strike
 the footnote, or replace 'existing' with 'original' or similar 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 160
 </TD>
- <TD WIDTH=77>
- 17.5.2.4
+ <TD>
+ 17.5.2.4
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- requires
+ <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 WIDTH=270>
- Replace
+ <TD>
+ Replace
 'Requires' with 'Preconditions' 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 161
 </TD>
- <TD WIDTH=77>
- 17.5.2.4
+ <TD>
+ 17.5.2.4
 </TD>
- <TD WIDTH=69>
- 4
+ <TD>
+ 4
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- This
+ <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 WIDTH=270>
- Strike
+ <TD>
+ Strike
 17.5.2.4p4 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 162
 </TD>
- <TD WIDTH=77>
- 17.5.2.4
+ <TD>
+ 17.5.2.4
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Clause
+ <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 WIDTH=270>
- Add
+ <TD>
+ Add
 'Synchronization' to the list either between Effects: and
 Postconditions:, or between Returns: and Throws:.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 163
 </TD>
- <TD WIDTH=77>
- 17.5.2.4
+ <TD>
+ 17.5.2.4
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Many
+ <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 WIDTH=270>
- Introduce
+ <TD>
+ Introduce
 an explicit "Equivalent to", which defines all of the
 properties of the function.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 164
 </TD>
- <TD WIDTH=77>
- 17.5.3.2.1
+ <TD>
+ 17.5.3.2.1
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- This
+ <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 WIDTH=270>
- Use
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 165
 </TD>
- <TD WIDTH=77>
- 17.5.3.2.2,
+ <TD>
+ 17.5.3.2.2,
 17.5.3.2.3
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- constraints
+ <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 WIDTH=270>
- Adopt
+ <TD>
+ Adopt
 wording in line with the motivation described in N2235 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 166
 </TD>
- <TD WIDTH=77>
- 17.5.3.2.4.1,
+ <TD>
+ 17.5.3.2.4.1,
 17.5.3.3
- 
+ 
 
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- List
+ <TD>
+ List
 of library clauses should go up to 30, not 27
 </TD>
- <TD WIDTH=270>
- Replace
+ <TD>
+ Replace
 initial refernce to ch27 with ch30 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 167
 </TD>
- <TD WIDTH=77>
- 17.5.3.4
+ <TD>
+ 17.5.3.4
 Private members
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Comment
+ <TD>
+ Comment
 marker in wrong place.
 </TD>
- <TD WIDTH=270>
- Change:
+ <TD>
+ Change:
 // streambuf* sb; exposition only to streambuf* sb; // exposition
 only To reflect actual usage.
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 168
 </TD>
- <TD WIDTH=77>
- 17.6.2.2
+ <TD>
+ 17.6.2.2
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- We
+ <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 WIDTH=270>
- Replace
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 169
 </TD>
- <TD WIDTH=77>
- 17.6.2.2
+ <TD>
+ 17.6.2.2
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- This
+ <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 WIDTH=270>
- Resolve
+ <TD>
+ Resolve
 conflict in either place
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 170
 </TD>
- <TD WIDTH=77>
- 17.6.2.3
+ <TD>
+ 17.6.2.3
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- One
+ <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 WIDTH=270>
- Add
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 171
 </TD>
- <TD WIDTH=77>
- 17.6.2.4
+ <TD>
+ 17.6.2.4
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Does
+ <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 WIDTH=270>
- Either
+ <TD>
+ Either
 strike the references to abort, at_exit and exit, or clarify which
 headers only require partial support.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 172
 </TD>
- <TD WIDTH=77>
- 17.6.2.4
+ <TD>
+ 17.6.2.4
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- No
+ <TD>
+ No
 reference to new functions quick_exit and at_quick_exit
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 reference to quick_exit and at_quick_exit 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 173
 </TD>
- <TD WIDTH=77>
- 17.6.2.4
+ <TD>
+ 17.6.2.4
 </TD>
- <TD WIDTH=69>
- table
+ <TD>
+ table
 15
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- <initializer_list>
+ <TD>
+ <initializer_list>
 is missing from headers required in freestanding implementations.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 18.8, initializer lists, <initializer_list>, to the end of
 the table.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 23
 </TD>
- <TD WIDTH=77>
- 17.6.2.4
+ <TD>
+ 17.6.2.4
 </TD>
- <TD WIDTH=69>
- 2nd
+ <TD>
+ 2nd
 paragraph, Table 15
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 There is a freestanding
 implementation including <type_traits>, <array>,
 <ratio>, lately added to Table 13, C++ library
@@ -12065,229 +12065,229 @@
 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 WIDTH=270>
- 
+ <TD>
+ 
 Add <type_traits>,
 <array>, <ration> to Table 15.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 174
 </TD>
- <TD WIDTH=77>
- 17.6.3.2
+ <TD>
+ 17.6.3.2
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Replace
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 175
 </TD>
- <TD WIDTH=77>
- 17.6.4.2.1
+ <TD>
+ 17.6.4.2.1
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Local
+ <TD>
+ Local
 types can now be used to instantiate templates, but don't have
 external linkage
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Remove
+ <TD>
+ Remove
 the reference to external linkage 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 176
 </TD>
- <TD WIDTH=77>
- 17.6.4.3.3
+ <TD>
+ 17.6.4.3.3
 </TD>
- <TD WIDTH=69>
- Footnote
+ <TD>
+ Footnote
 175
- 
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Reference
+ <TD>
+ Reference
 to namespace ::std should be 17.6.4.2
 </TD>
- <TD WIDTH=270>
- Change
+ <TD>
+ Change
 referfence from 17.6.4.3 to 17.6.4.2 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 177
 </TD>
- <TD WIDTH=77>
- 17.6.4.3.4
+ <TD>
+ 17.6.4.3.4
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Sentence
+ <TD>
+ Sentence
 is redundant as double underscores are reserved in all contexts by
 17.6.4.3.3
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Strike
+ <TD>
+ Strike
 the sentence 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 178
 </TD>
- <TD WIDTH=77>
- 17.6.4.8
+ <TD>
+ 17.6.4.8
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Strike
+ <TD>
+ Strike
 the sentence 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 179
 </TD>
- <TD WIDTH=77>
- 17.6.4.8
+ <TD>
+ 17.6.4.8
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- According
+ <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 WIDTH=270>
- Replace
+ <TD>
+ Replace
 the word 'throws' with 'propogates' 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 22
 </TD>
- <TD WIDTH=77>
- 17.6.5.7
+ <TD>
+ 17.6.5.7
 </TD>
- <TD WIDTH=69>
- 4th
+ <TD>
+ 4th
 paragraph, 1st
 line
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 The statement below describes
 relation among two or more threads using words “between
 threads”: [Note: This means, for example, that
@@ -12295,259 +12295,259 @@
 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 WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 180
 </TD>
- <TD WIDTH=77>
- 17.6.5.10
+ <TD>
+ 17.6.5.10
 </TD>
- <TD WIDTH=69>
- 1,
+ <TD>
+ 1,
 4
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- It
+ <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 WIDTH=270>
- Add
+ <TD>
+ Add
 restriction that exception specification of virtual functions
 cannot be tightened.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 181
 </TD>
- <TD WIDTH=77>
- 17.6.5.10
+ <TD>
+ 17.6.5.10
 </TD>
- <TD WIDTH=69>
- Footnote
+ <TD>
+ Footnote
 186
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- This
+ <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 WIDTH=270>
- Clarify
+ <TD>
+ Clarify
 that this note does not mean the functions are genuinely declared
 with the specification, but are treated as-if. 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 182
 </TD>
- <TD WIDTH=77>
- 17.6.5.10
+ <TD>
+ 17.6.5.10
 </TD>
- <TD WIDTH=69>
- Footnote
+ <TD>
+ Footnote
 188
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- It
+ <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 WIDTH=270>
- Make
+ <TD>
+ Make
 this footnote normative
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 184
 </TD>
- <TD WIDTH=77>
- 18
+ <TD>
+ 18
 -> 30
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Replace
+ <TD>
+ Replace
 all typedef declarations in the standard library with
 alias-declarations, except in the standard C library.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 24
 </TD>
- <TD WIDTH=77>
- 18
+ <TD>
+ 18
 </TD>
- <TD WIDTH=69>
- 2nd
+ <TD>
+ 2nd
 paragraph, Table 16
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 Subclauses are listed in Table
 16 as:
- 
+ 
 "18.6 Type identification
 …"
- 
+ 
 "18.8 Initializer lists
 …"
- 
+ 
 "18.7 Exception handling
 …".
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 Sort them in the increasing
 order "18.6 Type identification …"
- 
+ 
 "18.7 Exception handling
 …".
- 
+ 
 "18.8 Initializer lists
 …"
- 
+ 
 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 25
 </TD>
- <TD WIDTH=77>
- 18.1
+ <TD>
+ 18.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 6th
 paragraph , last line, SEE ALSO
- 
+ 
 
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 max_align_t is described in
 18.1, so add 3.11 Alignment as the reference.
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 Add
 "3.11,
 Alignment"
 to SEE ALSO.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 32
 </TD>
- <TD WIDTH=77>
+ <TD>
 18.2.1
 [Numeric limits]
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 te
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 The
 definition of numeric_limits<> as requiring a regular type
@@ -12560,33 +12560,33 @@
 
 
 </TD>
- <TD WIDTH=270>
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- DE-16
+ <TD>
+ DE-16
 </TD>
- <TD WIDTH=77>
- 18.2.1
+ <TD>
+ 18.2.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
+ <TD>
 DE-16
 The class template numeric_limits
 should not specify the Regular
@@ -12598,158 +12598,158 @@
 available at
 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2794.html
 .
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Specify
+ <TD>
+ Specify
 a concept requirement with fewer constraints as appropriate, for
 example SemiRegular.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 26
 </TD>
- <TD WIDTH=77>
- 18.2.1.1
+ <TD>
+ 18.2.1.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 numeric_limits does not use
 concept.
 </TD>
- <TD WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- DE-17
+ <TD>
+ DE-17
 </TD>
- <TD WIDTH=77>
- 18.2.6
+ <TD>
+ 18.2.6
 
 
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
+ <TD>
 DE-17
 The class type_index
 should be removed; it provides no additional functionality beyond
 providing appropriate concept maps.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Specify
+ <TD>
+ Specify
 concept maps for "const type_info *" as required by the
 ordered and unordered containers and remove the class type_index.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 185
 </TD>
- <TD WIDTH=77>
- 18.3.1
+ <TD>
+ 18.3.1
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- There
+ <TD>
+ There
 is no header <stdint>, it should either be <stdint.h>
 or <cstdint>
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Replace
+ <TD>
+ Replace
 <stdint> with <cstdint>
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- DE-18
+ <TD>
+ DE-18
 </TD>
- <TD WIDTH=77>
- 18.4
+ <TD>
+ 18.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
+ <TD>
 DE-18
 The proposed C++ standard makes a considerable number of existing
 programs that have well-defined behavior according to ISO/IEC
@@ -12765,729 +12765,729 @@
 potentially undefined programs into well-defined ones. Note:
 This issue is contributing significantly to Germany's overall
 “no” vote.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Consider
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 186
 </TD>
- <TD WIDTH=77>
- 18.4
+ <TD>
+ 18.4
 </TD>
- <TD WIDTH=69>
- Footnote
+ <TD>
+ Footnote
 221
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- What
+ <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 WIDTH=270>
- Remove
+ <TD>
+ Remove
 the footnote
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 187
 </TD>
- <TD WIDTH=77>
- 18.4
+ <TD>
+ 18.4
 </TD>
- <TD WIDTH=69>
- 9
+ <TD>
+ 9
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 term "thread safe" is not defined nor used in this
 context anywhere else in the standard.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Clarify
+ <TD>
+ Clarify
 the intended meaing of "thread safe"
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 188
 </TD>
- <TD WIDTH=77>
- 18.4
+ <TD>
+ 18.4
 </TD>
- <TD WIDTH=69>
- 12
+ <TD>
+ 12
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Depends
+ <TD>
+ Depends
 on where _Exit comes from
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 189
 </TD>
- <TD WIDTH=77>
- 18.4,
+ <TD>
+ 18.4,
 18.7
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 addition of the [[noreturn]] attribute to the language will be an
 important aid for static analysis tools.
 </TD>
- <TD WIDTH=270>
- The
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 27
 </TD>
- <TD WIDTH=77>
- 18.4,
+ <TD>
+ 18.4,
 18.9, 18.7.2.2, 18.7.3.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 190
 </TD>
- <TD WIDTH=77>
- 18.5.1
+ <TD>
+ 18.5.1
 </TD>
- <TD WIDTH=69>
- various
+ <TD>
+ various
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- It
+ <TD>
+ It
 is not entirely clear how the current specification acts in the
 presence of a garbage collected implementation.
 </TD>
- <TD WIDTH=270>
- All
+ <TD>
+ All
 deallocation functions taking a pointer parameter should have a
 Precondition : ptr is a safely-derived pointer value.
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 191
 </TD>
- <TD WIDTH=77>
- 18.5.1.1
+ <TD>
+ 18.5.1.1
 </TD>
- <TD WIDTH=69>
- 4
+ <TD>
+ 4
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- According
+ <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 WIDTH=270>
- Rephrase
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 192
 </TD>
- <TD WIDTH=77>
- 18.5.1.2
+ <TD>
+ 18.5.1.2
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Fix
+ <TD>
+ Fix
 5.3.4p7 by required std::bad_alloc rather than std::length_error
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 193
 </TD>
- <TD WIDTH=77>
- 18.5.2.2
+ <TD>
+ 18.5.2.2
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- quick_exit
+ <TD>
+ quick_exit
 has been added as a new valid way to terminate a program in a well
 defined way
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Change
+ <TD>
+ Change
 3rd bullet: call either abort(), exit() or quick_exit();
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 194
 </TD>
- <TD WIDTH=77>
- 18.6
+ <TD>
+ 18.6
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Move
+ <TD>
+ Move
 type_index and hash<type_index> out of <typeinfo> and
 into a new header, <typeindex>.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 28
 </TD>
- <TD WIDTH=77>
- 18.6,
+ <TD>
+ 18.6,
 18.7, 19.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <TD>
+ 
 Consider other types.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 29
 </TD>
- <TD WIDTH=77>
- 18.7.6
+ <TD>
+ 18.7.6
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 throw_with_nested does not use
 concept.
 </TD>
- <TD WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 30
 </TD>
- <TD WIDTH=77>
- 18.7.6
+ <TD>
+ 18.7.6
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <TD>
+ 
 Consider nested_exception to
 support tree structure.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 31
 </TD>
- <TD WIDTH=77>
- 18.7.6
+ <TD>
+ 18.7.6
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 It is difficult to understand
 in which case nested_exception is applied.
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 Consider to add a sample
 program which rethrows exception.
- 
+ 
 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 195
 </TD>
- <TD WIDTH=77>
- 18.8
+ <TD>
+ 18.8
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Delete
+ <TD>
+ Delete
 the two concept maps from std::initializer_list.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 196
 </TD>
- <TD WIDTH=77>
- 18.8.3
+ <TD>
+ 18.8.3
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Concept
+ <TD>
+ Concept
 maps for initializer_list to Range should not be in language
 support headers, but instead in iterator concepts.
 </TD>
- <TD WIDTH=270>
- Remove
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 197
 </TD>
- <TD WIDTH=77>
- 19
+ <TD>
+ 19
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- All
+ <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 WIDTH=270>
- Provide
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 32
 </TD>
- <TD WIDTH=77>
- 19.1
+ <TD>
+ 19.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <TD>
+ 
 Consider to add footnote that
 recommends what() returns message easy to recognize what exception
 was thrown.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 64
 </TD>
- <TD WIDTH=77>
- 19.3
+ <TD>
+ 19.3
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Ge
+ <TD>
+ Ge
 </TD>
- <TD WIDTH=307>
- “ See
+ <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 WIDTH=270>
+ <TD>
 Delete
 this cross reference. If necessary, expand the main text to
 include the relevant referenced text
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 65
 </TD>
- <TD WIDTH=77>
- 20
+ <TD>
+ 20
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- Scoped
+ <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 WIDTH=270>
- 
+ <TD>
+ 
 Sketch of proposed resolution:
 Eliminate scoped allocators, replace allocator propagation traits
 with a simple uniform rule (e.g. always propagate on copy and
@@ -13495,7 +13495,7 @@
 explicitly allocate memory (e.g. pair), and adjust container
 interfaces to reflect this simplification. 
 
- 
+ 
 Components
 that I propose eliminating include 
 HasAllocatorType?,
@@ -13504,36 +13504,36 @@
 ConstructibleAsElement?.
 
 
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 198
 </TD>
- <TD WIDTH=77>
- 20
+ <TD>
+ 20
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 organization of clause 20 could be improved to better group
 related items, making the standard easier to navigate.
 </TD>
- <TD WIDTH=270>
- 20.6.7,
+ <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
@@ -13560,31 +13560,31 @@
 Tuples and pairs are closely related so merge tuple and pair into
 the same subclause - see more general comment on this 
 
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 199
 </TD>
- <TD WIDTH=77>
- 20.1.1,
+ <TD>
+ 20.1.1,
 20.1.2
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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
@@ -13592,528 +13592,528 @@
 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 WIDTH=270>
- Replace
+ <TD>
+ Replace
 the term 'program' with 'user'.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 200
 </TD>
- <TD WIDTH=77>
- 20.1.4
+ <TD>
+ 20.1.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- All
+ <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 WIDTH=270>
- Either
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 201
 </TD>
- <TD WIDTH=77>
- 20.1.5
+ <TD>
+ 20.1.5
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 Consistency axiom for LessThanComparable will not compile.
 </TD>
- <TD WIDTH=270>
- Add
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 33
 </TD>
- <TD WIDTH=77>
- 20.1.5
+ <TD>
+ 20.1.5
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 LessThanComparable and
 EqualityComparable don't correspond to NaN.
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 Apply concept_map to these
 concepts at FloatingPointType
- 
+ 
 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 66
 </TD>
- <TD WIDTH=77>
- 20.1.10
+ <TD>
+ 20.1.10
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- Application
+ <TD>
+ Application
 of the "Regular" concept to floating-point types appears
 to be controversial (see long discussion on std-lib reflector).
 </TD>
- <TD WIDTH=270>
- State
+ <TD>
+ State
 that the “Regular” concept does not apply to
 floating-point types.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 34
 </TD>
- <TD WIDTH=77>
- 20.2
+ <TD>
+ 20.2
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 1st
 paragraph, 4th
 line
- 
+ 
 
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 Though N2672 pointed at adding
 "#include<initializer_list>", it isn't reflected.
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 add followings
- 
+ 
 #include <initializer_list>
 // for concept_map
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 67
 </TD>
- <TD WIDTH=77>
- 20.2.1
+ <TD>
+ 20.2.1
 </TD>
- <TD WIDTH=69>
- ¶
+ <TD>
+ ¶
 5 first sent.
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- Some
+ <TD>
+ Some
 connective words are missing.
 </TD>
- <TD WIDTH=270>
- Insert
+ <TD>
+ Insert
 “corresponding to” before “an lvalue reference
 type.”
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 35
 </TD>
- <TD WIDTH=77>
- 20.2.3
+ <TD>
+ 20.2.3
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 6th
 paragraph, 1st
 line
- 
+ 
 
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 Typo,
- "stdforward"
+ "stdforward"
 should be "std::forward"
 </TD>
- <TD WIDTH=270>
- Correct
+ <TD>
+ Correct
 typo.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 202
 </TD>
- <TD WIDTH=77>
- 20.2.4
+ <TD>
+ 20.2.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Remove
+ <TD>
+ Remove
 the std:: qualification from these references to pair.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 68
 </TD>
- <TD WIDTH=77>
- 20.2.12
+ <TD>
+ 20.2.12
 </TD>
- <TD WIDTH=69>
- IntegralLike
+ <TD>
+ IntegralLike
 </TD>
- <TD WIDTH=33>
- te/ed
+ <TD>
+ te/ed
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 code defining the context is syntactically incorrect.
 </TD>
- <TD WIDTH=270>
- Insert
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 203
 </TD>
- <TD WIDTH=77>
- 20.3.2
+ <TD>
+ 20.3.2
 </TD>
- <TD WIDTH=69>
- 1-4
+ <TD>
+ 1-4
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 ratio_xyz types have a misplaced '}'. For example: template <class
 R1, class R2> struct ratio_add { typedef see below} type; ;
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Move
+ <TD>
+ Move
 the '}' to after the typedef: template <class R1, class R2>
 struct ratio_add { typedef see below type; };
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 36
 </TD>
- <TD WIDTH=77>
- 20.4.2.1
+ <TD>
+ 20.4.2.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 19th
 paragraph, 6th
 line
- 
+ 
 
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 Typo.
- 
+ 
 "it it" should be
 "it is"
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 Correct typo.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 204
 </TD>
- <TD WIDTH=77>
- 20.5
+ <TD>
+ 20.5
 </TD>
- <TD WIDTH=69>
- Table
+ <TD>
+ Table
 41
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- It
+ <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 WIDTH=270>
- Restore
+ <TD>
+ Restore
 aligned_union template that was removed by LWG issue 856.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 69
 </TD>
- <TD WIDTH=77>
- 20.5
+ <TD>
+ 20.5
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- This
+ <TD>
+ This
 section, dealing with tuple<>, should be in the same section
 as the similar utility pair<>.
 </TD>
- <TD WIDTH=270>
- Restructure
+ <TD>
+ Restructure
 Clause 20 so as to bring these similar components together.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 205
 </TD>
- <TD WIDTH=77>
- 20.5.3
+ <TD>
+ 20.5.3
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- integral_constant
+ <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 WIDTH=270>
- Add
+ <TD>
+ Add
 a constexpr conversion operator to class tempalate
 integral_constant: constexpr operator value_type() { return value;
 }
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 206
 </TD>
- <TD WIDTH=77>
- 20.5.5
+ <TD>
+ 20.5.5
 </TD>
- <TD WIDTH=69>
- para
+ <TD>
+ para
 4
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Currently
+ <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 WIDTH=270>
- Change:
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 207
 </TD>
- <TD WIDTH=77>
- 20.5.6.1
+ <TD>
+ 20.5.6.1
 </TD>
- <TD WIDTH=69>
- Table
+ <TD>
+ Table
 36
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- suffix
+ <TD>
+ suffix
 "::type" is missing from the some of the examples.
 </TD>
- <TD WIDTH=270>
- Change:
+ <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
@@ -14130,153 +14130,153 @@
 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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 37
 </TD>
- <TD WIDTH=77>
- 20.5.7
+ <TD>
+ 20.5.7
 </TD>
- <TD WIDTH=69>
- Table
+ <TD>
+ Table
 41
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <TD>
+ 
 Add ”.”
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 70
 </TD>
- <TD WIDTH=77>
- 20.6
+ <TD>
+ 20.6
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- Specifications
+ <TD>
+ Specifications
 now expressed via narrative text are more accurately and clearly
 expressed via executable code.
 </TD>
- <TD WIDTH=270>
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 71
 </TD>
- <TD WIDTH=77>
- 20.6.7
+ <TD>
+ 20.6.7
 </TD>
- <TD WIDTH=69>
- Table
+ <TD>
+ Table
 51, last row, column 3
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 grammar is incorrect.
 </TD>
- <TD WIDTH=270>
- Change
+ <TD>
+ Change
 “conversion are” to “conversion is”.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 38
 </TD>
- <TD WIDTH=77>
- 20.6.12.1.3
+ <TD>
+ 20.6.12.1.3
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <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
@@ -14284,712 +14284,712 @@
 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 WIDTH=270>
- 
+ <TD>
+ 
 Add
 the following requirements. "it
 has a public move constructor that performs a member-wise move."
- 
+ 
 Add the MoveConstructible.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 39
 </TD>
- <TD WIDTH=77>
- 20.6.16.2
+ <TD>
+ 20.6.16.2
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 There are no requires
 corresponding to F of std::function.
 </TD>
- <TD WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 40
 </TD>
- <TD WIDTH=77>
- 20.6.16.2
+ <TD>
+ 20.6.16.2
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 Thougn it's "Allocator
 Aloc" at other places, it's "Allocator A" only
 std::function constructor template parameter.
 </TD>
- <TD WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 41
 </TD>
- <TD WIDTH=77>
- 20.6.16.2
+ <TD>
+ 20.6.16.2
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 There are no requires
 corresponding to R and Args of UsesAllocator.
 </TD>
- <TD WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 42
 </TD>
- <TD WIDTH=77>
- 20.6.16.2
+ <TD>
+ 20.6.16.2
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 208
 </TD>
- <TD WIDTH=77>
- 20.6.17
+ <TD>
+ 20.6.17
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- std::hash
+ <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 WIDTH=270>
- .
+ <TD>
+ .
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 209
 </TD>
- <TD WIDTH=77>
- 20.7
+ <TD>
+ 20.7
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Smart
+ <TD>
+ Smart
 pointers cannot be used in constrained templates
 </TD>
- <TD WIDTH=270>
- Provide
+ <TD>
+ Provide
 constraints for smart pointers 
 
- 
+ 
 
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 213
 </TD>
- <TD WIDTH=77>
- 20.7.6
+ <TD>
+ 20.7.6
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- std::allocator
+ <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 WIDTH=270>
- The
+ <TD>
+ The
 primary allocator template should be constrained to require
 ObjectType<T> and FreeStoreAllocatable<T>. Further
 operations to be constrained as required.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 214
 </TD>
- <TD WIDTH=77>
- 20.7.8
+ <TD>
+ 20.7.8
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- raw_storage_iterator
+ <TD>
+ raw_storage_iterator
 needs constraining as an iterator adaptor to be safely used in
 constrained templates
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Constrain
+ <TD>
+ Constrain
 the raw_storage_iterator template
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 210
 </TD>
- <TD WIDTH=77>
- 20.7.11
+ <TD>
+ 20.7.11
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Specialized
+ <TD>
+ Specialized
 algorithms for memory managenment need requirements to be easily
 usable in constrained templates
 </TD>
- <TD WIDTH=270>
- Provide
+ <TD>
+ Provide
 constraints for all algorithms in 20.7.11
- 
+ 
 
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- DE-20
+ <TD>
+ DE-20
 </TD>
- <TD WIDTH=77>
- 20.7.12
+ <TD>
+ 20.7.12
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- DE-20
+ <TD>
+ DE-20
 The section heading and the first sentence use the term "template
 function", which is undefined.
 </TD>
- <TD WIDTH=270>
+ <TD>
 Replace
 "template function" by "function template". 
 
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
+ <TD>
 
 US
 72
 </TD>
- <TD WIDTH=77>
- 20.7.12
+ <TD>
+ 20.7.12
 </TD>
- <TD WIDTH=69>
+ <TD>
 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 
 te
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 bind should support move-only
 functors and bound arguments.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
+ <TD>
 
 
 </TD>
- <TD WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- DE-21
+ <TD>
+ DE-21
 </TD>
- <TD WIDTH=77>
- 20.7.12.1.3
+ <TD>
+ 20.7.12.1.3
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- DE-21
+ <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 WIDTH=270>
- Add
+ <TD>
+ Add
 the missing specification in the same section, or add a
 cross-reference indicating the section where the specification
 appears.
 </TD>
- <TD WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 211
 </TD>
- <TD WIDTH=77>
- 20.7.12.2.3
+ <TD>
+ 20.7.12.2.3
 </TD>
- <TD WIDTH=69>
- 11
+ <TD>
+ 11
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Change
+ <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 WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 212
 </TD>
- <TD WIDTH=77>
- 20.7.13.7
+ <TD>
+ 20.7.13.7
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Move
+ <TD>
+ Move
 this specification to 18.5. Move the declarations into the header
 <new>.
 </TD>
- <TD WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- DE-22
+ <TD>
+ DE-22
 </TD>
- <TD WIDTH=77>
- 20.7.16.2
+ <TD>
+ 20.7.16.2
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- DE-22
+ <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 WIDTH=270>
- Consider
+ <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 WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
+ <TD>
 
 US
 73
 </TD>
- <TD WIDTH=77>
+ <TD>
 
 20.7.18
 </TD>
- <TD WIDTH=69>
+ <TD>
 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 
 te
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 The
 std::reference_closure template is redundant with std::function
@@ -15018,7 +15018,7 @@
 
 
 </TD>
- <TD WIDTH=270>
+ <TD>
 
 Remove
 20.7.18 [func.referenceclosure].
@@ -15028,30 +15028,30 @@
 Remove
 5.1.1 paragraph 12.
 </TD>
- <TD WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
+ <TD>
 
 US
 74
 </TD>
- <TD WIDTH=77>
+ <TD>
 
 20.8
 </TD>
- <TD WIDTH=69>
+ <TD>
 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 
 te
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 Scoped
 allocators represent a poor trade-off for standardization, since
@@ -15080,7 +15080,7 @@
 
 
 </TD>
- <TD WIDTH=270>
+ <TD>
 
 Remove
 support for scoped allocators from the working paper. This
@@ -15111,180 +15111,180 @@
 
 
 </TD>
- <TD WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 74
 </TD>
- <TD WIDTH=77>
- 20.8.2.2
+ <TD>
+ 20.8.2.2
 </TD>
- <TD WIDTH=69>
- (a)
+ <TD>
+ (a)
 synopsis (b) after ¶ 14
 </TD>
- <TD WIDTH=33>
- te/ed
+ <TD>
+ te/ed
 </TD>
- <TD WIDTH=307>
- A
+ <TD>
+ A
 concept name is twice misspelled.
 </TD>
- <TD WIDTH=270>
- Change
+ <TD>
+ Change
 “Hasconstructor” to “HasConstructor”
 (twice).
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 75
 </TD>
- <TD WIDTH=77>
- 20.8.2.2
+ <TD>
+ 20.8.2.2
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- Allocator
+ <TD>
+ Allocator
 concepts are incomplete
 </TD>
- <TD WIDTH=270>
+ <TD>
 See
 paper:
 http://www.halpernwightsoftware.com/WG21/n2810_allocator_defects.pdf>
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 43
 </TD>
- <TD WIDTH=77>
- 20.8.3
+ <TD>
+ 20.8.3
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 Typo.
- 
+ 
 "alloc" should be
 "Alloc"
 </TD>
- <TD WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 215
 </TD>
- <TD WIDTH=77>
- 20.8.3.3
+ <TD>
+ 20.8.3.3
 </TD>
- <TD WIDTH=69>
- 6,8
+ <TD>
+ 6,8
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Extra
+ <TD>
+ Extra
 pair of {}, presumably some formatting code gone awry : duration&
 operator-{-}();
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Remove
+ <TD>
+ Remove
 the {} or fix formatting
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
+ <TD>
 
 US
 77
 </TD>
- <TD WIDTH=77>
+ <TD>
 
 20.8.4
 </TD>
- <TD WIDTH=69>
+ <TD>
 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 
 te
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 Allocator-specific
 move and copy behavior for containers (N2525) complicates a
@@ -15308,7 +15308,7 @@
 
 
 </TD>
- <TD WIDTH=270>
+ <TD>
 
 Remove
 20.8.4.
@@ -15324,36 +15324,36 @@
 all references to the facilities in 20.8.4 and 20.8.5 from clause
 23.
 </TD>
- <TD WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 78
 </TD>
- <TD WIDTH=77>
- 20.8.12,
+ <TD>
+ 20.8.12,
 20.8.13.2
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- There
+ <TD>
+ There
 is presently no way to convert directly from a <CODE>
 shared_ptr</CODE>
 to a <CODE>
 unique_ptr</CODE>.
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 Add
 an interface that performs the conversion. See the attached,
 Issues with the C++ Standard" paper under Chapter 20,
@@ -15361,187 +15361,187 @@
 shared_ptr</CODE>
 to <CODE>
 unique_ptr".</CODE>
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
+ <TD>
 
 US
 79
 </TD>
- <TD WIDTH=77>
- 20.8.12.2.1
+ <TD>
+ 20.8.12.2.1
 </TD>
- <TD WIDTH=69>
+ <TD>
 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 
 te
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
+ <TD>
 
 
 </TD>
- <TD WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 44
 </TD>
- <TD WIDTH=77>
- 20.8.13.6
+ <TD>
+ 20.8.13.6
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <TD>
+ 
 Change shared_ptr<T>&
 or add the "p shall not be a null pionter" at the
 requires.
 </TD>
- <TD WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 45
 </TD>
- <TD WIDTH=77>
- 20.9
+ <TD>
+ 20.9
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <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 WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 80
 </TD>
- <TD WIDTH=77>
- 20.9.2.1
+ <TD>
+ 20.9.2.1
 </TD>
- <TD WIDTH=69>
- Heading
+ <TD>
+ Heading
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 section heading does not describe the contents.
 </TD>
- <TD WIDTH=270>
+ <TD>
 Change
 the heading “is_floating_point”
 to “treat_as_floating_point”.
 Optionally adjust the section’s label similarly.
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
+ <TD>
 
 US
 81
 </TD>
- <TD WIDTH=77>
- 20.9.3
+ <TD>
+ 20.9.3
 </TD>
- <TD WIDTH=69>
+ <TD>
 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 
 te
 </TD>
- <TD WIDTH=307>
- 
+ <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
@@ -15549,45 +15549,45 @@
 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 WIDTH=270>
+ <TD>
 
 Add:
 
 
- 
+ 
 template <class Rep, class
 Period = ratio<1>> 
 
- 
+ 
 class duration { 
 
- 
+ 
 public: 
 
 
@@ -15644,1183 +15644,1183 @@
 
 
 </TD>
- <TD WIDTH=157>
+ <TD>
 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 82
 </TD>
- <TD WIDTH=77>
- 20.9.5.3
+ <TD>
+ 20.9.5.3
 </TD>
- <TD WIDTH=69>
- after
+ <TD>
+ after
 ¶ 1
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 code synopsis has a minor alignment error.
 </TD>
- <TD WIDTH=270>
- Align
+ <TD>
+ Align
 “rep” with the other symbols defined in this synopsis.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 216
 </TD>
- <TD WIDTH=77>
- 21
+ <TD>
+ 21
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- All
+ <TD>
+ All
 the containers use concepts for their iterator usage, exect for
 basic_string. This needs fixing.
 </TD>
- <TD WIDTH=270>
- Use
+ <TD>
+ Use
 concepts for iterator template parameters throughout the chapter.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 46
 </TD>
- <TD WIDTH=77>
- 21.2,
+ <TD>
+ 21.2,
 21.3
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 The basic_string does not use
 concept.
 </TD>
- <TD WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 47
 </TD>
- <TD WIDTH=77>
- 21.3
+ <TD>
+ 21.3
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 Typo. Missing ”>”
- 
+ 
 template <class charT,
 class traits, Allocator Alloc
- 
+ 
 
 
- 
+ 
 should be
- 
+ 
 
 
- 
+ 
 template <class charT,
 class traits, Allocator Alloc>
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 Correct typo.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 48
 </TD>
- <TD WIDTH=77>
- 21.3
+ <TD>
+ 21.3
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <TD>
+ 
 Add a concept for char_traits.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 217
 </TD>
- <TD WIDTH=77>
- 21.3
+ <TD>
+ 21.3
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- basic_string
+ <TD>
+ basic_string
 refers to constructible_with_allocator_suffix, which I thought was
 removed?
 </TD>
- <TD WIDTH=270>
- Remove
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 218
 </TD>
- <TD WIDTH=77>
- 21.3.1
+ <TD>
+ 21.3.1
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- See
+ <TD>
+ See
 my recommendations for "23.2.1, 23.2.6".
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 219
 </TD>
- <TD WIDTH=77>
- 21.3.6.6
+ <TD>
+ 21.3.6.6
 [string.replace]
 </TD>
- <TD WIDTH=69>
- 11
+ <TD>
+ 11
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Effects
+ <TD>
+ Effects
 refers to "whose first begin() - i1 elements" However i1
 is greater than begin()...
 </TD>
- <TD WIDTH=270>
- Effects
+ <TD>
+ Effects
 refers to "whose first i1 - begin() elements" 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 220
 </TD>
- <TD WIDTH=77>
- 21.3.8.9
+ <TD>
+ 21.3.8.9
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Use
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 33
 </TD>
- <TD WIDTH=77>
+ <TD>
 22.1.1
 [locale]
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
+ <TD>
 ed
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 ios_base::iostate
 err = 0;
@@ -16832,167 +16832,167 @@
 goodbit
 is the solution.
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 49
 </TD>
- <TD WIDTH=77>
- 22.1.3.2.2
+ <TD>
+ 22.1.3.2.2
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <TD>
+ 
 Add a concept for codecvt.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 50
 </TD>
- <TD WIDTH=77>
- 22.1.3.2.2
+ <TD>
+ 22.1.3.2.2
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 Add custom allocator parameter
 to wstring_convert, since we cannot allocate memory for strings
 from a custom allocator.
 </TD>
- <TD WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FI
+ <TD>
+ FI
 4
 </TD>
- <TD WIDTH=77>
+ <TD>
 22.2.1.4.1
- 22.2.1.4.2
+ 22.2.1.4.2
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- <TT>to_end
+ <TD>
+ <TT>to_end
 and to_limit are both used. Only one is needed.</TT>
 </TD>
- <TD WIDTH=270>
- Change
+ <TD>
+ Change
 to_limit to to_end.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FI
+ <TD>
+ FI
 5
 </TD>
- <TD WIDTH=77>
- <TT>22.2.1.4.2
+ <TD>
+ <TT>22.2.1.4.2
 </TT>
 
 </TD>
- <TD WIDTH=69>
- #3
+ <TD>
+ #3
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
+ <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> 
@@ -17002,7 +17002,7 @@
 <TT>Also,
 the sentence applies to all the examples, including do_in and
 do_out.</TT>
- <TT>Reasoning:
+ <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
@@ -17011,36 +17011,36 @@
 unaltered, to_next is advanced, state is altered and return value
 is partial.</TT>
 </TD>
- <TD WIDTH=270>
- <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>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FI
+ <TD>
+ FI
 6
 </TD>
- <TD WIDTH=77>
+ <TD>
 22.2.1.5
- See
+ See
 also 22.2.1.4 (1,2,3)
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
+ <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
@@ -17052,478 +17052,478 @@
 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 WIDTH=270>
- <TT>There
+ <TD>
+ <TT>There
 should be a built-in means to find a codecvt with a pair of
 character set names. </TT>
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FI
+ <TD>
+ FI
 7
 </TD>
- <TD WIDTH=77>
- 22.2.1.4
+ <TD>
+ 22.2.1.4
 </TD>
- <TD WIDTH=69>
- 1,2,3
+ <TD>
+ 1,2,3
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
+ <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 WIDTH=270>
- Change
+ <TD>
+ Change
 "codeset" to "character set."
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 51
 </TD>
- <TD WIDTH=77>
- 22.2.5.1.1
+ <TD>
+ 22.2.5.1.1
 </TD>
- <TD WIDTH=69>
- 7th
+ <TD>
+ 7th
 paragraph, 1st
 line
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <TD>
+ 
 Correct as follows.
- 
+ 
 Requires: [fmt,end) shall be
 a valid range.
- 
+ 
 
 
- 
+ 
 should be
- 
+ 
 
 
- 
+ 
 Requires: [fmt,fmtend) shall
 be a valid range.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 52
 </TD>
- <TD WIDTH=77>
- 22.2.5.1,
+ <TD>
+ 22.2.5.1,
 22.2.5.2, 22.2.6.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 InputIterator does not use
 concept.
 </TD>
- <TD WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 53
 </TD>
- <TD WIDTH=77>
- 22.2.5.3
+ <TD>
+ 22.2.5.3
 , 22.2.5.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 OutputIterator does not use
 concept.
 </TD>
- <TD WIDTH=270>
- 
+ <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
+ typedef OutputIter
 iter_type;
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 54
 </TD>
- <TD WIDTH=77>
- 23
+ <TD>
+ 23
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 2nd
 paragraph, Table 79
- 
+ 
 
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 There is not <forward_list>
 in Table 79.
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 Add <forward_list>
 between <deque> and <list>.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 221
 </TD>
- <TD WIDTH=77>
- 23
+ <TD>
+ 23
 </TD>
- <TD WIDTH=69>
- Table
+ <TD>
+ Table
 79
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 table is missing the new <forward_list> header.
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 <forward_list> to the table for sequence containers.
 Alternative (technical) solution might be to merge <forward_list>
 into <list>.
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 222
 </TD>
- <TD WIDTH=77>
- 23
+ <TD>
+ 23
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- It
+ <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
@@ -17534,11 +17534,11 @@
 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 WIDTH=270>
- Clarify
+ <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
@@ -17548,526 +17548,526 @@
 introduction should mention it does not provide the required size
 operation as it cannot be implemented efficiently.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 55
 </TD>
- <TD WIDTH=77>
- 23.1.1
+ <TD>
+ 23.1.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 3rd
 paragraph, 4th
 line
- 
+ 
 
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 It seems that “the
 MinimalAllocator concep” is the typo of “the
 MinimalAllocator concept”.
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 Change
 to … models the MinimalAllocator concept.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 223
 </TD>
- <TD WIDTH=77>
- 23.1.1
+ <TD>
+ 23.1.1
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 library does not define the MinimalAllocator or ScopedAllocator
 concepts, these were part of an earlier Allocators proposal that
 was rejected.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Remove
+ <TD>
+ Remove
 the references to MinimalAllocator and ScopedAllocator, or add
 definitions for these concepts to clause 20.7.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 224
 </TD>
- <TD WIDTH=77>
- 23.1.1
+ <TD>
+ 23.1.1
 </TD>
- <TD WIDTH=69>
- 8
+ <TD>
+ 8
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- This
+ <TD>
+ This
 paragraph implicitly requires all containers in clause 23 to
 support allocators, which std::array does not.
 </TD>
- <TD WIDTH=270>
- Add
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 225
 </TD>
- <TD WIDTH=77>
- 23.1.1
+ <TD>
+ 23.1.1
 </TD>
- <TD WIDTH=69>
- Table
+ <TD>
+ Table
 81
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Inconsistent
+ <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 WIDTH=270>
- Change
+ <TD>
+ Change
 return types for X::(const)_reverse_iterator to say "iterator
 type whose value type is (const) T". 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 226
 </TD>
- <TD WIDTH=77>
- 23.1.1
+ <TD>
+ 23.1.1
 </TD>
- <TD WIDTH=69>
- 10
+ <TD>
+ 10
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- <array>
+ <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 WIDTH=270>
- If
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 227
 </TD>
- <TD WIDTH=77>
- 23.1.1
+ <TD>
+ 23.1.1
 </TD>
- <TD WIDTH=69>
- Table
+ <TD>
+ Table
 80
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 post-condition for a = rv uses the word “construction”
 when it means “assignment”
 </TD>
- <TD WIDTH=270>
- Replace
+ <TD>
+ Replace
 the word “construction” with the word “assignment”
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 228
 </TD>
- <TD WIDTH=77>
- 23.1.1
+ <TD>
+ 23.1.1
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Line
+ <TD>
+ Line
 4 contains a spelling mistake in the fragment "MinimalAllocator
 concep."
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Replace
+ <TD>
+ Replace
 "concep" with "concept"
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 229
 </TD>
- <TD WIDTH=77>
- 23.1.1
+ <TD>
+ 23.1.1
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 fragment "A container may directly call constructors" is
 not technically correct as constructors are not callable.
 </TD>
- <TD WIDTH=270>
- Replace
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 230
 </TD>
- <TD WIDTH=77>
- 23.1.2
+ <TD>
+ 23.1.2
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- “implementations
+ <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 WIDTH=270>
- Clarify
+ <TD>
+ Clarify
 what is meant and what requirements an implementation must
 satisfy.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 56
 </TD>
- <TD WIDTH=77>
- 23.1.3
+ <TD>
+ 23.1.3
 </TD>
- <TD WIDTH=69>
- 12th
+ <TD>
+ 12th
 paragraph, Table 84
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 `array’ is unstated in
 Table 84 - Optional sequence container operations.
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 Add `array’ to Container
 field for the following Expression.
- 
+ 
 a.front()
- 
+ 
 a.back()
- 
+ 
 a[n]
- 
+ 
 a.at(n)
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 231
 </TD>
- <TD WIDTH=77>
- 23.1.3
+ <TD>
+ 23.1.3
 </TD>
- <TD WIDTH=69>
- 9-11
+ <TD>
+ 9-11
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- These
+ <TD>
+ These
 paragraphs are redundant now that Concepts define what it means to
 be an Iterator and guide overload resolution accordingly.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Strike
+ <TD>
+ Strike
 23.1.3p9-11. Make sure std::basic_string has constraints similar
 to std::vector to meet this old guarantee.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 232
 </TD>
- <TD WIDTH=77>
- 23.1.3
+ <TD>
+ 23.1.3
 </TD>
- <TD WIDTH=69>
- Table
+ <TD>
+ Table
 84
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- match_results
+ <TD>
+ match_results
 may follow the requirements but is not listed a general purpose
 library container.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Remove
+ <TD>
+ Remove
 reference to match_results against a[n] operation
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 233
 </TD>
- <TD WIDTH=77>
- 23.1.3
+ <TD>
+ 23.1.3
 </TD>
- <TD WIDTH=69>
- Table
+ <TD>
+ Table
 84
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Add
+ <TD>
+ Add
 references to the new containers.
 </TD>
- <TD WIDTH=270>
- Add
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 234
 </TD>
- <TD WIDTH=77>
- 23.1.3
+ <TD>
+ 23.1.3
 </TD>
- <TD WIDTH=69>
- Table
+ <TD>
+ Table
 84
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Ther
+ <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 WIDTH=270>
- Replace
+ <TD>
+ Replace
 iterator with auto in semantics for back: { auto tmp = a.end();
 --tmp; return *tmp; }
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 235
 </TD>
- <TD WIDTH=77>
- 23.1.3
+ <TD>
+ 23.1.3
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- “The
+ <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 WIDTH=270>
- Change
+ <TD>
+ Change
 the text to read: “The library provides five basic kinds of
 sequence containers: array, deque, forward_list, list and vector”.
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 236
 </TD>
- <TD WIDTH=77>
- 23.1.3
+ <TD>
+ 23.1.3
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- [
+ <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
@@ -18079,67 +18079,67 @@
 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 WIDTH=270>
- Remove
+ <TD>
+ Remove
 this paragraph
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 237
 </TD>
- <TD WIDTH=77>
- 23.1.3
+ <TD>
+ 23.1.3
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- vector,
+ <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 WIDTH=270>
- Modify
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 238
 </TD>
- <TD WIDTH=77>
- 23.1.4
+ <TD>
+ 23.1.4
 </TD>
- <TD WIDTH=69>
- 6
+ <TD>
+ 6
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Leaving
+ <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
@@ -18147,74 +18147,74 @@
 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 WIDTH=270>
- Change
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 239
 </TD>
- <TD WIDTH=77>
- 23.1.4
+ <TD>
+ 23.1.4
 </TD>
- <TD WIDTH=69>
- 85
+ <TD>
+ 85
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- It
+ <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 WIDTH=270>
- Add
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 240
 </TD>
- <TD WIDTH=77>
- 23.1.6.1
+ <TD>
+ 23.1.6.1
 </TD>
- <TD WIDTH=69>
- 12
+ <TD>
+ 12
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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
@@ -18224,11 +18224,11 @@
 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 WIDTH=270>
- Remove
+ <TD>
+ Remove
 the * to deference the returned iterator either side of the == in
 the EmplacePushEquivalence axiom, rename the axiom
 EmplacementInsertionEquivalence : requires InsertionContainer<C>
@@ -18237,156 +18237,156 @@
 Args... args) { emplace(c, position, args...) == insert(c,
 position, value_type(args...)); }
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 57
 </TD>
- <TD WIDTH=77>
- 23.1.6.3
+ <TD>
+ 23.1.6.3
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 1st
 paragraph, 4th
 line
- 
+ 
 
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 Typo, duplicated "to"
- 
+ 
 "to
 to model insertion
 container concepts."
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 Remove one.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 241
 </TD>
- <TD WIDTH=77>
- 23.2.1
+ <TD>
+ 23.2.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- std::array
+ <TD>
+ std::array
 does not have an allocator, so need to document an exception to
 the requirements of 23.1.1p3
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- add
+ <TD>
+ add
 exception to 23.1.1p3
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 242
 </TD>
- <TD WIDTH=77>
- 23.2.1
+ <TD>
+ 23.2.1
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- std::
+ <TD>
+ std::
 qualification no longer needed for reverse_iterator.
 </TD>
- <TD WIDTH=270>
- remove
+ <TD>
+ remove
 std:: qualification from std::reverse_iterator<iterator> and
 std::reverse_iterator<const_iterator>
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 243
 </TD>
- <TD WIDTH=77>
- 23.2.1
+ <TD>
+ 23.2.1
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Most
+ <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 WIDTH=270>
- add
+ <TD>
+ add
 the other two swaps.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 244
 </TD>
- <TD WIDTH=77>
- 23.2.1,
+ <TD>
+ 23.2.1,
 23.2.6
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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
@@ -18394,11 +18394,11 @@
 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 WIDTH=270>
- Define
+ <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>;
@@ -18406,27 +18406,27 @@
 Contiguous { C c; true = equal_ranges( data( c), data(c) +
 size(c), begin(c)); } };
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 245
 </TD>
- <TD WIDTH=77>
- 23.2.3
+ <TD>
+ 23.2.3
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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
@@ -18434,8 +18434,8 @@
 would simplify the library specification in general. See earlier
 comment for details, that would render this one redundant.
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 CopyConstructible requirement to the following signatures:
 template <Predicate<auto, T> Pred> requires
 CopyConstructible<Pred> void remove_if(Pred pred); template
@@ -18448,298 +18448,298 @@
 template <StrictWeakOrder<auto, T> Compare> requires
 CopyConstructible<Compare> void sort(Compare comp); 
 
- 
+ 
 
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 58
 </TD>
- <TD WIDTH=77>
- 23.2.3.2
+ <TD>
+ 23.2.3.2
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 1st
 line before 1st
 paragraph 
 
- 
+ 
 
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 Unnecessary "{"
 exists before a word iterator like "{iterator
 before_begin()".
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 Remove "{"
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 59
 </TD>
- <TD WIDTH=77>
- 23.2.4.4
+ <TD>
+ 23.2.4.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 83
 </TD>
- <TD WIDTH=77>
- 23.2.6.2
+ <TD>
+ 23.2.6.2
 </TD>
- <TD WIDTH=69>
- 7
+ <TD>
+ 7
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 "shrink_to_fint"
 should be "shrink_to_fit".
- 
+ 
 
 
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 246
 </TD>
- <TD WIDTH=77>
- 23.3.2.2
+ <TD>
+ 23.3.2.2
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Strike
+ <TD>
+ Strike
 23.3.2.2 entirely. (but do NOT strike these signatures from the
 class template definition!)
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 247
 </TD>
- <TD WIDTH=77>
- 24.1
+ <TD>
+ 24.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ge
+ <TD>
+ Ge
 </TD>
- <TD WIDTH=307>
- Iterator
+ <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 WIDTH=270>
- Move
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 248
 </TD>
- <TD WIDTH=77>
- 24.1
+ <TD>
+ 24.1
 </TD>
- <TD WIDTH=69>
- 6
+ <TD>
+ 6
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Replace
+ <TD>
+ Replace
 the reference to container with a more appropriate concept 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 250
 </TD>
- <TD WIDTH=77>
- 24.1.1
+ <TD>
+ 24.1.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- A
+ <TD>
+ A
 default implementation should be supplied for the post-increment
 operator to simplify implementation of iterators by users.
 </TD>
- <TD WIDTH=270>
- Copy
+ <TD>
+ Copy
 the Effects clause into the concept description as the default
 implementation. Assumes a default value for postincrement_result 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 251
 </TD>
- <TD WIDTH=77>
- 24.1.1
+ <TD>
+ 24.1.1
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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
@@ -18748,881 +18748,881 @@
 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 WIDTH=270>
- Move
+ <TD>
+ Move
 declaration of postincrement operator and postincrement_result
 type from Interator concept to the ForwardIterator concept
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 UK 252
- 
+ 
 
 </TD>
- <TD WIDTH=77>
- 24.1.2
+ <TD>
+ 24.1.2
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- istream_iterator
+ <TD>
+ istream_iterator
 is not a class, but a class template
 </TD>
- <TD WIDTH=270>
- Change
+ <TD>
+ Change
 'class' to 'class template' in the note. 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 253
 </TD>
- <TD WIDTH=77>
- 24.1.3
+ <TD>
+ 24.1.3
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- First
+ <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 WIDTH=270>
- Add
+ <TD>
+ Add
 the words 'if it' : "X satisfies the requirements of an
 output iterator IF IT meets the syntactic and semantic
 requirements" 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 254
 </TD>
- <TD WIDTH=77>
- 24.1.3
+ <TD>
+ 24.1.3
 </TD>
- <TD WIDTH=69>
- 5
+ <TD>
+ 5
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- This
+ <TD>
+ This
 postcondition for pre-increment operator should be written as an
 axiom
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Move
+ <TD>
+ Move
 the postcondition into the concept definition as an axiom 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 255
 </TD>
- <TD WIDTH=77>
- 24.1.4
+ <TD>
+ 24.1.4
 </TD>
- <TD WIDTH=69>
- 4
+ <TD>
+ 4
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- This
+ <TD>
+ This
 postcondition for pre-increment operator should be written as an
 axiom
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Move
+ <TD>
+ Move
 the postcondition into the concept definition as an axiom 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 256
 </TD>
- <TD WIDTH=77>
- 24.1.5
+ <TD>
+ 24.1.5
 </TD>
- <TD WIDTH=69>
- 3,
+ <TD>
+ 3,
 4, 5
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 relationship between pre- and post- decrement should be expressed
 as an axiom.
 </TD>
- <TD WIDTH=270>
- Move
+ <TD>
+ Move
 the text specification of pre/post-conditions and behaviour into
 an axiom within the BidirectionalIterator concept 
 
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 257
 </TD>
- <TD WIDTH=77>
- 24.1.5
+ <TD>
+ 24.1.5
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- There
+ <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 WIDTH=270>
- Add
+ <TD>
+ Add
 the default : typename postincrement_result = X; 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 258
 </TD>
- <TD WIDTH=77>
- 24.1.5
+ <TD>
+ 24.1.5
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- A
+ <TD>
+ A
 default implementation should be supplied for the post-decrement
 operator to simplify implementation of iterators by users.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Copy
+ <TD>
+ Copy
 the Effects clause into the concept description as the default
 implementation. Assumes a default value for postincrement_result 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 259
 </TD>
- <TD WIDTH=77>
- 24.1.5
+ <TD>
+ 24.1.5
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- postdecrement_result
+ <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 WIDTH=270>
- Add
+ <TD>
+ Add
 the requirement: requires Iterator< postdecrement_result >; 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 260
 </TD>
- <TD WIDTH=77>
- 24.1.5
+ <TD>
+ 24.1.5
 </TD>
- <TD WIDTH=69>
- 6
+ <TD>
+ 6
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Move
+ <TD>
+ Move
 the Effects clause into the BidirectionalIterator concept
 definition as an axiom, and as the default implementation for the
 operation.
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 249
 </TD>
- <TD WIDTH=77>
- 24.1.6
+ <TD>
+ 24.1.6
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 semantic for operator+= should also be provided as a default
 implementation to simplify implementation of user-defined
 iterators
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Copy
+ <TD>
+ Copy
 the text from the effects clause into the RandomAccessIterator
 concept as the default implementaiton.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 261
 </TD>
- <TD WIDTH=77>
- 24.1.6
+ <TD>
+ 24.1.6
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- To
+ <TD>
+ To
 simplify user defined random access iterator types, the
 subscript_reference type should default to reference
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- typename
+ <TD>
+ typename
 subscript_reference = reference; 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 262
 </TD>
- <TD WIDTH=77>
- 24.1.6
+ <TD>
+ 24.1.6
 </TD>
- <TD WIDTH=69>
- 3,
+ <TD>
+ 3,
 4
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Effects
+ <TD>
+ Effects
 and post-conditions for operator+ are more useful if expressed as
 axioms, and supplied as default implementations.
 </TD>
- <TD WIDTH=270>
- Move
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 263
 </TD>
- <TD WIDTH=77>
- 24.1.6
+ <TD>
+ 24.1.6
 </TD>
- <TD WIDTH=69>
- 5
+ <TD>
+ 5
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- This
+ <TD>
+ This
 requirement on operator-= would be better expressed as a default
 implementation in the concept, with a matching axiom
 </TD>
- <TD WIDTH=270>
- Move
+ <TD>
+ Move
 the specification for operator-= from the returns clause into an
 axiom and default implementation within the RandomAccessIterator
 concept
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 264
 </TD>
- <TD WIDTH=77>
- 24.1.6
+ <TD>
+ 24.1.6
 </TD>
- <TD WIDTH=69>
- 6
+ <TD>
+ 6
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Effects
+ <TD>
+ Effects
 clauses are better expressed as axioms where possible.
 </TD>
- <TD WIDTH=270>
- Move
+ <TD>
+ Move
 code in operator- effects clause into RandomAccessIterator concept
 as both a default implementation and an axiom
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 265
 </TD>
- <TD WIDTH=77>
- 24.1.6
+ <TD>
+ 24.1.6
 </TD>
- <TD WIDTH=69>
- 8
+ <TD>
+ 8
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- This
+ <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 WIDTH=270>
- Strike
+ <TD>
+ Strike
 the Effects clause
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 266
 </TD>
- <TD WIDTH=77>
- 24.1.6
+ <TD>
+ 24.1.6
 </TD>
- <TD WIDTH=69>
- 9
+ <TD>
+ 9
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- This
+ <TD>
+ This
 sentance should be provided as a default definition, along with a
 matching axiom
 </TD>
- <TD WIDTH=270>
- Move
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 267
 </TD>
- <TD WIDTH=77>
- 24.1.6
+ <TD>
+ 24.1.6
 </TD>
- <TD WIDTH=69>
- 24.1.6
+ <TD>
+ 24.1.6
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 code in the Requires clause for RandomAccessIterator operator[]
 would be better expressed as an axiom.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Rewrite
+ <TD>
+ Rewrite
 the Requires clause as an axiom in the RandomAccessIterator
 concept
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 268
 </TD>
- <TD WIDTH=77>
- 24.1.6
+ <TD>
+ 24.1.6
 </TD>
- <TD WIDTH=69>
- 12
+ <TD>
+ 12
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- This
+ <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 WIDTH=270>
- Clean
+ <TD>
+ Clean
 up the note to either avoid using language extension, or spell out
 this is a constraint to support extensions.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 60
 </TD>
- <TD WIDTH=77>
- 24.1.8
+ <TD>
+ 24.1.8
 </TD>
- <TD WIDTH=69>
- 1st
+ <TD>
+ 1st
 paragraph
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <TD>
+ 
 Add InputRange, OutputRange,
 ForwardRange, BidirectionalRange and RandomAccessRange.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 269
 </TD>
- <TD WIDTH=77>
- 24.3
+ <TD>
+ 24.3
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- 'decrements
+ <TD>
+ 'decrements
 for negative n' seems to imply a negative number of decrement
 operations, which is odd.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Need
+ <TD>
+ Need
 simple, clearer wording
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 270
 </TD>
- <TD WIDTH=77>
- 24.3
+ <TD>
+ 24.3
 </TD>
- <TD WIDTH=69>
- 4
+ <TD>
+ 4
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 reachability constraint in p5 means that a negavite result,
 implying decrements operations in p4, is not possible
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Split
+ <TD>
+ Split
 the two overloads into separate descriptions, where reachability
 is permitted to be in either direction for RandomAccessIterator
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 271
 </TD>
- <TD WIDTH=77>
- 24.3
+ <TD>
+ 24.3
 </TD>
- <TD WIDTH=69>
- 6,7
+ <TD>
+ 6,7
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- next/prev
+ <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 WIDTH=270>
- Replace
+ <TD>
+ Replace
 InputIterator constraint with FOrwardIterator in next and prev
 function templates.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 272
 </TD>
- <TD WIDTH=77>
- 24.4
+ <TD>
+ 24.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- reverse_iterator
+ <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
@@ -19636,37 +19636,37 @@
 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 WIDTH=270>
- Rephrase
+ <TD>
+ Rephrase
 the reverse_iterator comparison operations using only operators <
 and ==, as per the move_iterator specification.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 274
 </TD>
- <TD WIDTH=77>
- 24.4,
+ <TD>
+ 24.4,
 24.5
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <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
@@ -19674,104 +19674,104 @@
 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 WIDTH=270>
- Promote
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 275
 </TD>
- <TD WIDTH=77>
- 24.4.1.1
+ <TD>
+ 24.4.1.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- The
+ <TD>
+ The
 reverse_iterator template constructor taking a single Iterator
 argument should be explicit.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 276
 </TD>
- <TD WIDTH=77>
- 24.4.1.1
+ <TD>
+ 24.4.1.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- It
+ <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 WIDTH=270>
- Make
+ <TD>
+ Make
 the member operators taking a difference_type argument non-member
 operators
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 277
 </TD>
- <TD WIDTH=77>
- 24.4.1.2.1
+ <TD>
+ 24.4.1.2.1
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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
@@ -19779,11 +19779,11 @@
 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 WIDTH=270>
- i/
+ <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
@@ -19791,516 +19791,516 @@
 emphasizing the singular nature of a value-initialized reserve
 iterator.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 278
 </TD>
- <TD WIDTH=77>
- 24.4.1.2.1
+ <TD>
+ 24.4.1.2.1
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- There
+ <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 WIDTH=270>
- Change
+ <TD>
+ Change
 the const reverse_iterator & parameter to
 pass-by-value
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 279
 </TD>
- <TD WIDTH=77>
- 24.4.1.2.12,
+ <TD>
+ 24.4.1.2.12,
 24.4.3.2.12
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Specify
+ <TD>
+ Specify
 the return type using either decltype or the Iter concept map
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 280
 </TD>
- <TD WIDTH=77>
- 24.4.1.2.4
+ <TD>
+ 24.4.1.2.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Add
+ <TD>
+ Add
 reverse_iterator expsoition only member tmp as a comment to class
 declaration, as a private member
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 281
 </TD>
- <TD WIDTH=77>
- 24.4.1.2.5
+ <TD>
+ 24.4.1.2.5
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Replace
+ <TD>
+ Replace
 the existing returns specification with a copy of the operator*
 specification that returns this->tmp.operator->
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 282
 </TD>
- <TD WIDTH=77>
- 24.4.2.1,
+ <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 WIDTH=69>
- n/a
+ <TD>
+ n/a
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Insert
+ <TD>
+ Insert
 iterators of move-only types will move from lvalues
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 an additional constrained overload for operator= that requires
 !CopyConstructible<Cont::value_type> and mark it =delete.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 283
 </TD>
- <TD WIDTH=77>
- 24.4.2.5,
+ <TD>
+ 24.4.2.5,
 24.4.2.6.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- postincrement
+ <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 WIDTH=270>
- change
+ <TD>
+ change
 operator++(int) overload to return by value, not reference.
 Affects both class summary and operator definition in p
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 61
 </TD>
- <TD WIDTH=77>
- 24.4.3.2.1
+ <TD>
+ 24.4.3.2.1
 </TD>
- <TD WIDTH=69>
- 2nd
+ <TD>
+ 2nd
 paragraph, 1st
 line
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 Typo.
- 
+ 
 "intializing"
 should be "initializing"
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 Add "i"
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 284
 </TD>
- <TD WIDTH=77>
- 24.5
+ <TD>
+ 24.5
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 stream iterators need constraining with concepts/requrires
 clauses.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Provide
+ <TD>
+ Provide
 constraints
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 285
 </TD>
- <TD WIDTH=77>
- 24.5.1
+ <TD>
+ 24.5.1
 </TD>
- <TD WIDTH=69>
- 1,2
+ <TD>
+ 1,2
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Much
+ <TD>
+ Much
 of the content of p1 and the whole of p2 is a redundant
 redefinition of InputIterator. It should be simplified
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Strike
+ <TD>
+ Strike
 p2. Simplify p1 and add a cross-reference to the definition of
 InputIterator concept.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 286
 </TD>
- <TD WIDTH=77>
- 24.5.1
+ <TD>
+ 24.5.1
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- To
+ <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 WIDTH=270>
- Either
+ <TD>
+ Either
 provide a similar definition to the copy-assign operator as for
 the copy constructor, or strike the copy constructor
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 287
 </TD>
- <TD WIDTH=77>
- 24.5.1.1
+ <TD>
+ 24.5.1.1
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- It
+ <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 WIDTH=270>
- Specify
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 288
 </TD>
- <TD WIDTH=77>
- 24.5.1.1
+ <TD>
+ 24.5.1.1
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 provided specification is vacuous, offering no useful information.
 </TD>
- <TD WIDTH=270>
- Either
+ <TD>
+ Either
 strike the specification of the copy constructor, or simply
 replace it with an = default definition.
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 289
 </TD>
- <TD WIDTH=77>
- 24.5.1.2
+ <TD>
+ 24.5.1.2
 </TD>
- <TD WIDTH=69>
- 6
+ <TD>
+ 6
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- It
+ <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 WIDTH=270>
- Merge
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 290
 </TD>
- <TD WIDTH=77>
- 24.5.2
+ <TD>
+ 24.5.2
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Replace
+ <TD>
+ Replace
 char * with const charT *
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 291
 </TD>
- <TD WIDTH=77>
- 24.5.2.2
+ <TD>
+ 24.5.2.2
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- ostream_iterator
+ <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 WIDTH=270>
- ostream_iterator
+ <TD>
+ ostream_iterator
 operator++(int);
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 34
 </TD>
- <TD WIDTH=77>
+ <TD>
 24.5.3
 [istreambuf.iterator]
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 ed
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 There
 are two public sections, and the content of the second one is
@@ -20308,67 +20308,67 @@
 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 292
 </TD>
- <TD WIDTH=77>
- 24.5.3
+ <TD>
+ 24.5.3
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Prefer
+ <TD>
+ Prefer
 the use of the new nullptr constant to the zero literal when using
 a null pointer in text.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Change
+ <TD>
+ Change
 istreambuf_iterator(0) to istreambuf_iterator(nullptr)
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 293
 </TD>
- <TD WIDTH=77>
- 24.5.3
+ <TD>
+ 24.5.3
 </TD>
- <TD WIDTH=69>
- 2,3,4
+ <TD>
+ 2,3,4
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- 2.
+ <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
@@ -20378,35 +20378,35 @@
 one-pass algorithms. It is not possible to assign a character via
 an input iterator. 
 
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 294
 </TD>
- <TD WIDTH=77>
- 24.5.3.2
+ <TD>
+ 24.5.3.2
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Implicit
+ <TD>
+ Implicit
 converting constructors can be invoked at surprising times, so
 there should always be a good reason for declaring one.
 </TD>
- <TD WIDTH=270>
- Mark
+ <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>&
@@ -20414,232 +20414,232 @@
 istreambuf_iterator(basic_streambuf<charT,traits>* s)
 throw(); 
 
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 295
 </TD>
- <TD WIDTH=77>
- 25
+ <TD>
+ 25
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- THere
+ <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 WIDTH=270>
- Adopt
+ <TD>
+ Adopt
 n2743, or an update of that paper.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 62
 </TD>
- <TD WIDTH=77>
- 25,
+ <TD>
+ 25,
 25.3.1.5, 26.3.6.5
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <TD>
+ 
 Change "is_sorted_until"
 to "sorted_bound"
- 
+ 
 Change "is_heap"
 to "heap_bound"
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 296
 </TD>
- <TD WIDTH=77>
- 25.1.8
+ <TD>
+ 25.1.8
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 'Returns' of adjacent_find requires only HasEqualTo, or a
 Predicate. Requiring EqualityComparable or EquivalenceRelation
 seems too strong and not useful.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Change
+ <TD>
+ Change
 EqualityComparable to HasEqualTo and EquivalnceRelation to
 Predicate
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 297
 </TD>
- <TD WIDTH=77>
- 25.2.11
+ <TD>
+ 25.2.11
 </TD>
- <TD WIDTH=69>
- 6
+ <TD>
+ 6
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 definition of rotate_copy is very complicated. It is equivalent
 to: return copy(first, middle, copy(middle, last, result));
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Change
+ <TD>
+ Change
 'effects' to, returns, requires, complexity to: effects:
 equivalent to: return copy(first, middle, copy(middle, last,
 result));
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 298
 </TD>
- <TD WIDTH=77>
- 25.2.13
+ <TD>
+ 25.2.13
 </TD>
- <TD WIDTH=69>
- 13
+ <TD>
+ 13
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- partition_point
+ <TD>
+ partition_point
 requires a partitioned array
 </TD>
- <TD WIDTH=270>
- requires:
+ <TD>
+ requires:
 is_partitioned(first, last, pred) != false;
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 299
 </TD>
- <TD WIDTH=77>
- 25.2.2
+ <TD>
+ 25.2.2
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Should
+ <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 WIDTH=270>
- Change
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 300
 </TD>
- <TD WIDTH=77>
- 25.2.3
+ <TD>
+ 25.2.3
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Since
+ <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
@@ -20650,227 +20650,227 @@
 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 WIDTH=270>
- Move
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 301
 </TD>
- <TD WIDTH=77>
- 25.2.5
+ <TD>
+ 25.2.5
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- replace
+ <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 WIDTH=270>
- Remove
+ <TD>
+ Remove
 OutputIterator<Iter, Iter::reference> from replace and
 replace_if
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 302
 </TD>
- <TD WIDTH=77>
- 25.3
+ <TD>
+ 25.3
 </TD>
- <TD WIDTH=69>
- 4
+ <TD>
+ 4
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- the
+ <TD>
+ the
 concept StrictWeakOrder covers the definition of a strict weak
 ordering, described in paragraph 4.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Remove
+ <TD>
+ Remove
 4, and mention StrictWeakOrder in paragraph 1.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 303
 </TD>
- <TD WIDTH=77>
- 25.3
+ <TD>
+ 25.3
 </TD>
- <TD WIDTH=69>
- 6
+ <TD>
+ 6
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- This
+ <TD>
+ This
 paragraph just describes is_partitioned
 </TD>
- <TD WIDTH=270>
- 6
+ <TD>
+ 6
 A sequence [start,finish) is partitioned with respect to an
 expression f(e) if is_partitioned(start, finish, e) != false
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 304
 </TD>
- <TD WIDTH=77>
- 25.3.6
+ <TD>
+ 25.3.6
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 requires clauses of push_heap, pop_heap and make_heap are
 inconsistently formatted, dispite being identical
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Format
+ <TD>
+ Format
 them identically.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 305
 </TD>
- <TD WIDTH=77>
- 25.3.7
+ <TD>
+ 25.3.7
 </TD>
- <TD WIDTH=69>
- 1,
+ <TD>
+ 1,
 9, 17
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Strike
+ <TD>
+ Strike
 the !IsSameType<T, Compare> constraint on min/max/minmax
 algorithms
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 84
 </TD>
- <TD WIDTH=77>
- 26
+ <TD>
+ 26
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- ge
+ <TD>
+ ge
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 Parts of the numerics chapter
 are not concept enabled.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 35
 </TD>
- <TD WIDTH=77>
+ <TD>
 26.3
 [Complex numbers]
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 te
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 Instantiations
 of the class template complex<> have to be allowed for
@@ -20879,317 +20879,317 @@
 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 306
 </TD>
- <TD WIDTH=77>
- 26.4
+ <TD>
+ 26.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Random
+ <TD>
+ Random
 number library component cannot be used in constrained templates
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Provide
+ <TD>
+ Provide
 constraints for the random number library 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 63
 </TD>
- <TD WIDTH=77>
- 26.4.8.5.1
+ <TD>
+ 26.4.8.5.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <TD>
+ 
 Add the following constructer.
- 
+ 
 discrete_distribution(initializer_list<result_type>);
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 64
 </TD>
- <TD WIDTH=77>
- 26.5.2
+ <TD>
+ 26.5.2
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 “valarray<T>&
 operator+= (initializer_list<T>);” is not defined.
- 
+ 
 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 Add valarray<T>&
 operator+= (initializer_list<T>);
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 307
 </TD>
- <TD WIDTH=77>
- 26.7
+ <TD>
+ 26.7
 </TD>
- <TD WIDTH=69>
- Footnote
+ <TD>
+ Footnote
 288
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Drop
+ <TD>
+ Drop
 the reference to TR1.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 85
 </TD>
- <TD WIDTH=77>
- 27
+ <TD>
+ 27
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- ge
+ <TD>
+ ge
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 The input/output chapter is
 not concept enabled.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 308
 </TD>
- <TD WIDTH=77>
- 27
+ <TD>
+ 27
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 iostreams
 library cannot be used from constrained templates
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Provide
+ <TD>
+ Provide
 constraints for the iostreams library, clause 27 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 65
 </TD>
- <TD WIDTH=77>
- 27.4.4
+ <TD>
+ 27.4.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 Switch from
 “unspecified-bool-type” to　“explicit
 operator bool() const”.
- 
+ 
 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 Replace
 "operator unspecified-bool-type()
 const;" with "explicit operator bool() const;"
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 66
 </TD>
- <TD WIDTH=77>
- 27.4.4.3
+ <TD>
+ 27.4.4.3
 </TD>
- <TD WIDTH=69>
- 1st
+ <TD>
+ 1st
 paragraph
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 Switch from
 “unspecified-bool-type” to　“explicit
 operator bool() const”
- 
+ 
 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 Replace
 "operator unspecified-bool-type()
 const;" with "explicit operator bool() const;"
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 36
 </TD>
- <TD WIDTH=77>
+ <TD>
 
 27.6.1.2.2
 [istream.formatted.arithmetic]
 </TD>
- <TD WIDTH=69>
- 1,
+ <TD>
+ 1,
 2, and 3
 </TD>
- <TD WIDTH=33>
+ <TD>
 ed
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 iostate
 err = 0;
@@ -21204,31 +21204,31 @@
 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 37
 </TD>
- <TD WIDTH=77>
+ <TD>
 27.6.1.2.2
 [istream.formatted.arithmetic]
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
+ <TD>
 ed
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 else
 if (lval < numeric_limits<int>::min()
@@ -21243,1036 +21243,1036 @@
 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 67
 </TD>
- <TD WIDTH=77>
- 27.7.1
+ <TD>
+ 27.7.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 basic_stringbuf dose not use
 concept.
 </TD>
- <TD WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 68
 </TD>
- <TD WIDTH=77>
- 27.7.2
+ <TD>
+ 27.7.2
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 basic_istringstream dose not
 use concept.
 </TD>
- <TD WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 69
 </TD>
- <TD WIDTH=77>
- 27.7.3
+ <TD>
+ 27.7.3
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 basic_ostringstream dose not
 use concept.
 </TD>
- <TD WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 71
 </TD>
- <TD WIDTH=77>
- 27.7.3
+ <TD>
+ 27.7.3
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 Typo.
- "template"
+ "template"
 is missing in "class basic_ostringstream" of the title
 of the chapter.
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 Correct as follows.
- 
+ 
 27.7.3 Class
 basic_ostringstream
- 
+ 
 
 
- 
+ 
 should be
- 
+ 
 
 
- 27.7.3
+ 27.7.3
 Class template
 basic_ostringstream
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 72
 </TD>
- <TD WIDTH=77>
- 27.7.4
+ <TD>
+ 27.7.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 basic_stringstream dose not
 use concept.
 </TD>
- <TD WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 73
 </TD>
- <TD WIDTH=77>
- 27.8.1.14
+ <TD>
+ 27.8.1.14
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <TD>
+ 
 Add interface corresponding to
 wchar_t, char16_t and char32_t.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 86
 </TD>
- <TD WIDTH=77>
- 28
+ <TD>
+ 28
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- ge
+ <TD>
+ ge
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 The regular expressions
 chapter is not concept enabled.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 309
 </TD>
- <TD WIDTH=77>
- 28
+ <TD>
+ 28
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Regular
+ <TD>
+ Regular
 expressions cannot be used in constrained templates
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Provide
+ <TD>
+ Provide
 constraints for the regular expression library, clause 28 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 310
 </TD>
- <TD WIDTH=77>
- 28
+ <TD>
+ 28
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 regex chapter uses iterators in the old pre-concept style, it
 should be changed to use concepts instead.
 </TD>
- <TD WIDTH=270>
- Use
+ <TD>
+ Use
 concepts for iterator template arguments throughout.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 314
 </TD>
- <TD WIDTH=77>
- 28.4
+ <TD>
+ 28.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Add
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 315
 </TD>
- <TD WIDTH=77>
- 28.4
+ <TD>
+ 28.4
 </TD>
- <TD WIDTH=69>
- p6
+ <TD>
+ p6
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- 6
+ <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 WIDTH=270>
- Reword
+ <TD>
+ Reword
 to effect clause to use legal iterator dereferences 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 316
 </TD>
- <TD WIDTH=77>
- 28.4
+ <TD>
+ 28.4
 ff
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 constructors for regex classes do not have an r-value overload.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 the missing r-value constructors to regex classes.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 317
 </TD>
- <TD WIDTH=77>
- 28.8
+ <TD>
+ 28.8
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- basic_string
+ <TD>
+ basic_string
 has both a constructor and an assignment operator that accepts an
 initializer list, basic_regex should have the same.
 </TD>
- <TD WIDTH=270>
- In
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 74
 </TD>
- <TD WIDTH=77>
- 28.8
+ <TD>
+ 28.8
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 “basic_regx &
 operator= (initializer_list<T>);” is not defined.
- 
+ 
 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 Add basic_regx & operator=
 (initializer_list<T>);
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 318
 </TD>
- <TD WIDTH=77>
- 28.8.2
+ <TD>
+ 28.8.2
 </TD>
- <TD WIDTH=69>
- para
+ <TD>
+ para
 22
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Constructor
+ <TD>
+ Constructor
 definition should appear with the other constructors not after
 assignment ops.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Move
+ <TD>
+ Move
 para 22 to just after para 17.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 319
 </TD>
- <TD WIDTH=77>
- 28.12.2
+ <TD>
+ 28.12.2
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- It
+ <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
@@ -22284,8 +22284,8 @@
 initializer_lists we should use them to remove this particular
 wart.
 </TD>
- <TD WIDTH=270>
- To
+ <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
@@ -22304,101 +22304,101 @@
 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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 87
 </TD>
- <TD WIDTH=77>
- 29
+ <TD>
+ 29
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- ge
+ <TD>
+ ge
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 The atomics chapter is not
 concept enabled. The adopted paper, N2427, did have those
 concepts.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 311
 </TD>
- <TD WIDTH=77>
- 29
+ <TD>
+ 29
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Atomic
+ <TD>
+ Atomic
 types cannot be used generically in a constrained template
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Provide
+ <TD>
+ Provide
 constraints for the atomics library, clause 29 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 312
 </TD>
- <TD WIDTH=77>
- 29
+ <TD>
+ 29
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Remove
+ <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
@@ -22406,576 +22406,576 @@
 atomic operations to C we can add corresponding headers to table
 14 with a TR.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 75
 </TD>
- <TD WIDTH=77>
- 29
+ <TD>
+ 29
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 A definition of enum or struct
 is the style of C using typedef.
 </TD>
- <TD WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 313
 </TD>
- <TD WIDTH=77>
- 29.1
+ <TD>
+ 29.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- seq_cst
+ <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 WIDTH=270>
- Add
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 88
 </TD>
- <TD WIDTH=77>
- 29.2
+ <TD>
+ 29.2
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 "lockfree" facilities do not tell the programmer enough.
 </TD>
- <TD WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 89
 </TD>
- <TD WIDTH=77>
- 29.3.1
+ <TD>
+ 29.3.1
 </TD>
- <TD WIDTH=69>
- Table
+ <TD>
+ Table
 122
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- Change
+ <TD>
+ Change
 the classes to typedefs.
 </TD>
- <TD WIDTH=157>
- Google
+ <TD>
+ Google
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 90
 </TD>
- <TD WIDTH=77>
- 29.4
+ <TD>
+ 29.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- Are
+ <TD>
+ Are
 atomic functions allowed to have non-volatile overloads?
 </TD>
- <TD WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 91
 </TD>
- <TD WIDTH=77>
- 29.4
+ <TD>
+ 29.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- Whether
+ <TD>
+ Whether
 or not a failed compare_exchange is a RMW operation (as used in
 1.10 [intro.multithread]) is unclear.
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 Make
 failing compare_exchange operations not
 be RMW. See the attached paper under "atomic RMW status of
 failed compare_exchange"
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 92
 </TD>
- <TD WIDTH=77>
- 29.4
+ <TD>
+ 29.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- The
+ <TD>
+ The
 effect of memory_order_consume with atomic RMW operations is
 unclear.
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 Follow the lead of fences
 [atomics.fences], and promote memory_order_consume to
 memory_order_acquire with RMW operations.
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 76
 </TD>
- <TD WIDTH=77>
- 30
+ <TD>
+ 30
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 A
 description for "Throws:
 Nothing." are
 not unified.
- 
+ 
 At
 the part without throw, "Throws:
 Nothing."
 should be described.
 </TD>
- <TD WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 93
 </TD>
- <TD WIDTH=77>
- 30
+ <TD>
+ 30
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- ge
+ <TD>
+ ge
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 The thread chapter is not
 concept enabled.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 UK 320
- 
+ 
 
 </TD>
- <TD WIDTH=77>
- 30
+ <TD>
+ 30
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Threads
+ <TD>
+ Threads
 library cannot be used in constrained templates
 </TD>
- <TD WIDTH=270>
- Provide
+ <TD>
+ Provide
 constraints for the threads library, clause 30 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 321
 </TD>
- <TD WIDTH=77>
- 30
+ <TD>
+ 30
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- Throughout
+ <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
@@ -22985,39 +22985,39 @@
 move, replacing Requires: clauses with Preconditions: clasues
 throught the library. See comment against clause 17 for more
 details.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Decument
+ <TD>
+ Decument
 Preconditions: paragraphs in 17.5.2.4, and use consistently
 through rest of the library.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 94
 </TD>
- <TD WIDTH=77>
- 30.1.2
+ <TD>
+ 30.1.2
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- The first
+ <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 WIDTH=270>
+ <TD>
 Rewrite
 para 1 as: “ Some functions described
 in this Clause are specified to throw exceptions of type
@@ -23026,39 +23026,39 @@
 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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 95
 </TD>
- <TD WIDTH=77>
- 30.1.3
+ <TD>
+ 30.1.3
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- “native_handle_type”
+ <TD>
+ “native_handle_type”
 is a typedef, not a class member.
 </TD>
- <TD WIDTH=270>
- 
+ <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
@@ -23067,95 +23067,95 @@
 use of this member or the corresponding type is inherently
 non-portable. —end
 note ]
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 96
 </TD>
- <TD WIDTH=77>
- 30.1.4
+ <TD>
+ 30.1.4
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- There is no
+ <TD>
+ There is no
 definition here for monotonic clock.
 </TD>
- <TD WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 322
 </TD>
- <TD WIDTH=77>
- 30.1.4
+ <TD>
+ 30.1.4
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Not
+ <TD>
+ Not
 all systms can provide a monotonic clock. How are they expected to
 treat a _for function?
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 at least a note explaining the intent for systems that do not
 support a monotonic clock.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 323
 </TD>
- <TD WIDTH=77>
- 30.2.1
+ <TD>
+ 30.2.1
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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
@@ -23164,245 +23164,245 @@
 constructor is redundant; the variadic constructor can provide
 identical functionality with one *fewer* copies if the supplied
 func is an lvalue.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Mark
+ <TD>
+ Mark
 constructor template <class F, class ...Args> thread(F&&
 f, Args&&... args); as explicit and remove the
 single-argument constructor.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 324
 </TD>
- <TD WIDTH=77>
- 30.2.1.1
+ <TD>
+ 30.2.1.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- thread::id
+ <TD>
+ thread::id
 objects should be as useable in hashing containers as they are in
 ordered associative containers.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 thread::id support for std::hash
- 
+ 
 
- 
+ 
 
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 77
 </TD>
- <TD WIDTH=77>
- 30.2.1.2
+ <TD>
+ 30.2.1.2
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <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 WIDTH=270>
- 
+ <TD>
+ 
 Add a concept for constructor
 of thread.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 78
 </TD>
- <TD WIDTH=77>
- 30.2.1.2
+ <TD>
+ 30.2.1.2
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 4th
 paragraph, 1st
 line
- 
+ 
 
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 In "F and each Ti in
 Args", 'Ti' is not clear.
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 Replace "Ti" with
 "args"
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 97
 </TD>
- <TD WIDTH=77>
- 30.2.1.3
+ <TD>
+ 30.2.1.3
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- detach-on-destruction
+ <TD>
+ detach-on-destruction
 may result in “escaped” threads accessing objects with
 bounded lifetime after the end of their lifetime.
 </TD>
- <TD WIDTH=270>
- See
+ <TD>
+ See
 document WG21 N2802=08-0312 written by Hans Boehm.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- US
+ <TD>
+ US
 98
 </TD>
- <TD WIDTH=77>
- 30.2.1.3,
+ <TD>
+ 30.2.1.3,
 30.2.1.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 325
 </TD>
- <TD WIDTH=77>
- 30.3.3
+ <TD>
+ 30.3.3
 </TD>
- <TD WIDTH=69>
- 2
+ <TD>
+ 2
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- We
+ <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 WIDTH=270>
- Replace
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 326
 </TD>
- <TD WIDTH=77>
- 30.3.3.2.1
+ <TD>
+ 30.3.3.2.1
 </TD>
- <TD WIDTH=69>
- 7
+ <TD>
+ 7
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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
@@ -23411,35 +23411,35 @@
 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 WIDTH=270>
- Strike
+ <TD>
+ Strike
 30.3.3.2.1p7
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 327
 </TD>
- <TD WIDTH=77>
- 30.3.3.2.2
+ <TD>
+ 30.3.3.2.2
 </TD>
- <TD WIDTH=69>
- 4,
+ <TD>
+ 4,
 9, 14, 19
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Not
+ <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
@@ -23452,75 +23452,75 @@
 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 WIDTH=270>
- Add
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 328
 </TD>
- <TD WIDTH=77>
- 30.3.3.2.2
+ <TD>
+ 30.3.3.2.2
 </TD>
- <TD WIDTH=69>
- 20
+ <TD>
+ 20
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- There
+ <TD>
+ There
 is a missing precondition that owns is true, or an if(owns) test
 is missing from the effect clause
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 a precondition that owns == true. Add an error condition to detect
 a violation, rather than yield undefined behaviour.
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 329
 </TD>
- <TD WIDTH=77>
- 30.5
+ <TD>
+ 30.5
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- future,
+ <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 WIDTH=270>
- Provide
+ <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
@@ -23537,255 +23537,255 @@
 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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 330
 </TD>
- <TD WIDTH=77>
- 30.5.1
+ <TD>
+ 30.5.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- 30.5.1
+ <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 WIDTH=270>
- Remove
+ <TD>
+ Remove
 the reference to constructible_with_allocator_prefix in 30.5.1
 Remove paragraph 30.5.7
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 79
 </TD>
- <TD WIDTH=77>
- 30.5.1
+ <TD>
+ 30.5.1
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 The concept of UsesAllocator
 and Allocator should be used.
 </TD>
- <TD WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 331
 </TD>
- <TD WIDTH=77>
- 30.5.3
+ <TD>
+ 30.5.3
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Not
+ <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 WIDTH=270>
- Declare
+ <TD>
+ Declare
 the constructor as private with a note about intended friendship,
 or remove the exposition-only comment and document the semantics.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 332
 </TD>
- <TD WIDTH=77>
- 30.5.4
+ <TD>
+ 30.5.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ed
+ <TD>
+ Ed
 </TD>
- <TD WIDTH=307>
- It
+ <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 WIDTH=270>
- Provide
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 333
 </TD>
- <TD WIDTH=77>
- 30.5.4
+ <TD>
+ 30.5.4
 </TD>
- <TD WIDTH=69>
- 5
+ <TD>
+ 5
 </TD>
- <TD WIDTH=33>
- Ge
+ <TD>
+ Ge
 </TD>
- <TD WIDTH=307>
- We
+ <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 WIDTH=270>
- Requires
+ <TD>
+ Requires
 fully baked concepts for clause 30
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 334
 </TD>
- <TD WIDTH=77>
- 30.5.4
+ <TD>
+ 30.5.4
 </TD>
- <TD WIDTH=69>
- 5
+ <TD>
+ 5
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Behaviour
+ <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 WIDTH=270>
- Effects:
+ <TD>
+ Effects:
 If is_ready() would return false, block on the asynchronous result
 associated with *this. 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 335
 </TD>
- <TD WIDTH=77>
- 30.5.4
+ <TD>
+ 30.5.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- std::unique_future
+ <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
@@ -23794,39 +23794,39 @@
 uf(p.get_future()); std::unique_future<int>
 uf2(std::move(uf)); uf.wait(); // oops, uf has no result to wait
 for.
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Add
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 336
 </TD>
- <TD WIDTH=77>
- 30.5.4
+ <TD>
+ 30.5.4
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- It
+ <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
@@ -23835,103 +23835,103 @@
 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 WIDTH=270>
- Add
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 80
 </TD>
- <TD WIDTH=77>
- 30.5.4
+ <TD>
+ 30.5.4
 , 30.5.5
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 Typo, duplicated ">"
- 
+ 
 "class Period>>"
- 
+ 
 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 Remove one
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 337
 </TD>
- <TD WIDTH=77>
- 30.5.5
+ <TD>
+ 30.5.5
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- shared_future
+ <TD>
+ shared_future
 should support an efficient move constructor that can avoid
 unnecessary manipulation of a reference count, much like
 shared_ptr
- 
+ 
 
 </TD>
- <TD WIDTH=270>
- Add
+ <TD>
+ Add
 a move constructor
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 338
 </TD>
- <TD WIDTH=77>
- 30.5.5
+ <TD>
+ 30.5.5
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- shared_future
+ <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
@@ -23942,8 +23942,8 @@
 can be retained by declaring such an instance as "const
 shared_future".
 </TD>
- <TD WIDTH=270>
- Remove
+ <TD>
+ Remove
 "=delete" from the copy-assignment operator of
 shared_future. Add a move-constructor
 shared_future(shared_future&& rhs), and a move-assignment
@@ -23953,372 +23953,372 @@
 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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 339
 </TD>
- <TD WIDTH=77>
- 30.5.6
+ <TD>
+ 30.5.6
 </TD>
- <TD WIDTH=69>
- 6,
+ <TD>
+ 6,
 7
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- Move
+ <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 WIDTH=270>
- Strike
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 340
 </TD>
- <TD WIDTH=77>
- 30.5.6
+ <TD>
+ 30.5.6
 </TD>
- <TD WIDTH=69>
- 11,
+ <TD>
+ 11,
 12, 13
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- There
+ <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 WIDTH=270>
- Postcondition:
+ <TD>
+ Postcondition:
 *this has no associated state.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 341
 </TD>
- <TD WIDTH=77>
- 30.5.6
+ <TD>
+ 30.5.6
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- promise::swap
+ <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 WIDTH=270>
- Change
+ <TD>
+ Change
 promise::swap to take an rvalue reference.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 342
 </TD>
- <TD WIDTH=77>
- 30.5.6
+ <TD>
+ 30.5.6
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- std::promise
+ <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 WIDTH=270>
- Add
+ <TD>
+ Add
 a non-member overload void swap(promise&& x,promise&&
 y){ x.swap(y); }
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 343
 </TD>
- <TD WIDTH=77>
- 30.5.6
+ <TD>
+ 30.5.6
 </TD>
- <TD WIDTH=69>
- 3
+ <TD>
+ 3
 </TD>
- <TD WIDTH=33>
- Te
+ <TD>
+ Te
 </TD>
- <TD WIDTH=307>
- The
+ <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 WIDTH=270>
- Remove
+ <TD>
+ Remove
 the constructor with the signature template <class Allocator>
 promise(allocator_arg_t, const Allocator& a, promise&
 rhs);
- 
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- JP
+ <TD>
+ JP
 81
 </TD>
- <TD WIDTH=77>
- 30.5.8
+ <TD>
+ 30.5.8
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- ed
+ <TD>
+ ed
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 There are not requirements for
 F and a concept of Allocator dose not use.
 </TD>
- <TD WIDTH=270>
- 
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- DE-23
+ <TD>
+ DE-23
 </TD>
- <TD WIDTH=77>
- Annex
+ <TD>
+ Annex
 B
 </TD>
- <TD WIDTH=69>
- p2
+ <TD>
+ p2
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
+ <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 WIDTH=270>
- In
+ <TD>
+ In
 Annex B, specify a recursion depth of 256 or a larger value.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- DE-24
+ <TD>
+ DE-24
 </TD>
- <TD WIDTH=77>
- Annex
+ <TD>
+ Annex
 B
 </TD>
- <TD WIDTH=69>
- p2
+ <TD>
+ p2
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
+ <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 WIDTH=270>
- Add
+ <TD>
+ Add
 a miminum of 10 placeholders to Annex B.
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- DE-25
+ <TD>
+ DE-25
 </TD>
- <TD WIDTH=77>
- Annex
+ <TD>
+ Annex
 B
 </TD>
- <TD WIDTH=69>
- p2
+ <TD>
+ p2
 </TD>
- <TD WIDTH=33>
- te
+ <TD>
+ te
 </TD>
- <TD WIDTH=307>
+ <TD>
 DE-25
 Specifying a minimum of 17 recursively nested template
 instantiations is too small for practical purposes. The limit is
@@ -24326,34 +24326,34 @@
 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 WIDTH=270>
- Remove
+ <TD>
+ Remove
 the bullet "Recursively nested template instantiations [17]".
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 38
 </TD>
- <TD WIDTH=77>
+ <TD>
 C.2
 [diffs.library]
 </TD>
- <TD WIDTH=69>
- 1
+ <TD>
+ 1
 </TD>
- <TD WIDTH=33>
+ <TD>
 ed
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 What
 is ISO/IEC 1990:9899/DAM 1? My guess is that's a typo for ISO/IEC
@@ -24366,70 +24366,70 @@
 
 
 </TD>
- <TD WIDTH=270>
+ <TD>
 
 One
 need probably a reference to the document which introduce char16_t
 and
- char32_t
+ char32_t
 in C (ISO/IEC TR 19769:2004?).
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- UK 
+ <TD>
+ UK 
 344
 </TD>
- <TD WIDTH=77>
- Appendix
+ <TD>
+ Appendix
 D
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- Ge
+ <TD>
+ Ge
 </TD>
- <TD WIDTH=307>
- It
+ <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 WIDTH=270>
- Add
+ <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 WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- FR
+ <TD>
+ FR
 39
 </TD>
- <TD WIDTH=77>
+ <TD>
 Index
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
+ <TD>
 ed
 </TD>
- <TD WIDTH=307>
+ <TD>
 
 Some
 definitions seem not indexed (such as /trivially copyable/ or
@@ -24442,70 +24442,45 @@
 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
 <TR VALIGN=TOP>
- <TD WIDTH=23>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=77>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=69>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=33>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=307>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=270>
- 
+ <TD>
+ 
 
 </TD>
- <TD WIDTH=157>
- 
+ <TD>
+ 
 
 </TD>
 </TR>
</TABLE>
-
- 
-
-<DIV TYPE=FOOTER>
- 
- 1 MB
- = Member body (enter the ISO 3166 two-letter country code, e.g. CN
- for China; comments from the ISO/CS editing unit are identified by
- **)
- 
- 2 Type
- of comment: ge
- = general te
- = technical ed
- = editorial 
- 
- 
- NOTE Columns
- 1, 2, 4, 5 are compulsory.
- page
- <SDFIELD TYPE=PAGE SUBTYPE=RANDOM FORMAT=PAGE>144</SDFIELD>
- of <SDFIELD TYPE=DOCSTAT SUBTYPE=PAGE FORMAT=ARABIC>144</SDFIELD>
- ISO
- electronic balloting commenting template/version 2001-10
-</DIV>
</BODY>
</HTML>
\ No newline at end of file

Next message: bdawes_at_[hidden]: "[Boost-commit] svn:boost r51561 - sandbox/committee/LWG"
Previous message: bdawes_at_[hidden]: "[Boost-commit] svn:boost r51559 - 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