Boost-Commit :

Date view	Thread view	Subject view	Author view

Subject: [Boost-commit] svn:boost r51559 - sandbox/committee/LWG
From: bdawes_at_[hidden]
Date: 2009-03-03 08:17:15

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

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

Log:
Edit 1
Text files modified:
sandbox/committee/LWG/0xCD1_Comments.html | 3051 ++++++++++++++++++++-------------------
1 files changed, 1546 insertions(+), 1505 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:17:14 EST (Tue, 03 Mar 2009)
@@ -2,8 +2,8 @@
<HTML>
<HEAD>
 <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=windows-1252">
- <TITLE>CommentsOn</TITLE>
- <META NAME="GENERATOR" CONTENT="OpenOffice.org 3.0 (Win32)">
+ <TITLE>C++0x CD1 NB Comments</TITLE>
+ <META NAME="GENERATOR" CONTENT="Microsoft FrontPage 5.0">
 <META NAME="AUTHOR" CONTENT="dow">
 <META NAME="CREATED" CONTENT="20090221;19590000">
 <META NAME="CHANGEDBY" CONTENT=" Barry E Hedquist">
@@ -22,35 +22,7 @@
</HEAD>
<BODY LANG="en-US" TEXT="#000000" DIR="LTR">
<DIV TYPE=HEADER>
- <TABLE WIDTH=1035 BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0>
- <COL WIDTH=564>
- <COL WIDTH=139>
- <COL WIDTH=288>
- <TR VALIGN=TOP>
- <TD WIDTH=564>
- C++0X,
- CD 1, NB Comments
- </TD>
- <TD WIDTH=139>
- Date:
- 21 Feb 2009
- </TD>
- <TD WIDTH=288>
- Document:
- SC22 N4411, ISO/IEC CD 14882
- </TD>
- </TR>
- </TABLE>
- 
- 
- <TABLE WIDTH=1036 BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0>
- <COL WIDTH=23>
- <COL WIDTH=77>
- <COL WIDTH=69>
- <COL WIDTH=33>
- <COL WIDTH=307>
- <COL WIDTH=270>
- <COL WIDTH=157>
+ <TABLE BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0 style="border-collapse: collapse">
 <TR VALIGN=TOP>
 <TD WIDTH=23>
 
@@ -89,14 +61,14 @@
 </TD>
 <TD WIDTH=77>
 
- Clause
- No./ Subclause No./ Annex (e.g.
- 3.1)
+ Clause
+ No./ Subclause No./ Annex (e.g.
+ 3.1)
 </TD>
 <TD WIDTH=69>
 
- Paragraph/ Figure/Table/Note (e.g.
- Table 1)
+ Paragraph/ Figure/Table/Note (e.g.
+ Table 1)
 </TD>
 <TD WIDTH=33>
 
@@ -120,21 +92,6 @@
 
 </TD>
 </TR>
- </TABLE>
- 
- 
- 
- 
- 
-</DIV>
-<TABLE WIDTH=1036 BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0 STYLE="page-break-before: always">
- <COL WIDTH=23>
- <COL WIDTH=77>
- <COL WIDTH=69>
- <COL WIDTH=33>
- <COL WIDTH=307>
- <COL WIDTH=270>
- <COL WIDTH=157>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
 FR
@@ -149,15 +106,17 @@
 
 </TD>
 <TD WIDTH=33>
- ge
+ ge
 </TD>
 <TD WIDTH=307>
- Interactions
+ 
+ Interactions
 between several new features appear obscure, and very few examples
 are offered to guide understanding of the formal text on
- interaction between these new additions.
- We
- worry about the complexity of the programming model so created.
+ interaction between these new additions.
+ 
+ We
+ worry about the complexity of the programming model so created.
 
 
 </TD>
@@ -172,8 +131,7 @@
 </TR>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
- US
- 1
+ US 1
 </TD>
 <TD WIDTH=77>
 1-16
@@ -194,7 +152,7 @@
 
 
 
- http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html
+ http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html
 
 
 </TD>
@@ -305,8 +263,7 @@
 </TR>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
- US
- 3
+ US 3
 </TD>
 <TD WIDTH=77>
 all
@@ -348,11 +305,11 @@
 2
 </TD>
 <TD WIDTH=33>
- ed
+ ed
 </TD>
 <TD WIDTH=307>
- C++
- is split at the end of line.
+ C++
+ is split at the end of line.
 </TD>
 <TD WIDTH=270>
 
@@ -365,8 +322,7 @@
 </TR>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
- US
- 4
+ US 4
 </TD>
 <TD WIDTH=77>
 1.1
@@ -390,18 +346,6 @@
 
 </TD>
 </TR>
-</TABLE>
-
- 
-
-<TABLE WIDTH=1036 BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0>
- <COL WIDTH=23>
- <COL WIDTH=77>
- <COL WIDTH=69>
- <COL WIDTH=33>
- <COL WIDTH=307>
- <COL WIDTH=270>
- <COL WIDTH=157>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
 UK
@@ -445,11 +389,11 @@
 1
 </TD>
 <TD WIDTH=33>
- ed
+ ed
 </TD>
 <TD WIDTH=307>
- Is
- the lack of reference to ISO/CEI 9899/AC3:2007 voluntary?
+ Is
+ the lack of reference to ISO/CEI 9899/AC3:2007 voluntary?
 </TD>
 <TD WIDTH=270>
 
@@ -476,10 +420,10 @@
 </TD>
 <TD WIDTH=307>
 
- We
+ 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.+
+ without comment.+
 
 
 </TD>
@@ -581,12 +525,12 @@
 
 </TD>
 <TD WIDTH=33>
- te
+ te
 </TD>
 <TD WIDTH=307>
- "The
+ "The
 dynamic type of an rvalue expression is its static type." Is
- this true with rvalue references?
+ this true with rvalue references?
 </TD>
 <TD WIDTH=270>
 
@@ -599,8 +543,7 @@
 </TR>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
- US
- 5
+ US 5
 </TD>
 <TD WIDTH=77>
 1.3.5
@@ -641,11 +584,11 @@
 
 </TD>
 <TD WIDTH=33>
- ed
+ ed
 </TD>
 <TD WIDTH=307>
- There
- is a page break between the title and the paragraph.
+ There
+ is a page break between the title and the paragraph.
 </TD>
 <TD WIDTH=270>
 
@@ -670,15 +613,15 @@
 
 </TD>
 <TD WIDTH=33>
- ed
+ ed
 </TD>
 <TD WIDTH=307>
- [intro.execution]/5
- explicitly allows non causal undefined behaviour,
+ [intro.execution]/5
+ explicitly allows non causal undefined behaviour,
 </TD>
 <TD WIDTH=270>
- Adding
- it to the note outlying possible undefined behaviours.
+ Adding
+ it to the note outlying possible undefined behaviours.
 </TD>
 <TD WIDTH=157>
 
@@ -687,8 +630,7 @@
 </TR>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
- US
- 6
+ US 6
 </TD>
 <TD WIDTH=77>
 1.3.14
@@ -733,14 +675,14 @@
 8
 </TD>
 <TD WIDTH=33>
- ed
+ ed
 </TD>
 <TD WIDTH=307>
- The
+ 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.
+ ODR.
 </TD>
 <TD WIDTH=270>
 
@@ -870,8 +812,7 @@
 </TR>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
- US
- 9
+ US 9
 </TD>
 <TD WIDTH=77>
 1.6
@@ -900,8 +841,7 @@
 </TR>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
- US
- 10
+ US 10
 </TD>
 <TD WIDTH=77>
 1.7
@@ -917,7 +857,8 @@
 term thread is used before defined.
 </TD>
 <TD WIDTH=270>
- Reference
+ 
+ Reference
 1.10 [intro.multithread].
 </TD>
 <TD WIDTH=157>
@@ -925,18 +866,6 @@
 
 </TD>
 </TR>
-</TABLE>
-
- 
-
-<TABLE WIDTH=1036 BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0>
- <COL WIDTH=23>
- <COL WIDTH=77>
- <COL WIDTH=69>
- <COL WIDTH=33>
- <COL WIDTH=307>
- <COL WIDTH=270>
- <COL WIDTH=157>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
 US
@@ -1183,18 +1112,6 @@
 
 </TD>
 </TR>
-</TABLE>
-
- 
-
-<TABLE WIDTH=1036 BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0>
- <COL WIDTH=23>
- <COL WIDTH=77>
- <COL WIDTH=69>
- <COL WIDTH=33>
- <COL WIDTH=307>
- <COL WIDTH=270>
- <COL WIDTH=157>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
 FR
@@ -1208,12 +1125,12 @@
 16
 </TD>
 <TD WIDTH=33>
- ed
+ ed
 </TD>
 <TD WIDTH=307>
- This
+ This
 example use int *v while the other examples seems to use notation
- like int* v.
+ like int* v.
 </TD>
 <TD WIDTH=270>
 
@@ -1249,19 +1166,17 @@
 Replace
 first sentence of para 1 as follows:
 
- Under
- a hosted implementation, a C++
- program can have more
- than one thread of
- execution (a.k.a.
- thread)
- running concurrently.
+ Under
+ a hosted implementation, a C++ program can have more
+ than one thread of
+ execution (a.k.a. thread)
+ running concurrently.
 Each thread is a single flow of control within a program.
 Anything whose address may be determined by a thread, including
 but not limited to static objects, storage obtained via new or by
 any dynamic allocator, directly addressable storage obtained
 through implementation-defined functions, and automatic variables,
- are accessible to all threads in the same program.
+ are accessible to all threads in the same program.
 
 
 
@@ -1342,18 +1257,6 @@
 
 </TD>
 </TR>
-</TABLE>
-
- 
-
-<TABLE WIDTH=1036 BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0>
- <COL WIDTH=23>
- <COL WIDTH=77>
- <COL WIDTH=69>
- <COL WIDTH=33>
- <COL WIDTH=307>
- <COL WIDTH=270>
- <COL WIDTH=157>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
 FR
@@ -1368,34 +1271,40 @@
 
 </TD>
 <TD WIDTH=33>
- te
+ te
 </TD>
 <TD WIDTH=307>
- [defns.multibyte]
- "the extended character set."
- [lex.charset]/3
+ 
+ [defns.multibyte]
+ "the extended character set."
+ 
+ [lex.charset]/3
 cited below implies that there is an extended character set per
- locale.
- [lex.phases]/5
+ locale.
+ 
+ [lex.phases]/5
 "Each [...] universal-character-name [...] is converted to
- the corresponding member of the execution character set"
- [lex.charset]/3
+ the corresponding member of the execution character set"
+ 
+ [lex.charset]/3
 "The values of the members of the execution character sets
 are implementation defined, and any additional members are
- locale-specific."
+ locale-specific."
 
 
- Together
+ 
+ Together
 they seem to imply that what is locale-specific is if a value is
 valid or not for the current locale, not the representation of a
- given universal character.
+ given universal character.
 
 
- This
+ 
+ This
 is not the behaviour of at least some compilers I've access to
 which are allowing different codes for the same abstract character
 in different locale. During phase 5, they are using an
- implementation defined char set.
+ implementation defined char set.
 
 
 
@@ -1522,11 +1431,11 @@
 3
 </TD>
 <TD WIDTH=33>
- ed
+ ed
 </TD>
 <TD WIDTH=307>
- There
- are spurious empty lines.
+ There
+ are spurious empty lines.
 </TD>
 <TD WIDTH=270>
 
@@ -1551,12 +1460,12 @@
 
 </TD>
 <TD WIDTH=33>
- te
+ te
 </TD>
 <TD WIDTH=307>
- The
+ The
 alternative representations are reserved as such even in
- attribute. Is that what is wanted?
+ attribute. Is that what is wanted?
 </TD>
 <TD WIDTH=270>
 
@@ -1841,9 +1750,8 @@
 ed
 </TD>
 <TD WIDTH=307>
- Typo,
- R"..." should
- be R"[...]"
+ Typo, R"..." should
+ be R"[...]"
 </TD>
 <TD WIDTH=270>
 Correct
@@ -1899,10 +1807,10 @@
 
 [Note:
 
- char
- foo[] = R”delimiter[[a-z]
+ char
+ foo[] = R”delimiter[[a-z]
 specifies a range which matches any lowercase letter from "a"
- to "z".]delimiter”;
+ to "z".]delimiter”;
 
 
 
@@ -1927,18 +1835,6 @@
 
 </TD>
 </TR>
-</TABLE>
-
- 
-
-<TABLE WIDTH=1036 BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0>
- <COL WIDTH=23>
- <COL WIDTH=77>
- <COL WIDTH=69>
- <COL WIDTH=33>
- <COL WIDTH=307>
- <COL WIDTH=270>
- <COL WIDTH=157>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
 JP
@@ -2092,13 +1988,14 @@
 3
 </TD>
 <TD WIDTH=33>
- ed
+ ed
 </TD>
 <TD WIDTH=307>
- Shouldn't
- the assert be
- assert(std::strcmp(p,
- "a\nb\nc") == 0);
+ 
+ Shouldn't
+ the assert be
+ assert(std::strcmp(p,
+ "a\nb\nc") == 0);
 </TD>
 <TD WIDTH=270>
 
@@ -2245,25 +2142,28 @@
 7
 </TD>
 <TD WIDTH=33>
- ed
+ ed
 </TD>
 <TD WIDTH=307>
- "In
+ "In
 general it is necessary to determine whether a name denotes one of
- these entities before parsing the program that contains it."
+ these entities before parsing the program that contains it."
 </TD>
 <TD WIDTH=270>
- Would
- prefer
- "...
- before continuing to parse the program that contains it."
+ 
+ Would
+ prefer
+ 
+ "...
+ before continuing to parse the program that contains it."
 or
 even 
 
- "...
- to complete the parsing of the program that contains it."
- as
- some names denotes entities declared after the first occurrence.
+ 
+ "...
+ to complete the parsing of the program that contains it."
+ as
+ some names denotes entities declared after the first occurrence.
 </TD>
 <TD WIDTH=157>
 
@@ -2283,13 +2183,14 @@
 8
 </TD>
 <TD WIDTH=33>
- ed
+ ed
 </TD>
 <TD WIDTH=307>
- /operator-function-id/,
+ 
+ /operator-function-id/,
 /conversion-function-id/, /template-id/ are followed by a space
 and then a "s" while usually such production names
- aren't followed by a space when put in plural (see /identifier/).
+ aren't followed by a space when put in plural (see /identifier/).
 
 
 </TD>
@@ -2585,12 +2486,13 @@
 
 </TD>
 <TD WIDTH=33>
- te
+ te
 </TD>
 <TD WIDTH=307>
- The
+ 
+ The
 scope of function parameters is defined, but what is the scope of
- template parameters?
+ template parameters?
 
 
 </TD>
@@ -2633,18 +2535,6 @@
 
 </TD>
 </TR>
-</TABLE>
-
- 
-
-<TABLE WIDTH=1036 BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0>
- <COL WIDTH=23>
- <COL WIDTH=77>
- <COL WIDTH=69>
- <COL WIDTH=33>
- <COL WIDTH=307>
- <COL WIDTH=270>
- <COL WIDTH=157>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
 
@@ -2694,15 +2584,17 @@
 
 </TD>
 <TD WIDTH=33>
- te
+ te
 </TD>
 <TD WIDTH=307>
- This
- section does not specify whether concept names have linkage.
- Do
+ 
+ This
+ section does not specify whether concept names have linkage.
+ 
+ Do
 they or not? If concept names do not have linkage, then a note is
 appropriate, and that would be a bit surprising and curious. What
- is the rationale?
+ is the rationale?
 
 
 </TD>
@@ -2818,11 +2710,11 @@
 6
 </TD>
 <TD WIDTH=33>
- ed
+ ed
 </TD>
 <TD WIDTH=307>
- The
- paragraph number is not aligned with the text.
+ The
+ paragraph number is not aligned with the text.
 </TD>
 <TD WIDTH=270>
 
@@ -2847,17 +2739,20 @@
 
 </TD>
 <TD WIDTH=33>
- te
+ te
 </TD>
 <TD WIDTH=307>
- This
+ 
+ This
 section completely ignores the real world and practical case of
 dynamically linked or loaded libraries. In current computing
- environments, they are ubiquitous and they cannot be ignored in
- practical
- C++ programs. The Standard
- should
- address this aspect.
+ environments, they are ubiquitous and they cannot be ignored in
+ 
+ practical
+ C++ programs. The Standard
+ 
+ should
+ address this aspect.
 
 
 </TD>
@@ -2870,18 +2765,6 @@
 
 </TD>
 </TR>
-</TABLE>
-
- 
-
-<TABLE WIDTH=1036 BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0>
- <COL WIDTH=23>
- <COL WIDTH=77>
- <COL WIDTH=69>
- <COL WIDTH=33>
- <COL WIDTH=307>
- <COL WIDTH=270>
- <COL WIDTH=157>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
 UK 
@@ -3035,18 +2918,6 @@
 
 </TD>
 </TR>
-</TABLE>
-
- 
-
-<TABLE WIDTH=1036 BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0>
- <COL WIDTH=23>
- <COL WIDTH=77>
- <COL WIDTH=69>
- <COL WIDTH=33>
- <COL WIDTH=307>
- <COL WIDTH=270>
- <COL WIDTH=157>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
 DE-3
@@ -3067,10 +2938,11 @@
 behavior; none of the bullets in the second paragraph seem to
 apply.
 
- int&
- i = *new int(5);
- delete
- &i;
+ int&
+ i = *new int(5);
+ 
+ delete
+ &i;
 </TD>
 <TD WIDTH=270>
 Clarify
@@ -3156,16 +3028,17 @@
 
 </TD>
 <TD WIDTH=33>
- te
+ te
 </TD>
 <TD WIDTH=307>
- The
+ 
+ The
 phrase 'effective type' is defined and used in a way that is
 incompatible with C99. Such a deliberate incompatible choice of
 terminology is both unfortunate and confusing, given past practice
 of the committee to maintain greater compatibility with C99. We
 strongly suggest that the phrase 'effective type' not be used in
- such an incompatible way.
+ such an incompatible way.
 
 
 </TD>
@@ -3204,15 +3077,15 @@
 Add (3.11) after over-aligned
 type as the link.
 [
- Note: pointers to over-aligned types(3.11)
+ Note: pointers to over-aligned types(3.11)
 have no special representation, but their range of valid values is
 restricted by the extended alignment requirement. This
 International Standard specifies only two ways of obtaining such a
 pointer: taking the address of a valid object with an over-aligned
- type(3.11),
+ type(3.11),
 and using one of the runtime pointer alignment functions. An
 implementation may provide other means of obtaining a valid
- pointer value for an over-aligned type(3.11).—end
+ pointer value for an over-aligned type(3.11).—end
 note ]
 </TD>
 <TD WIDTH=157>
@@ -3220,18 +3093,6 @@
 
 </TD>
 </TR>
-</TABLE>
-
- 
-
-<TABLE WIDTH=1036 BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0>
- <COL WIDTH=23>
- <COL WIDTH=77>
- <COL WIDTH=69>
- <COL WIDTH=33>
- <COL WIDTH=307>
- <COL WIDTH=270>
- <COL WIDTH=157>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
 US
@@ -3874,10 +3735,12 @@
 </TD>
 <TD WIDTH=307>
 
- The
- standard does not clarify the meaning of <CODE>this</CODE>
+ 
+ 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?
+ the lambda is nested?
 
 
 </TD>
@@ -3907,9 +3770,10 @@
 </TD>
 <TD WIDTH=307>
 
- The
+ 
+ The
 current wording does not specify how context capturing and name
- resolution take
+ resolution take
 place when the inner lambda refers to the outer lambda's locals
 variables and parameters.
 
@@ -4259,18 +4123,18 @@
 <TD WIDTH=307>
 DE-6
 Some uses of lambda expressions refer to specializations of the
- unconstrained class template std::reference_closure
+ 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
- 20.7.18, for the class template std::reference_closure,
- require Returnable
- for R
- and VariableType
- for each of the ArgTypes.
+ 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>
 
@@ -5258,11 +5122,11 @@
 
 </TD>
 <TD WIDTH=33>
- te
+ te
 </TD>
 <TD WIDTH=307>
- Should
- not the type of alignof-expression be of type std::max_align_t?
+ Should
+ not the type of alignof-expression be of type std::max_align_t?
 </TD>
 <TD WIDTH=270>
 
@@ -5521,23 +5385,26 @@
 
 </TD>
 <TD WIDTH=33>
- te
+ te
 </TD>
 <TD WIDTH=307>
- The
- constant-expression in
+ 
+ The
+ constant-expression in
 
 
- case
- constant-expression
+ 
+ case
+ constant-expression
 
 
- should
+ 
+ should
 be allowed to be of any constant expression of literal type for
 which a constexpr comparison operator (operator< and
 operator==) is in scope. Now that constant expressions of other
 integral types are evaluated at compile time, the restriction for
- case-labels is at best artificial.
+ case-labels is at best artificial.
 
 
 </TD>
@@ -5614,8 +5481,8 @@
 
 {
 
-     typedef
- decltype( expression ) _RangeT;
+     typedef
+ decltype( expression ) _RangeT;
 
     auto &&
 __range = ( expression );
@@ -5749,8 +5616,7 @@
 </TD>
 <TD WIDTH=270>
 State
- that such a late-checked block has the same meaning as if the
- late_check
+ that such a late-checked block has the same meaning as if the late_check
 keyword were absent.
 </TD>
 <TD WIDTH=157>
@@ -6098,25 +5964,30 @@
 
 </TD>
 <TD WIDTH=33>
- te
+ te
 </TD>
 <TD WIDTH=307>
- 'constexpr'
+ 
+ 'constexpr'
 functions should be allowed to take const reference parameters, as
 long as their uses are in a context where a constant expression
- may be required. For example, the following should be allowed
+ may be required. For example, the following should be allowed
 
 
- template<typename
- T, int N>
- int
- size(const T(&)[N]) { return N; }
+ 
+ template<typename
+ T, int N>
+ 
+ int
+ size(const T(&)[N]) { return N; }
 
 
- int
- a[] = { 41,42,43,44 };
- enum
- { v = size(a) };
+ 
+ int
+ a[] = { 41,42,43,44 };
+ 
+ enum
+ { v = size(a) };
 
 
 </TD>
@@ -6585,47 +6456,58 @@
 
 </TD>
 <TD WIDTH=33>
- te
+ te
 </TD>
 <TD WIDTH=307>
- Now
+ 
+ Now
 that 'auto' is finally used in its most obvious sense to state
 `deduce the type of this variable from initializer', it should
- also be allowed in template parameter declarations, as in
+ also be allowed in template parameter declarations, as in
 
 
- template<auto
- n> struct X { /* … */ };
+ 
+ template<auto
+ n> struct X { /* … */ };
 
 
- X<903>
- x;
+ 
+ X<903>
+ x;
 
 
- X<&Widget::callback>
- y;
+ 
+ X<&Widget::callback>
+ y;
 
 
- instead
- of the current, often verbose and cumbersome
+ 
+ instead
+ of the current, often verbose and cumbersome
 
 
- template<typename
- T, T n> struct X { /* … */
- };
+ 
+ 
+ template<typename
+ T, T n> struct X { /* … 
+ */
+ };
 
 
- X<int,903>
- x;
- X<void
- (Widget::*)(),&Widget::callback> y;
+ 
+ X<int,903>
+ x;
+ 
+ X<void
+ (Widget::*)(),&Widget::callback> y;
 
 
- We
+ 
+ We
 understand that 'auto' is used in 14.1/18 in a different way (for
 constrained template), but that usable appears very strange
 syntax, unnatural and does not fit well with the usage in this
- section.
+ section.
 
 
 </TD>
@@ -7066,22 +6948,25 @@
 21
 </TD>
 <TD WIDTH=33>
- te
+ te
 </TD>
 <TD WIDTH=307>
- The
+ The
 syntax for concept map alias is unnecessarily both confused and
- verbose.
+ verbose.
 </TD>
 <TD WIDTH=270>
- We
- strongly suggest simplifications, e.g.
- using
- N1::C<int>;
- that
+ 
+ We
+ strongly suggest simplifications, e.g.
+ 
+ using
+ N1::C<int>;
+ 
+ that
 fits well with existing constructs. The syntactic complexity is
 too high for a new feature presumably designed to support sound
- programming.
+ programming.
 
 
 </TD>
@@ -7143,8 +7028,10 @@
 
 The
 list of attributes is missing an attribute to indicate that a
- function with a <CODE>throw()</CODE>
- (throws nothing) clause need not have the <CODE>unexpected()</CODE>
+ function with a <CODE>
+ throw()</CODE>
+ (throws nothing) clause need not have the <CODE>
+ unexpected()</CODE>
 catch clause generated. This attribute was a motivating example
 for the attribute syntax, and its omission is surprising.
 
@@ -7198,20 +7085,21 @@
 26
 </TD>
 <TD WIDTH=77>
- 7.6
- [Attributes]
+ 7.6
+ [Attributes]
 </TD>
 <TD WIDTH=69>
 
 
 </TD>
 <TD WIDTH=33>
- ed
+ ed
 </TD>
 <TD WIDTH=307>
- Are
+ 
+ Are
 they part of object types or not? The section does not appear to
- indicate that clearly.
+ indicate that clearly.
 
 
 </TD>
@@ -7259,28 +7147,31 @@
 27
 </TD>
 <TD WIDTH=77>
- 7.6.1
+ 7.6.1
 </TD>
 <TD WIDTH=69>
 
 
 </TD>
 <TD WIDTH=33>
- te
+ te
 </TD>
 <TD WIDTH=307>
- This
+ 
+ This
 section specifies that no name lookup is performed on any
 identifier contained in an attribute-token. This in particular
 implies that, for example, it is impossible to define a template
 class parameterized by its alignment. That restriction is
- unacceptable.
- The
- original alignment proposal made that useful construct possible.
- Furthermore
+ unacceptable.
+ 
+ The
+ original alignment proposal made that useful construct possible.
+ 
+ Furthermore
 paragraph 7.6.1/2 appears contradictory with the rest of that
 section -- since no name lookup is performed, how a 'type-id'is
- determined?
+ determined?
 
 
 </TD>
@@ -7541,7 +7432,8 @@
 <TD WIDTH=307>
 
 The
- meaning of the <CODE>[[final]]</CODE>
+ meaning of the <CODE>
+ [[final]]</CODE>
 attribute applied to classes is inconsistent with other languages
 and not desirable in its own right.
 
@@ -7550,9 +7442,11 @@
 <TD WIDTH=270>
 
 Modify
- the semantics of <CODE>[[final]]</CODE>
+ the semantics of <CODE>
+ [[final]]</CODE>
 applied to classes. See the attached paper "Issues with the
- C++ Standard" under Chapter 7 "Meaning of <CODE>[[final]]</CODE>
+ C++ Standard" under Chapter 7 "Meaning of <CODE>
+ [[final]]</CODE>
 attribute applied to classes".
 
 
@@ -7673,8 +7567,10 @@
 With
 the introduction of late-specified return types for functions and
 lambda expressions, we now have three different syntaxes for
- declaring functions. The <CODE>-></CODE>
- late declaration is used in two. The <CODE>auto</CODE>
+ declaring functions. The <CODE>
+ -></CODE>
+ late declaration is used in two. The <CODE>
+ auto</CODE>
 keyword is used in one, but also used differently in variable
 definitions.
 
@@ -7753,99 +7649,126 @@
 </TR>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
- US
- 45
+ 
+ US
+ 45
 </TD>
 <TD WIDTH=77>
- 8.3.5
+ 
+ 8.3.5
 </TD>
 <TD WIDTH=69>
- 13
+ 
+ 13
 </TD>
 <TD WIDTH=33>
- te
+ 
+ te
 </TD>
 <TD WIDTH=307>
- At
+ 
+ At
 present, function parameter packs can only occur at the end of a
 parameter-declaration-list. This restriction unnecessarily
 prohibits uses of function parameter packs in cases where template
- argument deduction isn’t needed, e.g.,
+ argument deduction isn’t needed, e.g.,
 
 
- template<class...
- T> struct X { };
- template<class...
- T1, class... T2>
- struct
- X<pair<T1, T2>...> {
- void
- f(T1..., T2...);
- };
+ 
+ template<class...
+ T> struct X { };
+ 
+ template<class...
+ T1, class... T2>
+ 
+ struct
+ X<pair<T1, T2>...> {
+ 
+ void
+ f(T1..., T2...);
+ 
+ };
 
 
- More
+ 
+ More
 importantly, this restriction is inconsistent with the way pack
 expansions are handled. For example, this template is well-formed
- (but X<T..., int> is a non-deduced context):
+ (but X<T..., int> is a non-deduced context):
 
 
- template<class...
- T> void f(X<T..., int>);
+ 
+ template<class...
+ T> void f(X<T..., int>);
 
 
- Therefore,
+ 
+ Therefore,
 the restriction that limits function parameter packs to the end of
 the parameter-declaration-list should be removed. Instead,
 function parameter packs not at the end of the
 parameter-declaration-list should be considered non-deduced
- contexts.
+ contexts.
 </TD>
 <TD WIDTH=270>
- In
- 8.3.5p13, remove the sentence “A
+ 
+ 
+ In
+ 8.3.5p13, remove the sentence “A
 function parameter pack, if present, shall occur at the end of the
- parameter-declaration-list.”
+ parameter-declaration-list.”
 
 
- In
+ 
+ 
+ In
 14.8.2.1p1, replace the phrase “For a function parameter
 pack” with “For a function parameter pack that occurs
- at the end of a parameter-declaration-list”.
+ at the end of a 
+ parameter-declaration-list”.
 
 
- Replace
+ 
+ 
+ Replace
 the note text “A function parameter pack can only occur at
- the end of a parameter-declaration-list
+ the end of a parameter-declaration-list
 (8.3.5).” with “A function parameter pack that does
 not occur at the end of a parameter-declaration-list is a
- non-deduced context.”
+ non-deduced context.”
 
 
- In
+ 
+ In
 14.8.2.5p5, add a new bullet: “A function parameter pack
- that does not occur at the end of its parameter-declaration-list.”
+ that does not occur at the end of its parameter-declaration-list.”
 
 
- In
- 14.8.2.5p10, replace “If
- the
+ 
+ 
+ In
+ 14.8.2.5p10, replace “If
+ 
+ the
 parameter-declaration corresponding to Pi is a function parameter
- pack” with “If
- the
+ pack” with “If
+ 
+ the
 parameter-declaration corresponding to Pi is a function parameter
 pack and Pi occurs at the end of the parameter-declaration-list”.
- 
+ 
 
 
 
- Replace
- the
+ 
+ 
+ Replace
+ the
 note text “A function parameter pack can only occur at the
- end of a parameter-declaration-list
+ end of a parameter-declaration-list
 (8.3.5).” with “A function parameter pack that does
 not occur at the end of a parameter-declaration-list is a
- non-deduced context.”
+ non-deduced context.”
 
 
 </TD>
@@ -7920,31 +7843,38 @@
 </TR>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
- US
- 46
+ 
+ US
+ 46
 </TD>
 <TD WIDTH=77>
- 8.5.3
+ 
+ 8.5.3
 </TD>
 <TD WIDTH=69>
 
 
 </TD>
 <TD WIDTH=33>
- te
+ 
+ te
 </TD>
 <TD WIDTH=307>
- The
+ 
+ The
 ability for an rvalue reference to bind to an lvalue opens a
 type-safety hole that becomes very dangerous with concepts. For
- example, consider vector’s push_back operation:
- requires
- MoveConstructible<T> void push_back(T&&);
- requires
- CopyConstructible<T> void push_back(const T&);
+ example, consider vector’s push_back operation:
+ 
+ requires
+ MoveConstructible<T> void push_back(T&&);
+ 
+ requires
+ CopyConstructible<T> void push_back(const T&);
 
 
- For
+ 
+ For
 a copy-constructible T (which is also move-constructible),
 push_back does the right thing. However, if T is something that is
 move-constructible (e.g., unique_ptr<int>), the second
@@ -7952,39 +7882,45 @@
 away), so only the first overload remains. Therefore, one could
 accidentally call push_back with an lvalue of type T, and
 push_back would silently move from the lvalue. The same problem
- occurs without concepts (albeit less frequently).
+ occurs without concepts (albeit less frequently).
 
 
 
 
 </TD>
 <TD WIDTH=270>
- Prohibit
- rvalue references from binding to lvalues.
+ 
+ Prohibit
+ rvalue references from binding to lvalues.
 
 
- Unfortunately
+ 
+ Unfortunately
 this change will break some current use cases of rvalue reference
 including the use of rvalue streams, and of the forward function
 itself. To resolve this we may want to consider three types of
- references:
+ references:
 
 
 <OL>
- <LI>The
- current reference.
- <LI>A
- non-const reference that only binds to rvalues.
- <LI>A
- non-const reference that will bind to both lvalues and rvalues.
+ <LI>
+ The
+ current reference.
+ <LI>
+ A
+ non-const reference that only binds to rvalues.
+ <LI>
+ A
+ non-const reference that will bind to both lvalues and rvalues.
 </OL>
 
 
- Still
+ 
+ Still
 another solution would be to adopt the “deleted function”
 solution for all functions. This solution is described in comment
 for 12.1, 12.4, 12.8, but restricted to special functions in that
- comment. (See US NN).
+ comment. (See US NN).
 </TD>
 <TD WIDTH=157>
 
@@ -8083,70 +8019,88 @@
 </TR>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
- US
- 50
+ 
+ US
+ 50
 </TD>
 <TD WIDTH=77>
- 12.1,
- 12.4, 12.8
+ 
+ 12.1,
+ 12.4, 12.8
 </TD>
 <TD WIDTH=69>
 
 
 </TD>
 <TD WIDTH=33>
- te
+ 
+ te
 </TD>
 <TD WIDTH=307>
- Implicitly-declared
+ 
+ Implicitly-declared
 default constructors, destructors, copy constructors, and copy
 assignment operators are deleted when their definitions would be
 ill-formed. However, unlike with overloading and template argument
 deduction, access control is performed as part of the check for
 making one of these special function deleted. This inconsistency
- should be removed.
+ should be removed.
 
 
- This
+ 
+ This
 change would sacrifice some backward compatibility in favor of
 consistency. With the current wording, checking that the following
 class ‘A’ is CopyConstructible would proceed without
- error (it is not CopyConstructible):
- class
- A { A(const A&); };
- With
+ error (it is not CopyConstructible):
+ 
+ class
+ A { A(const A&); };
+ 
+ With
 the proposed change, testing whether A is CopyConstructible would
 produce a diagnostic. To fix the problem, the user would have to
- use a deleted function:
- class
- A { A(const A&) = delete; };
+ use a deleted function:
+ 
+ class
+ A { A(const A&) = delete; };
 
 
 </TD>
 <TD WIDTH=270>
- In
- 12.1p5, remove the phrase “
- or inaccessible from the implicitly-declared default constructor”.
+ 
+ 
+ In
+ 12.1p5, remove the phrase “
+ or inaccessible from the implicitly-declared default 
+ constructor”.
 
 
- In
- 12.4p3, remove the phrase “or
+ 
+ 
+ In
+ 12.4p3, remove the phrase “or
 a destructor that is inaccessible from the implicitly-declared
 destructor,” and the phrase “or a destructor that is
- inaccessible from the implicitly-declared
- destructor”.
+ inaccessible from the 
+ implicitly-declared
+ destructor”.
 
 
- In
- 12.8p5, remove the phrase “
+ 
+ 
+ In
+ 12.8p5, remove the phrase “
 or inaccessible from the implicitly-declared copy constructor”
- from the two places it occurs.
+ from the two places it occurs.
 
 
- In
- 12.8p10, remove the phrase “or
+ 
+ 
+ In
+ 12.8p10, remove the phrase “or
 inaccessible from the implicitly-declared copy assignment
- operator” from the two places it occurs.
+ operator” from the two places it occurs.
 
 
 </TD>
@@ -8161,8 +8115,9 @@
 28
 </TD>
 <TD WIDTH=77>
- 12.6.1
- [Explicit initialization]
+ 
+ 12.6.1
+ [Explicit initialization]
 
 
 </TD>
@@ -8171,12 +8126,12 @@
 
 </TD>
 <TD WIDTH=33>
- te
+ te
 </TD>
 <TD WIDTH=307>
- This
+ This
 section, in particular the example with `g' appears contradictory
- with the syntax for uniform initialization.
+ with the syntax for uniform initialization.
 </TD>
 <TD WIDTH=270>
 
@@ -8528,8 +8483,9 @@
 29
 </TD>
 <TD WIDTH=77>
- 14.3
- [Template arguments]
+ 
+ 14.3
+ [Template arguments]
 
 
 </TD>
@@ -8538,12 +8494,12 @@
 
 </TD>
 <TD WIDTH=33>
- te
+ te
 </TD>
 <TD WIDTH=307>
- Constant
+ Constant
 expressions of any literal type should be allowed as template
- arguments.
+ arguments.
 </TD>
 <TD WIDTH=270>
 
@@ -8556,53 +8512,68 @@
 </TR>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
- US
- 53
+ 
+ US
+ 53
 </TD>
 <TD WIDTH=77>
- 14.5.1
+ 
+ 14.5.1
 </TD>
 <TD WIDTH=69>
- 5
+ 
+ 5
 </TD>
 <TD WIDTH=33>
- te
+ 
+ te
 </TD>
 <TD WIDTH=307>
- If
+ 
+ 
+ If
 the requirements of a constrained member that is a copy
 constructor, copy assignment operator, or destructor are not
 satisfied, then that user-declared special function will not
 exist. It appears that, in this case, the special function will
- then be implicitly
+ then be 
+ implicitly
 defined, which is likely to either (a) fail to compile or (b)
- produce a function with the wrong semantics. For example:
- template<ObjectType
- T> class vector {
- T*
- first, last, end;
- public:
- requires
- CopyConstructible<T> vector(const vector&);
- };
+ produce a function with the wrong semantics. For example:
+ 
+ template<ObjectType
+ T> class vector {
+ 
+ T*
+ first, last, end;
+ 
+ public:
+ 
+ requires
+ CopyConstructible<T> vector(const vector&);
+ 
+ };
 
 
- If
+ 
+ If
 instantiated with a type that is not CopyConstructible, vector
 will get an implicitly-defined copy constructor that performs a
- copy of the pointers.
+ copy of the pointers.
 </TD>
 <TD WIDTH=270>
- Add
- to 14.5.1p5:
- If
+ 
+ Add
+ to 14.5.1p5:
+ 
+ If
 the constrained member is a copy constructor (12.8), destructor
 (12.4), or copy assignment operator and its template requirements
 are not satisfied, then a copy constructor, destructor, or copy
 assignment operator, respectively, with the same signature as the
 constrained member (after substituting the class template’s
 template arguments for its template parameters) will be declared
- as a deleted function (8.4).
+ as a deleted function (8.4).
 </TD>
 <TD WIDTH=157>
 
@@ -8648,48 +8619,58 @@
 30
 </TD>
 <TD WIDTH=77>
- 14.5.7
- [Template aliases]
+ 14.5.7
+ [Template aliases]
 </TD>
 <TD WIDTH=69>
 
 
 </TD>
 <TD WIDTH=33>
- te
+ te
 </TD>
 <TD WIDTH=307>
- When
- are two template alias names equivalent?
+ 
+ When
+ are two template alias names equivalent?
 
 
- E.g.
- given
- template<template<class>
- class> struct X { };
+ 
+ E.g.
+ given
+ 
+ template<template<class>
+ class> struct X { };
 
 
- template<typename,typename>
- struct Y { };
+ 
+ template<typename,typename>
+ struct Y { };
 
 
- template<typename
- T>
- using
- Z1 = Y<int,T>;
+ 
+ template<typename
+ T>
+ 
+ using
+ Z1 = Y<int,T>;
 
 
- template<typename
- T>
- using
- Z2 = Y<int,T>;
+ 
+ template<typename
+ T>
+ 
+ using
+ Z2 = Y<int,T>;
 
 
- Are
- the types X<Z1> and X<Z2> equivalent?
- We
+ 
+ Are
+ the types X<Z1> and X<Z2> equivalent?
+ 
+ We
 would suggest yes (since Z1<T> and Z2<T> are the same
- for all T), but we do not see any wording to that effect.
+ for all T), but we do not see any wording to that effect.
 
 
 </TD>
@@ -8734,7 +8715,8 @@
 
 
 if
- that namespace is inline, any namespace forming
+ that namespace is inline, any namespace 
+ forming
 its enclosing namespace set.
 
 
@@ -8809,7 +8791,8 @@
 
 
 any
- namespace forming
+ namespace 
+ forming
 its enclosing namespace set
 
 
@@ -8843,9 +8826,9 @@
 
 Typo, duplicated "is"
 
- "At
- certain points in the template argument deduction process it is
- is necessary"
+ "At
+ certain points in the template argument deduction process it is
+ is necessary"
 
 
 
@@ -9015,21 +8998,25 @@
 </TR>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
- US
- 59
+ 
+ US
+ 59
 </TD>
 <TD WIDTH=77>
- 14.9.1.4
+ 
+ 14.9.1.4
 </TD>
 <TD WIDTH=69>
 
 
 </TD>
 <TD WIDTH=33>
- te
+ 
+ te
 </TD>
 <TD WIDTH=307>
- Axioms
+ 
+ Axioms
 are under-specified and provide little benefit to programmers, so
 they should be removed from the working paper. The optimizations
 permitted by axioms (see 14.9.1.4p4-5) are not compulsory (and,
@@ -9040,52 +9027,62 @@
 starting with c++std-lib-22717). Given the level of confusion and
 the inability to verify the correctness of axioms, it is likely
 that many axioms written by programmers (including those specified
- in the candidate draft) will be incorrect.
+ in the candidate draft) will be incorrect.
 </TD>
 <TD WIDTH=270>
- Remove
- clause 14.9.1.4 [concept.axiom]
- In
- 2.11p1, remove “axiom” from the list of keywords.
+ 
+ Remove
+ clause 14.9.1.4 [concept.axiom]
+ 
+ In
+ 2.11p1, remove “axiom” from the list of keywords.
 
 
- In
+ 
+ In
 14.5.8p7, remove “, or if the resulting concept map fails to
- satisfy the axioms of the corresponding concept”
+ satisfy the axioms of the corresponding concept”
 
 
- In
+ 
+ In
 14.9.1p6, remove axiom-definition from the list of grammar
 productions for concept-member-specifier. Remove “, and
 axioms” from the final sentence, and instead “and”
 prior to “associated requirements” in the final
- sentence.
+ sentence.
 
 
 
 
- Remove
- paragraph 14 of clause 14.9.2.
+ 
+ Remove
+ paragraph 14 of clause 14.9.2.
 
 
- In
+ 
+ 
+ In
 14.10.1p6, remove the sentence, “When the
 concept-instance-alias-def appears in the optional requires-clause
 of an axiom-definition (14.9.1.4), the potential scope of the
 identifier begins at its point of declaration and terminates at
- the end of the axiom-deﬁnition.”
+ the end of the axiom-deﬁnition.”
 
 
- In
+ 
+ 
+ In
 clauses 20.2.5, 20.2.8, 23.1.6.1, 23.1.6.2, and 24.1.4, remove the
 axiom-definitions and replace them with paragraphs (denoted
 Requires, Postconditions, or Effects, as appropriate) that
 express the intended semantics of the concepts from which the
- axiom-definitions were removed.
+ axiom-definitions were removed.
 
 
- In
- 24.1.4p2, replace the word “axiom” with “condition.”
+ 
+ In
+ 24.1.4p2, replace the word “axiom” with “condition.”
 
 
 </TD>
@@ -9100,34 +9097,40 @@
 31
 </TD>
 <TD WIDTH=77>
- 14.9.1.4
- [Axioms]
+ 14.9.1.4
+ [Axioms]
 </TD>
 <TD WIDTH=69>
 
 
 </TD>
 <TD WIDTH=33>
- te
+ te
 </TD>
 <TD WIDTH=307>
- This
+ 
+ This
 section states that an axiom-definition defines a new semantics
- axiom but is unusually vague as to what those semantics might be.
+ axiom but is unusually vague as to what those semantics might be.
 
 
- The
+ 
+ The
 use of the '==' and '!=' with completely new semantics, unrelated
 to anything we have seen before in C++ is both unwise and
 confusing, especially if the types involved in the expressions
- happen to have operator== and operator!= defined.
- We
- strongly suggest use of different tokens, e.g. ,
- and opposed to this obscure usage/overload.
- The
+ happen to have operator== and operator!= defined.
+ 
+ 
+ We
+ strongly suggest use of different tokens, e.g. 
+ ,
+ and opposed to this obscure usage/overload.
+ 
+ The
 description is very vague. How many times is an implementation
 permitted to replace one expression by another one when they have
- side effects?
+ side effects?
 
 
 </TD>
@@ -9448,20 +9451,25 @@
 </TR>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
- US
- 60
+ 
+ US
+ 60
 </TD>
 <TD WIDTH=77>
- 14.10.1
+ 
+ 14.10.1
 </TD>
 <TD WIDTH=69>
- 1
+ 
+ 1
 </TD>
 <TD WIDTH=33>
- te
+ 
+ te
 </TD>
 <TD WIDTH=307>
- The
+ 
+ The
 use of && as the separator for a list of requirements has
 shown itself to be a serious teachability problem. The mental
 model behind ‘&&’ treats concepts as simple
@@ -9470,36 +9478,46 @@
 (and especially try to fake || with && and !), the harder
 it is for them to understand the role of concept maps. Simply
 changing the separator to ‘,’ would eliminate a
- significant source of confusion.
+ significant source of confusion.
 </TD>
 <TD WIDTH=270>
- Replace
- 
+ 
+ Replace
+ 
 
- requirement-list:
- requirement-list
- ... [opt] && requirement
- requirement
- ... [opt]
+ 
+ requirement-list:
+ 
+ requirement-list
+ ... [opt] && requirement
+ 
+ requirement
+ ... [opt]
 
 
- with
+ 
+ with
 
 
- requirement-list
- requirement-list
- ...[opt] , requirement
- requirement
- ... [opt]
+ 
+ requirement-list
+ 
+ requirement-list
+ ...[opt] , requirement
+ 
+ requirement
+ ... [opt]
 
 
- In
- 14.5.4p6, replace the first sentence with: 
+ 
+ In
+ 14.5.4p6, replace the first sentence with: 
 
- The
+ 
+ The
 instantiation of an expansion produces a comma-separated list E1,
 E2, ..., EN, where N is the number of elements in the pack
- expansion parameters.
+ expansion parameters.
 
 
 </TD>
@@ -9986,7 +10004,7 @@
 
 
 
- http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html
+ http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html
 
 
 </TD>
@@ -10014,12 +10032,12 @@
 Library
 </TD>
 <TD WIDTH=33>
- ge
+ ge
 </TD>
 <TD WIDTH=307>
- The
+ The
 adoption of the library `constexpr' proposal was not reflected in
- the draft, despite formal WG21 committee vote.
+ the draft, despite formal WG21 committee vote.
 </TD>
 <TD WIDTH=270>
 FR
@@ -10098,23 +10116,27 @@
 </TR>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
- US
- 62
+ 
+ US
+ 62
 </TD>
 <TD WIDTH=77>
- 17-30
+ 
+ 17-30
 </TD>
 <TD WIDTH=69>
 
 
 </TD>
 <TD WIDTH=33>
- ge
+ 
+ ge
 </TD>
 <TD WIDTH=307>
- Provide
+ 
+ Provide
 concepts and requirements clauses for all standard library
- templates
+ templates
 
 
 </TD>
@@ -10512,8 +10534,8 @@
 
 
  typedef
- basic_fstream<char32_t> u32fstream;
- 
+ basic_fstream<char32_t> u32fstream;
+ 
 
 
  
@@ -10567,8 +10589,8 @@
 basic_istream<wchar_t> wistream; 
 
 
-  typedef
- basic_istream<char16_t> u16istream;
+  typedef
+ basic_istream<char16_t> u16istream;
 
  typedef
 basic_istream<char32_t> u32istream;
@@ -10590,8 +10612,8 @@
 basic_iostream<wchar_t> wiostream; 
 
 
-  typedef
- basic_iostream<char16_t> u16iostream;
+  typedef
+ basic_iostream<char16_t> u16iostream;
 
  typedef
 basic_iostream<char32_t> u32iostream;
@@ -10619,8 +10641,8 @@
 basic_ostream<wchar_t> wostream; 
 
 
-  typedef
- basic_ostream<char16_t> u16ostream;
+  typedef
+ basic_ostream<char16_t> u16ostream;
 
  typedef
 basic_ostream<char32_t> u32ostream;
@@ -10660,8 +10682,8 @@
 basic_stringbuf<wchar_t> wstringbuf; 
 
 
-  typedef
- basic_stringbuf<char16_t> u16stringbuf;
+  typedef
+ basic_stringbuf<char16_t> u16stringbuf;
 
  typedef
 basic_stringbuf<char32_t> u32stringbuf;
@@ -10690,8 +10712,8 @@
 basic_istringstream<wchar_t> wistringstream; 
 
 
-  typedef
- basic_istringstream<char16_t> u16istringstream;
+  typedef
+ basic_istringstream<char16_t> u16istringstream;
 
  typedef
 basic_istringstream<char32_t> u32istringstream;
@@ -10720,8 +10742,8 @@
 basic_ostringstream<wchar_t> wostringstream; 
 
 
-  typedef
- basic_ostringstream<char16_t> u16ostringstream;
+  typedef
+ basic_ostringstream<char16_t> u16ostringstream;
 
  typedef
 basic_ostringstream<char32_t> u32ostringstream;
@@ -10785,8 +10807,8 @@
 basic_filebuf<wchar_t> wfilebuf; 
 
 
-  typedef
- basic_filebuf<char16_t> u16filebuf;
+  typedef
+ basic_filebuf<char16_t> u16filebuf;
 
  typedef
 basic_filebuf<char32_t> u32filebuf;
@@ -10808,8 +10830,8 @@
 basic_ifstream<wchar_t> wifstream; 
 
 
-  typedef
- basic_ifstream<char16_t> u16ifstream;
+  typedef
+ basic_ifstream<char16_t> u16ifstream;
 
  typedef
 basic_ifstream<char32_t> u32ifstream;
@@ -10831,8 +10853,8 @@
 basic_ofstream<wchar_t> wofstream; 
 
 
-  typedef
- basic_ofstream<char16_t> u16ofstream;
+  typedef
+ basic_ofstream<char16_t> u16ofstream;
 
  typedef
 basic_ofstream<char32_t> u32ofstream;
@@ -10854,8 +10876,8 @@
 basic_fstream<wchar_t> wfstream; 
 
 
-  typedef
- basic_fstream<char16_t> u16fstream;
+  typedef
+ basic_fstream<char16_t> u16fstream;
 
  typedef
 basic_fstream<char32_t> u32fstream;
@@ -11017,13 +11039,13 @@
 regex_token_iterator<const char32_t*>
 u32cregex_token_iterator;
 
-  typedef
+  typedef
 regex_token_iterator<string::const_iterator>
- sregex_token_iterator; 
+ sregex_token_iterator; 
 
 
  typedef
- regex_token_iterator<wstring::const_iterator>　　　wsregex_token_iterator;
+ regex_token_iterator<wstring::const_iterator>　　　wsregex_token_iterator;
 
 
 
@@ -11032,7 +11054,7 @@
 u16sregex_token_iterator;
 
  typedef
- regex_token_iterator<u32string::const_iterator>　u32sregex_token_iterator;
+ regex_token_iterator<u32string::const_iterator>　u32sregex_token_iterator;
 
 
 
@@ -11090,8 +11112,8 @@
 </TD>
 <TD WIDTH=307>
 
- Summary
- of numeric facilities should mention random numbers
+ Summary
+ of numeric facilities should mention random numbers
 
 
 </TD>
@@ -12500,9 +12522,9 @@
 <TD WIDTH=270>
 
 Add
- "3.11,
- Alignment"
- to SEE ALSO.
+ "3.11,
+ Alignment"
+ to SEE ALSO.
 </TD>
 <TD WIDTH=157>
 
@@ -12515,34 +12537,35 @@
 32
 </TD>
 <TD WIDTH=77>
- 18.2.1
- [Numeric limits]
+ 18.2.1
+ [Numeric limits]
 </TD>
 <TD WIDTH=69>
 
 
 </TD>
 <TD WIDTH=33>
- te
+ te
 </TD>
 <TD WIDTH=307>
- The
+ 
+ The
 definition of numeric_limits<> as requiring a regular type
 is both conceptually wrong and operationally illogical. As we
 pointed before, this mistake needs to be corrected. For example,
 the template can be left unconstrained. In fact this reflects a
 much more general problem with concept_maps/axioms and their
 interpretations. It appears that the current text heavily leans
- toward experimental academic type theory.
+ toward experimental academic type theory.
 
 
 </TD>
 <TD WIDTH=270>
- We
+ 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.
+ assertions on the carrier type.
 </TD>
 <TD WIDTH=157>
 
@@ -12565,11 +12588,11 @@
 </TD>
 <TD WIDTH=307>
 DE-16
- The class template numeric_limits
- should not specify the Regular
+ The class template numeric_limits
+ should not specify the Regular
 concept requirement for its template parameter, because it
 contains functions returning NaN values for floating-point types;
- these values violate the semantics of EqualityComparable.
+ these values violate the semantics of EqualityComparable.
 See also library issue 902 in WG21 document N2794 "C++
 Standard Library Active Issues List (Revision R60)",
 available at
@@ -12581,7 +12604,7 @@
 <TD WIDTH=270>
 Specify
 a concept requirement with fewer constraints as appropriate, for
- example SemiRegular.
+ example SemiRegular.
 </TD>
 <TD WIDTH=157>
 
@@ -12632,14 +12655,14 @@
 
 
 
- template<Regular
- T> class numeric_limits<const T>;
+ template<Regular
+ T> class numeric_limits<const T>;
 
- template<Regular
- T> class numeric_limits<volatile T>;
+ template<Regular
+ T> class numeric_limits<volatile T>;
 
- template<Regular
- T> class numeric_limits<const volatile T>;
+ template<Regular
+ T> class numeric_limits<const volatile T>;
 
 
 </TD>
@@ -12666,7 +12689,7 @@
 </TD>
 <TD WIDTH=307>
 DE-17
- The class type_index
+ The class type_index
 should be removed; it provides no additional functionality beyond
 providing appropriate concept maps.
 
@@ -12675,7 +12698,7 @@
 <TD WIDTH=270>
 Specify
 concept maps for "const type_info *" as required by the
- ordered and unordered containers and remove the class type_index.
+ ordered and unordered containers and remove the class type_index.
 </TD>
 <TD WIDTH=157>
 
@@ -13112,12 +13135,12 @@
 </TD>
 <TD WIDTH=307>
 
- Errors
+ Errors
 reported by Exception classes are of types char or std::string
- only. For
+ 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.
+ char32_t/u32string can not be used.
 
 
 </TD>
@@ -13423,10 +13446,10 @@
 </TD>
 <TD WIDTH=307>
 “ See
- also: ISO C 7.1.4, 7.2,
- Amendment 1 4.3.”
+ 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.
+ C89, not C99.
 </TD>
 <TD WIDTH=270>
 Delete
@@ -13474,9 +13497,11 @@
 
 
 Components
- that I propose eliminating include HasAllocatorType?,
+ that I propose eliminating include 
+ HasAllocatorType?,
 is_scoped_allocator, allocator_propagation_map,
- scoped_allocator_adaptor, and ConstructibleAsElement?.
+ scoped_allocator_adaptor, and 
+ ConstructibleAsElement?.
 
 
 
@@ -14272,8 +14297,8 @@
 <TD WIDTH=270>
 
 Add
- the following requirements. "it
- has a public move constructor that performs a member-wise move."
+ the following requirements. "it
+ has a public move constructor that performs a member-wise move."
 
 Add the MoveConstructible.
 </TD>
@@ -14390,15 +14415,15 @@
 
 
 
- template<class
- F, Allocator Alloc>
- function(allocator_arg_t, const Alloc
- &, F);
+ template<class
+ F, Allocator Alloc>
+ function(allocator_arg_t, const Alloc
+ &, F);
 
- template<class
- F, Allocator Alloc>
- function(allocator_arg_t, const Alloc
- &, F&&);
+ template<class
+ F, Allocator Alloc>
+ function(allocator_arg_t, const Alloc
+ &, F&&);
 
 
 
@@ -14451,10 +14476,10 @@
 
 
 
- template
- <Returnable
- R, CopyConstructible...
- Args>
+ template
+ <Returnable
+ R, CopyConstructible...
+ Args>
 
 concept_map
 UsesAllocator<function<R(Args...)>, Alloc> {
@@ -14538,42 +14563,42 @@
 
 
 
- template
- <Returnable
- R, CopyConstructible...
- ArgTypes>
+ template
+ <Returnable
+ R, CopyConstructible...
+ ArgTypes>
 
 bool operator==(const
 function<R(ArgTypes...)>&, nullptr_t);
 
- template
- <Returnable
- R, CopyConstructible...
- ArgTypes>
+ template
+ <Returnable
+ R, CopyConstructible...
+ ArgTypes>
 
 bool operator==(nullptr_t,
 const function<R(ArgTypes...)>&);
 
- template
- <Returnable
- R, CopyConstructible...
- ArgTypes>
+ template
+ <Returnable
+ R, CopyConstructible...
+ ArgTypes>
 
 bool operator!=(const
 function<R(ArgTypes...)>&, nullptr_t);
 
- template
- <Returnable
- R, CopyConstructible...
- ArgTypes>
+ template
+ <Returnable
+ R, CopyConstructible...
+ ArgTypes>
 
 bool operator!=(nullptr_t,
 const function<R(ArgTypes...)>&);
 
- template
- <Returnable
- R, CopyConstructible...
- ArgTypes>
+ template
+ <Returnable
+ R, CopyConstructible...
+ ArgTypes>
 
 void
 swap(function<R(ArgTypes...)>&,
@@ -14783,8 +14808,9 @@
 </TR>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
- US
- 72
+ 
+ US
+ 72
 </TD>
 <TD WIDTH=77>
 20.7.12
@@ -14794,7 +14820,8 @@
 
 </TD>
 <TD WIDTH=33>
- te
+ 
+ te
 </TD>
 <TD WIDTH=307>
 
@@ -14946,51 +14973,60 @@
 </TR>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
- US
- 73
+ 
+ US
+ 73
 </TD>
 <TD WIDTH=77>
- 20.7.18
+ 
+ 20.7.18
 </TD>
 <TD WIDTH=69>
 
 
 </TD>
 <TD WIDTH=33>
- te
+ 
+ te
 </TD>
 <TD WIDTH=307>
- The
+ 
+ The
 std::reference_closure template is redundant with std::function
- and should be removed.
+ and should be removed.
 
 
- std::reference_closure
+ 
+ std::reference_closure
 is a premature optimization that provides a limited subset of the
 functionality of std::function intended to improve performance in
 a narrow use case. However, the “parallel application
 performance” benchmark used to motivate the inclusion of
- std::reference_closure was flawed in several ways:
+ std::reference_closure was flawed in several ways:
 <OL START=3>
- <LI>it
+ <LI>
+ it
 failed to enable a common optimization in std::function
 (implemented by all vendors), exacting a large and unrealistic
- penalty for copying std::function instances, and
- <LI>it
+ penalty for copying std::function instances, and
+ <LI>
+ it
 failed to account for parallel scheduler overhead or
 realistically-sized work units, both of which would dominate the
- costs measured by the benchmark in any realistic application.
+ costs measured by the benchmark in any realistic application.
 </OL>
 
 
 </TD>
 <TD WIDTH=270>
- Remove
- 20.7.18 [func.referenceclosure].
+ 
+ Remove
+ 20.7.18 [func.referenceclosure].
 
 
- Remove
- 5.1.1 paragraph 12.
+ 
+ Remove
+ 5.1.1 paragraph 12.
 </TD>
 <TD WIDTH=157>
 
@@ -14999,21 +15035,25 @@
 </TR>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
- US
- 74
+ 
+ US
+ 74
 </TD>
 <TD WIDTH=77>
- 20.8
+ 
+ 20.8
 </TD>
 <TD WIDTH=69>
 
 
 </TD>
 <TD WIDTH=33>
- te
+ 
+ te
 </TD>
 <TD WIDTH=307>
- Scoped
+ 
+ Scoped
 allocators represent a poor trade-off for standardization, since
 (1) scoped-allocator--aware containers can be implemented outside
 the C++ standard library but used with its algorithms, (2) scoped
@@ -15026,40 +15066,48 @@
 support a very small subset of the community who can already
 implement their own data structures outside of the standard
 library. Therefore, scoped allocators should be removed from the
- working paper.
- Some
- evidence of the complexity introduced by scoped allocators:
- 20.3.3,
- 20.5: large increase in the number of pair and tuple constructors
- 23:
+ working paper.
+ 
+ Some
+ evidence of the complexity introduced by scoped allocators:
+ 
+ 20.3.3,
+ 20.5: large increase in the number of pair and tuple constructors
+ 
+ 23:
 confusing “AllocatableElement” requirements
- throughout.
+ throughout.
 
 
 </TD>
 <TD WIDTH=270>
- Remove
+ 
+ Remove
 support for scoped allocators from the working paper. This
- includes at least the following changes:
+ includes at least the following changes:
 
 
- Remove
- 20.8.3 [allocator.element.concepts]
+ 
+ Remove
+ 20.8.3 [allocator.element.concepts]
 
 
- Remove
- 20.8.7 [allocator.adaptor]
+ 
+ Remove
+ 20.8.7 [allocator.adaptor]
 
 
- Remove
- 20.8.10 [construct.element]
+ 
+ Remove
+ 20.8.10 [construct.element]
 
 
- In
+ 
+ In
 Clause 23: replace requirements naming the AllocatableElement
 concept with requirements naming CopyConstructible,
 MoveConstructible, DefaultConstructible, or Constructible, as
- appropriate.
+ appropriate.
 
 
 </TD>
@@ -15174,8 +15222,8 @@
 auto concept
 UsesAllocator<typename T, typename Alloc> {
 
- requires
- Allocator<Alloc>;
+ requires
+ Allocator<Alloc>;
 
 typename allocator_type =
 T::allocator_type;
@@ -15220,29 +15268,34 @@
 </TR>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
- US
- 77
+ 
+ US
+ 77
 </TD>
 <TD WIDTH=77>
- 20.8.4
+ 
+ 20.8.4
 </TD>
 <TD WIDTH=69>
 
 
 </TD>
 <TD WIDTH=33>
- te
+ 
+ te
 </TD>
 <TD WIDTH=307>
- Allocator-specific
+ 
+ Allocator-specific
 move and copy behavior for containers (N2525) complicates a
 little-used and already-complicated portion of the standard
 library (allocators), and breaks the conceptual model of
 move-constructor and move-assignment operations on standard
 containers being efficient operations. The extensions for
 allocator-specific move and copy behavior should be removed from
- the working paper.
- With
+ the working paper.
+ 
+ With
 the introduction of rvalue references, we are teaching programmers
 that moving from a standard container (e.g., a vector<string>)
 is an efficient, constant-time operation. The introduction of
@@ -15251,22 +15304,25 @@
 operations can be constant or linear time. This level of
 customization greatly increases the complexity of standard
 containers, and benefits only a tiny fraction of the C++
- community.
+ community.
 
 
 </TD>
 <TD WIDTH=270>
- Remove
- 20.8.4.
+ 
+ Remove
+ 20.8.4.
 
 
- Remove
- 20.8.5.
+ 
+ Remove
+ 20.8.5.
 
 
- Remove
+ 
+ Remove
 all references to the facilities in 20.8.4 and 20.8.5 from clause
- 23.
+ 23.
 </TD>
 <TD WIDTH=157>
 
@@ -15291,16 +15347,20 @@
 </TD>
 <TD WIDTH=307>
 There
- is presently no way to convert directly from a <CODE>shared_ptr</CODE>
- to a <CODE>unique_ptr</CODE>.
+ is presently no way to convert directly from a <CODE>
+ shared_ptr</CODE>
+ to a <CODE>
+ unique_ptr</CODE>.
 </TD>
 <TD WIDTH=270>
 
 Add
 an interface that performs the conversion. See the attached,
 Issues with the C++ Standard" paper under Chapter 20,
- "Conversion from <CODE>shared_ptr</CODE>
- to <CODE>unique_ptr".</CODE>
+ "Conversion from <CODE>
+ shared_ptr</CODE>
+ to <CODE>
+ unique_ptr".</CODE>
 
 
 </TD>
@@ -15311,8 +15371,9 @@
 </TR>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
- US
- 79
+ 
+ US
+ 79
 </TD>
 <TD WIDTH=77>
 20.8.12.2.1
@@ -15322,7 +15383,8 @@
 
 </TD>
 <TD WIDTH=33>
- te
+ 
+ te
 </TD>
 <TD WIDTH=307>
 
@@ -15463,8 +15525,9 @@
 </TR>
 <TR VALIGN=TOP>
 <TD WIDTH=23>
- US
- 81
+ 
+ US
+ 81
 </TD>
 <TD WIDTH=77>
 20.9.3
@@ -15474,7 +15537,8 @@
 
 </TD>
 <TD WIDTH=33>
- te
+ 
+ te
 </TD>
 <TD WIDTH=307>
 
@@ -15512,7 +15576,8 @@
 
 </TD>
 <TD WIDTH=270>
- Add:
+ 
+ Add:
 
 
 
@@ -15525,42 +15590,56 @@
 
 public: 
 
- ...
- duration&
- operator%(const rep&);
- duration&
- operator%(const duration&);
- ..
- };
+ 
+ ...
+ 
+ duration&
+ operator%(const rep&);
+ 
+ duration&
+ operator%(const duration&);
+ 
+ ..
+ 
+ };
 
 
- template
- <class Rep1, class Period,
- class
- Rep2> 
- 
- duration<typename
- common_type<
- Rep1,
- Rep2>::type, Period> 
- 
- operator%(const
- duration<Rep1, Period>& d, const Rep2& s); 
+ 
+ template
+ <class Rep1, class Period,
+ 
+ class
+ Rep2> 
+ 
+ 
+ duration<typename
+ common_type<
+ 
+ Rep1,
+ Rep2>::type, Period> 
+ 
+ 
+ operator%(const
+ duration<Rep1, Period>& d, const Rep2& s); 
 
 
 
- template
- <class Rep1, class Period1,
- class
- Rep2, class Period2> 
+ 
+ template
+ <class Rep1, class Period1,
+ 
+ class
+ Rep2, class Period2> 
 
- typename
+ 
+ typename
 common_type<duration<Rep1, Period1>, duration<Rep2,
- Period2>>::type 
+ Period2>>::type 
 
- operator%(const
+ 
+ operator%(const
 duration<Rep1, Period1>& lhs, const duration<Rep2,
- Period2>& rhs); 
+ Period2>& rhs); 
 
 
 
@@ -15664,423 +15743,392 @@
 template<class charT, class
 traits = char_traits<charT>,
 
- Allocator
- Alloc = allocator<charT> >
+ Allocator
+ Alloc = allocator<charT> >
 
 class basic_string;
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
- basic_string<charT,traits,Alloc>
+ basic_string<charT,traits,Alloc>
 
- operator+(const
- basic_string<charT,traits,Alloc>&
- lhs,
+ operator+(const
+ basic_string<charT,traits,Alloc>&
+ lhs,
 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
+ const
+ basic_string<charT,traits,Alloc>&
+ rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
- basic_string<charT,traits,Alloc>&&
+ basic_string<charT,traits,Alloc>&&
 
- operator+(basic_string<charT,traits,Alloc>&&
- lhs,
+ operator+(basic_string<charT,traits,Alloc>&&
+ lhs,
 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
+ const
+ basic_string<charT,traits,Alloc>&
+ rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
- basic_string<charT,traits,Alloc>&&
+ basic_string<charT,traits,Alloc>&&
 
- operator+(const
- basic_string<charT,traits,Alloc>&
- lhs,
+ operator+(const
+ basic_string<charT,traits,Alloc>&
+ lhs,
 
- basic_string<charT,traits,Alloc>&&
- rhs);
+ basic_string<charT,traits,Alloc>&&
+ rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
- basic_string<charT,traits,Alloc>&&
+ basic_string<charT,traits,Alloc>&&
 
- operator+(basic_string<charT,traits,Alloc>&&
- lhs,
+ operator+(basic_string<charT,traits,Alloc>&&
+ lhs,
 
- basic_string<charT,traits,Alloc>&&
- rhs);
+ basic_string<charT,traits,Alloc>&&
+ rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
- basic_string<charT,traits,Alloc>
+ basic_string<charT,traits,Alloc>
 
 operator+(const charT*
 lhs,
 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
+ const
+ basic_string<charT,traits,Alloc>&
+ rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
- basic_string<charT,traits,Alloc>&&
+ basic_string<charT,traits,Alloc>&&
 
 operator+(const charT*
 lhs,
 
- basic_string<charT,traits,Alloc>&&
- rhs);
+ basic_string<charT,traits,Alloc>&&
+ rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
- basic_string<charT,traits,Alloc>
+ basic_string<charT,traits,Alloc>
 
- operator+(charT
- lhs, const basic_string<charT,traits,Alloc>&
- rhs);
+ operator+(charT
+ lhs, const basic_string<charT,traits,Alloc>&
+ rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
- basic_string<charT,traits,Alloc>&&
+ basic_string<charT,traits,Alloc>&&
 
- operator+(charT
- lhs, basic_string<charT,traits,Alloc>&&
- rhs);
+ operator+(charT
+ lhs, basic_string<charT,traits,Alloc>&&
+ rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
- basic_string<charT,traits,Alloc>
+ basic_string<charT,traits,Alloc>
 
- operator+(const
- basic_string<charT,traits,Alloc>&
- lhs,
+ operator+(const
+ basic_string<charT,traits,Alloc>&
+ lhs,
 
 const charT*
 rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
- basic_string<charT,traits,Alloc>&&
+ basic_string<charT,traits,Alloc>&&
 
- operator+(basic_string<charT,traits,Alloc>&&
- lhs,
+ operator+(basic_string<charT,traits,Alloc>&&
+ lhs,
 
 const charT*
 rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
- basic_string<charT,traits,Alloc>
+ basic_string<charT,traits,Alloc>
 
- operator+(const
- basic_string<charT,traits,Alloc>&
- lhs, charT rhs);
+ operator+(const
+ basic_string<charT,traits,Alloc>&
+ lhs, charT rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
- basic_string<charT,traits,Alloc>&&
+ basic_string<charT,traits,Alloc>&&
 
- operator+(basic_string<charT,traits,Alloc>&&
- lhs, charT rhs);
+ operator+(basic_string<charT,traits,Alloc>&&
+ lhs, charT rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
- bool
- operator==(const basic_string<charT,traits,Alloc>&
- lhs,
+ bool
+ operator==(const basic_string<charT,traits,Alloc>&
+ lhs,
 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
+ const
+ basic_string<charT,traits,Alloc>&
+ rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
 bool operator==(const charT*
 lhs,
 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
+ const
+ basic_string<charT,traits,Alloc>&
+ rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
- bool
- operator==(const basic_string<charT,traits,Alloc>&
- lhs,
+ bool
+ operator==(const basic_string<charT,traits,Alloc>&
+ lhs,
 
 const charT*
 rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
- bool
- operator!=(const basic_string<charT,traits,Alloc>&
- lhs,
+ bool
+ operator!=(const basic_string<charT,traits,Alloc>&
+ lhs,
 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
+ const
+ basic_string<charT,traits,Alloc>&
+ rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
 bool operator!=(const charT*
 lhs,
 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
+ const
+ basic_string<charT,traits,Alloc>&
+ rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
- bool
- operator!=(const basic_string<charT,traits,Alloc>&
- lhs,
+ bool
+ operator!=(const basic_string<charT,traits,Alloc>&
+ lhs,
 
 const charT*
 rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
- bool
- operator< (const basic_string<charT,traits,Alloc>&
- lhs,
+ bool
+ operator< (const basic_string<charT,traits,Alloc>&
+ lhs,
 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
+ const
+ basic_string<charT,traits,Alloc>&
+ rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
- bool
- operator< (const basic_string<charT,traits,Alloc>&
- lhs,
+ bool
+ operator< (const basic_string<charT,traits,Alloc>&
+ lhs,
 
 const charT*
 rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
 bool operator< (const
 charT* lhs,
 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
+ const
+ basic_string<charT,traits,Alloc>&
+ rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
- bool
- operator> (const basic_string<charT,traits,Alloc>&
- lhs,
+ bool
+ operator> (const basic_string<charT,traits,Alloc>&
+ lhs,
 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
+ const
+ basic_string<charT,traits,Alloc>&
+ rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
- bool
- operator> (const basic_string<charT,traits,Alloc>&
- lhs,
+ bool
+ operator> (const basic_string<charT,traits,Alloc>&
+ lhs,
 
 const charT*
 rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
 bool operator> (const
 charT* lhs,
 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
+ const
+ basic_string<charT,traits,Alloc>&
+ rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
- bool
- operator<=(const basic_string<charT,traits,Alloc>&
- lhs,
+ bool
+ operator<=(const basic_string<charT,traits,Alloc>&
+ lhs,
 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
+ const
+ basic_string<charT,traits,Alloc>&
+ rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
- bool
- operator<=(const basic_string<charT,traits,Alloc>&
- lhs,
+ bool
+ operator<=(const basic_string<charT,traits,Alloc>&
+ lhs,
 
 const charT*
 rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
 bool operator<=(const
 charT* lhs,
 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
+ const
+ basic_string<charT,traits,Alloc>&
+ rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
- bool
- operator>=(const basic_string<charT,traits,Alloc>&
- lhs,
+ bool
+ operator>=(const basic_string<charT,traits,Alloc>&
+ lhs,
 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
+ const
+ basic_string<charT,traits,Alloc>&
+ rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
- bool
- operator>=(const basic_string<charT,traits,Alloc>&
- lhs,
+ bool
+ operator>=(const basic_string<charT,traits,Alloc>&
+ lhs,
 
 const charT*
 rhs);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
 bool operator>=(const
 charT* lhs,
 
- const
- basic_string<charT,traits,Alloc>&
- rhs);
+ const
+ basic_string<charT,traits,Alloc>&
+ rhs);
 
  
 
 // 21.3.8.8: swap
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
 void
 swap(basic_string<charT,traits,Alloc>& lhs,
@@ -16090,9 +16138,8 @@
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
 void
 swap(basic_string<charT,traits,Alloc>&& lhs,
@@ -16102,9 +16149,8 @@
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
 void
 swap(basic_string<charT,traits,Alloc>& lhs,
@@ -16117,23 +16163,21 @@
 // 21.3.8.9: inserters and
 extractors
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
 basic_istream<charT,traits>&
 
 operator>>(basic_istream<charT,traits>&&
 is,
 
- basic_string<charT,traits,Alloc>&
- str);
+ basic_string<charT,traits,Alloc>&
+ str);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
 basic_ostream<charT,
 traits>&
@@ -16141,39 +16185,37 @@
 operator<<(basic_ostream<charT,
 traits>&& os,
 
- const
- basic_string<charT,traits,Alloc>&
- str);
+ const
+ basic_string<charT,traits,Alloc>&
+ str);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
 basic_istream<charT,traits>&
 
 getline(basic_istream<charT,traits>&&
 is,
 
- basic_string<charT,traits,Alloc>&
- str,
+ basic_string<charT,traits,Alloc>&
+ str,
 
 charT delim);
 
  
 
- template<class
- charT, class traits, Allocator
- Alloc>
+ template<class
+ charT, class traits, Allocator Alloc>
 
 basic_istream<charT,traits>&
 
 getline(basic_istream<charT,traits>&&
 is,
 
- basic_string<charT,traits,Alloc>&
- str);
+ basic_string<charT,traits,Alloc>&
+ str);
 
  
 
@@ -16188,9 +16230,9 @@
 template<class charT,
 class traits = char_traits<charT>,
 
- Allocator
- Alloc =
- allocator<charT> >
+ Allocator
+ Alloc =
+ allocator<charT> >
 
 class basic_string {
 
@@ -16203,33 +16245,32 @@
 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 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
@@ -16252,9 +16293,9 @@
 // 21.3.2
 construct/copy/destroy:
 
- explicit
- basic_string(const Alloc&
- a = Alloc());
+ explicit
+ basic_string(const Alloc&
+ a = Alloc());
 
 basic_string(const
 basic_string& str);
@@ -16265,44 +16306,41 @@
 basic_string(const
 basic_string& str, size_type pos, size_type n = npos,
 
- const
- Alloc&
- a = Alloc());
+ 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());
+ 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,
 
- basic_string(const
- basic_string&, const Alloc&);
+ const Alloc&
+ a = Alloc());
 
- basic_string(basic_string&&,
- const Alloc&);
+ basic_string(initializer_list<charT>,
+ const Alloc&
+ = Alloc());
+ 
+ basic_string(const
+ basic_string&, const Alloc&);
+ 
+ basic_string(basic_string&&,
+ const Alloc&);
 
 ~basic_string();
 
@@ -16365,13 +16403,12 @@
 basic_string&
 append(size_type n, charT c);
 
- template<InputIterator
- Iter>
+ template<InputIterator Iter>
 
- basic_string&
- append(Iter
- first, Iter
- last);
+ basic_string&
+ append(Iter
+ first, Iter
+ last);
 
 basic_string&
 append(initializer_list<charT>);
@@ -16401,13 +16438,12 @@
 basic_string&
 assign(size_type n, charT c);
 
- template<InputIterator
- Iter>
+ template<InputIterator Iter>
 
- basic_string&
- assign(Iter
- first, Iter
- last);
+ basic_string&
+ assign(Iter
+ first, Iter
+ last);
 
 basic_string&
 assign(initializer_list<charT>);
@@ -16438,13 +16474,12 @@
 void insert(const_iterator
 p, size_type n, charT c);
 
- template<InputIterator
- Iter>
+ template<InputIterator Iter>
 
- void
- insert(const_iterator p, Iter
- first, Iter
- last);
+ void
+ insert(const_iterator p, Iter
+ first, Iter
+ last);
 
 void insert(const_iterator
 p, initializer_list<charT>);
@@ -16504,15 +16539,14 @@
 size_type
 n, charT c);
 
- template<InputIterator
- Iter>
+ template<InputIterator Iter>
 
 basic_string&
 replace(iterator i1, iterator i2,
 
- Iter
- j1, Iter
- j2);
+ Iter
+ j1, Iter
+ j2);
 
 basic_string&
 replace(iterator, iterator, initializer_list<charT>);
@@ -16529,16 +16563,15 @@
 
  
 
- template
- <class charT, class traits, Allocator
- Alloc>
+ template
+ <class charT, class traits, Allocator Alloc>
 
 struct
 constructible_with_allocator_suffix<
 
- basic_string<charT,
- traits, Alloc>
- > : true_type { };
+ basic_string<charT,
+ traits, Alloc>
+ > : true_type { };
 
 
 
@@ -16618,9 +16651,9 @@
 
 
 
- template<class
- charT, CharTraits
- traits = char_traits<charT>,
+ template<class
+ charT, CharTraits
+ traits = char_traits<charT>,
 
 class Allocator =
 allocator<charT> >
@@ -16778,24 +16811,26 @@
 33
 </TD>
 <TD WIDTH=77>
- 22.1.1
- [locale]
+ 22.1.1
+ [locale]
 </TD>
 <TD WIDTH=69>
 3
 </TD>
 <TD WIDTH=33>
- ed
+ ed
 </TD>
 <TD WIDTH=307>
- ios_base::iostate
- err = 0;
+ 
+ ios_base::iostate
+ err = 0;
 
 
- iostate
- is a bitmask type and so could be an enumeration. Probably using
- goodbit
- is the solution.
+ 
+ iostate
+ is a bitmask type and so could be an enumeration. Probably using
+ goodbit
+ is the solution.
 </TD>
 <TD WIDTH=270>
 
@@ -16823,13 +16858,12 @@
 </TD>
 <TD WIDTH=307>
 
- codecvt
- does not use concept.
- For example, create
- CodeConvert concept and change as follows.
+ codecvt
+ does not use concept. For example, create
+ CodeConvert concept and change as follows.
 
- template<CodeConvert
- Codecvt, class Elem = wchar_t> class wstring_convert {
+ template<CodeConvert
+ Codecvt, class Elem = wchar_t> class wstring_convert {
 </TD>
 <TD WIDTH=270>
 
@@ -16882,28 +16916,28 @@
 
  
 
- template<class
- Codecvt, class Elem = wchar_t,
+ template<class
+ Codecvt, class Elem = wchar_t,
 
- Allocator
- WideAllocator = allocator<Elem>,
+ Allocator
+ WideAllocator = allocator<Elem>,
 
- Allocator
- ByteAllocator = allocator<char>>
+ Allocator
+ ByteAllocator = allocator<char>>
 
 class wstring_convert {
 
 public:
 
- typedef
- std::basic_string<char, char_traits<char>,
- ByteAllocator>
- byte_string;
+ typedef
+ std::basic_string<char, char_traits<char>,
+ ByteAllocator>
+ byte_string;
 
- typedef
- std::basic_string<Elem, char_traits<Elem>,
- WideAllocator>
- wide_string;
+ typedef
+ std::basic_string<Elem, char_traits<Elem>,
+ WideAllocator>
+ wide_string;
 
 
 
@@ -17172,10 +17206,10 @@
 
  
 
- template
- <class charT, InputIterator
- InputIter =
- istreambuf_iterator<charT> >
+ template
+ <class charT, InputIterator
+ InputIter =
+ istreambuf_iterator<charT> >
 
 class time_get : public
 locale::facet, public time_base {
@@ -17185,9 +17219,8 @@
 typedef charT
 char_type;
 
- typedef
- InputIter
- iter_type;
+ typedef InputIter
+ iter_type;
 
  
 
@@ -17217,10 +17250,10 @@
 
  
 
- template
- <class charT, InputIterator
- InputIter =
- istreambuf_iterator<charT> >
+ template
+ <class charT, InputIterator
+ InputIter =
+ istreambuf_iterator<charT> >
 
 class time_get_byname : public
 time_get<charT, InputIter> {
@@ -17230,9 +17263,8 @@
 typedef time_base::dateorder
 dateorder;
 
- typedef
- InputIter
- iter_type;
+ typedef InputIter
+ iter_type;
 
  
 
@@ -17266,9 +17298,9 @@
 
 template <class charT,
 
- InputIterator
- InputIter =
- istreambuf_iterator<charT> >
+ InputIterator
+ InputIter =
+ istreambuf_iterator<charT> >
 
 class money_get : public
 locale::facet {
@@ -17278,9 +17310,9 @@
 typedef charT
 char_type;
 
- typedef
- InputIter
- iter_type; 
+ typedef InputIter
+ iter_type;
+ 
 
 
 
@@ -17324,8 +17356,8 @@
 template <class charT,
 class OutputIterator = ostreambuf_iterator<charT> >
 
- class
- time_put : public locale::facet {
+ class
+ time_put : public locale::facet {
 
 public:
 
@@ -17337,27 +17369,26 @@
 
  
 
- 　should
+ 　should
 be
 
  
 
- template
- <class charT, OutputIterator
- OutputIter =
- ostreambuf_iterator<charT> >
+ template
+ <class charT, OutputIterator
+ OutputIter =
+ ostreambuf_iterator<charT> >
 
 class time_put : public
 locale::facet {
 
 public:
 
- typedef
- charT char_type;
+ typedef
+ charT char_type;
 
- typedef
- OutputIter
- iter_type;
+ typedef OutputIter
+ iter_type;
 
  
 
@@ -17389,10 +17420,10 @@
 
  
 
- template
- <class charT, OutputIterator
- OutputIter =
- ostreambuf_iterator<charT> >
+ template
+ <class charT, OutputIterator
+ OutputIter =
+ ostreambuf_iterator<charT> >
 
 class time_put_byname : public
 time_put<charT, OutputIter>
@@ -17403,9 +17434,8 @@
 
 typedef charT
 char_type;
- typedef
- OutputIter
- iter_type;
+ typedef OutputIter
+ iter_type;
 </TD>
 <TD WIDTH=157>
 
@@ -17551,7 +17581,7 @@
 <TD WIDTH=270>
 
 Change
- to … models the MinimalAllocator concept.
+ to … models the MinimalAllocator concept.
 </TD>
 <TD WIDTH=157>
 
@@ -18235,9 +18265,9 @@
 
 Typo, duplicated "to"
 
- "to
- to model insertion
- container concepts."
+ "to
+ to model insertion
+ container concepts."
 </TD>
 <TD WIDTH=270>
 
@@ -19030,7 +19060,7 @@
 249
 </TD>
 <TD WIDTH=77>
- 24.1.6
+ 24.1.6
 </TD>
 <TD WIDTH=69>
 2
@@ -19984,8 +20014,8 @@
 
 Typo.
 
- "intializing"
- should be "initializing"
+ "intializing"
+ should be "initializing"
 </TD>
 <TD WIDTH=270>
 
@@ -20260,20 +20290,21 @@
 34
 </TD>
 <TD WIDTH=77>
- 24.5.3
- [istreambuf.iterator]
+ 24.5.3
+ [istreambuf.iterator]
 </TD>
 <TD WIDTH=69>
 
 
 </TD>
 <TD WIDTH=33>
- ed
+ ed
 </TD>
 <TD WIDTH=307>
- There
+ 
+ There
 are two public sections, and the content of the second one is
- indented with respect to the first. I don't it should be.
+ indented with respect to the first. I don't it should be.
 
 
 </TD>
@@ -20829,21 +20860,22 @@
 35
 </TD>
 <TD WIDTH=77>
- 26.3
- [Complex numbers]
+ 26.3
+ [Complex numbers]
 </TD>
 <TD WIDTH=69>
 
 
 </TD>
 <TD WIDTH=33>
- te
+ te
 </TD>
 <TD WIDTH=307>
- Instantiations
+ 
+ Instantiations
 of the class template complex<> have to be allowed for
 integral types, to reflect existing practice and ISO standards
- (LIA-III).
+ (LIA-III).
 
 
 </TD>
@@ -20934,7 +20966,7 @@
 
 Add the following constructer.
 
- discrete_distribution(initializer_list<result_type>);
+ discrete_distribution(initializer_list<result_type>);
 </TD>
 <TD WIDTH=157>
 
@@ -21055,8 +21087,8 @@
 </TD>
 <TD WIDTH=307>
 
- iostreams
- library cannot be used from constrained templates
+ iostreams
+ library cannot be used from constrained templates
 
 
 </TD>
@@ -21088,7 +21120,7 @@
 <TD WIDTH=307>
 
 Switch from
- “unspecified-bool-type” to　“explicit
+ “unspecified-bool-type” to　“explicit
 operator bool() const”.
 
 
@@ -21096,9 +21128,9 @@
 </TD>
 <TD WIDTH=270>
 
- Replace
- "operator unspecified-bool-type()
- const;" with "explicit operator bool() const;"
+ Replace
+ "operator unspecified-bool-type()
+ const;" with "explicit operator bool() const;"
 </TD>
 <TD WIDTH=157>
 
@@ -21123,7 +21155,7 @@
 <TD WIDTH=307>
 
 Switch from
- “unspecified-bool-type” to　“explicit
+ “unspecified-bool-type” to　“explicit
 operator bool() const”
 
 
@@ -21131,9 +21163,9 @@
 </TD>
 <TD WIDTH=270>
 
- Replace
- "operator unspecified-bool-type()
- const;" with "explicit operator bool() const;"
+ Replace
+ "operator unspecified-bool-type()
+ const;" with "explicit operator bool() const;"
 </TD>
 <TD WIDTH=157>
 
@@ -21146,25 +21178,29 @@
 36
 </TD>
 <TD WIDTH=77>
- 27.6.1.2.2
- [istream.formatted.arithmetic]
+ 
+ 27.6.1.2.2
+ [istream.formatted.arithmetic]
 </TD>
 <TD WIDTH=69>
 1,
 2, and 3
 </TD>
 <TD WIDTH=33>
- ed
+ ed
 </TD>
 <TD WIDTH=307>
- iostate
- err = 0;
+ 
+ iostate
+ err = 0;
 
 
- iostate
- is a bitmask type and so could be an enumeration. Probably using
- goodbit
- is the solution.
+ 
+ iostate
+ is a bitmask type and so could be an enumeration. Probably using
+ 
+ goodbit
+ is the solution.
 
 
 </TD>
@@ -21183,24 +21219,27 @@
 37
 </TD>
 <TD WIDTH=77>
- 27.6.1.2.2
- [istream.formatted.arithmetic]
+ 27.6.1.2.2
+ [istream.formatted.arithmetic]
 </TD>
 <TD WIDTH=69>
 3
 </TD>
 <TD WIDTH=33>
- ed
+ ed
 </TD>
 <TD WIDTH=307>
- else
- if (lval < numeric_limits<int>::min()
- ||
- numeric_limits<int>::max() < lval))
+ 
+ else
+ if (lval < numeric_limits<int>::min()
+ 
+ ||
+ numeric_limits<int>::max() < lval))
 
 
- The
- parentheses aren't balanced.
+ 
+ The
+ parentheses aren't balanced.
 
 
 </TD>
@@ -21248,9 +21287,9 @@
 template <class charT,
 class traits = char_traits<charT>,
 
- Allocator
- Alloc =
- allocator<charT> >
+ Allocator
+ Alloc =
+ allocator<charT> >
 
 class basic_stringbuf :
 public basic_streambuf<charT,traits> {
@@ -21272,9 +21311,9 @@
 
 explicit basic_stringbuf
 
- (const
- basic_string<charT,traits,Alloc>&
- str,
+ (const
+ basic_string<charT,traits,Alloc>&
+ str,
 
 ios_base::openmode which
 = ios_base::in | ios_base::out);
@@ -21293,12 +21332,12 @@
 
 // 27.7.1.3 Get and set:
 
- basic_string<charT,traits,Alloc>
- str() const;
+ basic_string<charT,traits,Alloc>
+ str() const;
 
- void
- str(const basic_string<charT,traits,Alloc>&
- s);
+ void
+ str(const basic_string<charT,traits,Alloc>&
+ s);
 
  
 
@@ -21309,41 +21348,41 @@

 
 
- template
- <class charT, class traits, Allocator
- Alloc>
+ template
+ <class charT, class traits, Allocator
+ Alloc>
 
- void
- swap(basic_stringbuf<charT, traits, Alloc>&
- x,
- 
- basic_stringbuf<charT,
- traits, Alloc>&
- y);
+ void
+ swap(basic_stringbuf<charT, traits, Alloc>&
+ x,
 
- template
- <class charT, class traits, Allocator
- Alloc>
+ 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);
+ void
+ swap(basic_stringbuf<charT, traits, Alloc>&&
+ x,
 
- template
- <class charT, class traits, Allocator
- Alloc>
+ 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);
+ void
+ swap(basic_stringbuf<charT, traits, Alloc>&
+ x,
+ 
+ basic_stringbuf<charT,
+ traits, Alloc>&&
+ y);
 
 }
 
@@ -21389,9 +21428,9 @@
 template <class charT,
 class traits = char_traits<charT>,
 
- Allocator
- Alloc =
- allocator<charT> >
+ Allocator
+ Alloc =
+ allocator<charT> >
 
 class basic_istringstream :
 public basic_istream<charT,traits> {
@@ -21413,9 +21452,8 @@
 typedef traits
 traits_type;
 
- typedef
- Alloc
- allocator_type;
+ typedef Alloc
+ allocator_type;
 
 
 
@@ -21428,9 +21466,9 @@
 explicit
 basic_istringstream(
 
- const
- basic_string<charT,traits,Alloc>&
- str,
+ const
+ basic_string<charT,traits,Alloc>&
+ str,
 
 ios_base::openmode
 which = ios_base::in);
@@ -21454,65 +21492,65 @@
 
 // 27.7.2.3 Members:
 
- basic_stringbuf<charT,traits,Alloc>*
- rdbuf() const;
+ basic_stringbuf<charT,traits,Alloc>*
+ rdbuf() const;
 
  
 
- basic_string<charT,traits,Alloc>
- str() const;
+ basic_string<charT,traits,Alloc>
+ str() const;
 
- void
- str(const basic_string<charT,traits,Alloc>&
- s);
+ void
+ str(const basic_string<charT,traits,Alloc>&
+ s);
 
  
 
 private:
 
- //
- basic_stringbuf<charT,traits,Alloc>
- sb; exposition only
+ //
+ basic_stringbuf<charT,traits,Alloc>
+ sb; exposition only
 
 };
 
  
 
- template
- <class charT, class traits, Allocator
- Alloc>
+ template
+ <class charT, class traits, Allocator
+ Alloc>
 
- void
- swap(basic_istringstream<charT, traits, Alloc>&
- x,
- 
- basic_istringstream<charT,
- traits, Alloc>&
- y);
+ void
+ swap(basic_istringstream<charT, traits, Alloc>&
+ x,
 
- template
- <class charT, class traits, Allocator
- Alloc>
+ basic_istringstream<charT,
+ traits, Alloc>&
+ y);
+ 
+ template
+ <class charT, class traits, Allocator
+ Alloc>
+ 
+ void
+ swap(basic_istringstream<charT, traits, Alloc>&&
+ x,
 
- void
- swap(basic_istringstream<charT, traits, Alloc>&&
- x,
- 
- basic_istringstream<charT,
- traits, Alloc>&
- y);
+ basic_istringstream<charT,
+ traits, Alloc>&
+ y);
+ 
+ template
+ <class charT, class traits, Allocator
+ Alloc>
 
- template
- <class charT, class traits, Allocator
- Alloc>
+ void
+ swap(basic_istringstream<charT, traits, Alloc>&
+ x,
 
- void
- swap(basic_istringstream<charT, traits, Alloc>&
- x,
- 
- basic_istringstream<charT,
- traits, Alloc>&&
- y);
+ basic_istringstream<charT,
+ traits, Alloc>&&
+ y);
 
 }
 
@@ -21558,9 +21596,9 @@
 template <class charT,
 class traits = char_traits<charT>,
 
- Allocator
- Alloc =
- allocator<charT> >
+ Allocator
+ Alloc =
+ allocator<charT> >
 
 class basic_ostringstream :
 public basic_ostream<charT,traits> {
@@ -21584,9 +21622,8 @@
 typedef traits
 traits_type;
 
- typedef
- Alloc
- allocator_type;
+ typedef Alloc
+ allocator_type;
 
  
 
@@ -21599,9 +21636,9 @@
 explicit
 basic_ostringstream(
 
- const
- basic_string<charT,traits,Alloc>&
- str,
+ const
+ basic_string<charT,traits,Alloc>&
+ str,
 
 ios_base::openmode
 which = ios_base::out);
@@ -21623,61 +21660,61 @@
 
 // 27.7.3.3 Members:
 
- basic_stringbuf<charT,traits,Alloc>*
- rdbuf() const;
+ basic_stringbuf<charT,traits,Alloc>*
+ rdbuf() const;
 
- basic_string<charT,traits,Alloc>
- str() const;
+ basic_string<charT,traits,Alloc>
+ str() const;
 
- void
- str(const basic_string<charT,traits,Alloc>&
- s);
+ void
+ str(const basic_string<charT,traits,Alloc>&
+ s);
 
 private:
 
- //
- basic_stringbuf<charT,traits,Alloc>
- sb; exposition only
+ //
+ basic_stringbuf<charT,traits,Alloc>
+ sb; exposition only
 
 };
 
  
 
 template
- <class charT, class traits, Allocator
- Alloc>
+ <class charT, class traits, Allocator
+ Alloc>
 
- void
- swap(basic_ostringstream<charT, traits, Alloc>&
- x,
- 
- basic_ostringstream<charT,
- traits, Alloc>&
- y);
+ void
+ swap(basic_ostringstream<charT, traits, Alloc>&
+ x,
+ 
+ basic_ostringstream<charT,
+ traits, Alloc>&
+ y);
 
 template
- <class charT, class traits, Allocator
- Alloc>
+ <class charT, class traits, Allocator
+ Alloc>
+ 
+ void
+ swap(basic_ostringstream<charT, traits, Alloc>&&
+ x,
 
- void
- swap(basic_ostringstream<charT, traits, Alloc>&&
- x,
- 
- basic_ostringstream<charT,
- traits, Alloc>&
- y);
+ basic_ostringstream<charT,
+ traits, Alloc>&
+ y);
+ 
+ template
+ <class charT, class traits, Allocator
+ Alloc>
 
- template
- <class charT, class traits, Allocator
- Alloc>
+ void
+ swap(basic_ostringstream<charT, traits, Alloc>&
+ x,
 
- void
- swap(basic_ostringstream<charT, traits, Alloc>&
- x,
- 
- basic_ostringstream<charT,
- traits, Alloc>&&
- y);
+ basic_ostringstream<charT,
+ traits, Alloc>&&
+ y);
 
 }
 
@@ -21725,9 +21762,9 @@
 
 
 
- 27.7.3
- Class template
- basic_ostringstream
+ 27.7.3
+ Class template
+ basic_ostringstream
 </TD>
 <TD WIDTH=157>
 
@@ -21768,9 +21805,9 @@
 template <class charT,
 class traits = char_traits<charT>,
 
- Allocator
- Alloc =
- allocator<charT> >
+ Allocator
+ Alloc =
+ allocator<charT> >
 
 class basic_stringstream
 
@@ -21796,9 +21833,8 @@
 typedef traits
 traits_type;
 
- typedef
- Alloc
- allocator_type;
+ typedef Alloc
+ allocator_type;
 
  
 
@@ -21813,9 +21849,9 @@
 explicit
 basic_stringstream(
 
- const
- basic_string<charT,traits,Alloc>&
- str,
+ const
+ basic_string<charT,traits,Alloc>&
+ str,
 
 ios_base::openmode which =
 ios_base::out|ios_base::in);
@@ -21834,15 +21870,15 @@
 
 // Members:
 
- basic_stringbuf<charT,traits,Alloc>*
- rdbuf() const;
+ basic_stringbuf<charT,traits,Alloc>*
+ rdbuf() const;
 
- basic_string<charT,traits,Alloc>
- str() const;
+ basic_string<charT,traits,Alloc>
+ str() const;
 
- void
- str(const basic_string<charT,traits,Alloc>&
- str);
+ void
+ str(const basic_string<charT,traits,Alloc>&
+ str);
 
 private:
 
@@ -21853,41 +21889,41 @@
 
  
 
- template
- <class charT, class traits, Allocator
- Alloc>
+ template
+ <class charT, class traits, Allocator
+ Alloc>
 
- void
- swap(basic_stringstream<charT, traits, Alloc>&
- x,
- 
- basic_stringstream<charT,
- traits, Alloc>&
- y);
+ void
+ swap(basic_stringstream<charT, traits, Alloc>&
+ x,
+ 
+ basic_stringstream<charT,
+ traits, Alloc>&
+ y);
 
 template
- <class charT, class traits, Allocator
- Alloc>
+ <class charT, class traits, Allocator
+ Alloc>
+ 
+ void
+ swap(basic_stringstream<charT, traits, Alloc>&&
+ x,
 
- void
- swap(basic_stringstream<charT, traits, Alloc>&&
- x,
- 
- basic_stringstream<charT,
- traits, Alloc>&
- y);
+ basic_stringstream<charT,
+ traits, Alloc>&
+ y);
 
 template
- <class charT, class traits, Allocator
- Alloc>
+ <class charT, class traits, Allocator
+ Alloc>
+ 
+ void
+ swap(basic_stringstream<charT, traits, Alloc>&
+ x,
 
- void
- swap(basic_stringstream<charT, traits, Alloc>&
- x,
- 
- basic_stringstream<charT,
- traits, Alloc>&&
- y);
+ basic_stringstream<charT,
+ traits, Alloc>&&
+ y);
 
 }
 </TD>
@@ -22410,8 +22446,8 @@
 
 namespace std {
 
- typedef
- enum memory_order {
+ typedef
+ enum memory_order {
 
 memory_order_relaxed,
 memory_order_consume, memory_order_acquire,
@@ -22455,8 +22491,8 @@
 
 namespace std {
 
- typedef
- struct atomic_bool {
+ typedef
+ struct atomic_bool {
 
 ...
 
@@ -22487,14 +22523,14 @@
 
 namespace std {
 
- typedef
- struct atomic_itype
- {
+ typedef
+ struct atomic_itype
+ {
 
 ...
 
- }
- atomic_itype;
+ }
+ atomic_itype;
 
 }
 
@@ -22508,9 +22544,9 @@
 
 namespace std {
 
- struct
- atomic_itype
- {
+ struct
+ atomic_itype
+ {
 
 ...
 
@@ -22528,8 +22564,8 @@
 
 namespace std {
 
- typedef
- struct atomic_address {
+ typedef
+ struct atomic_address {
 
 ...
 
@@ -22565,8 +22601,8 @@
 
 namespace std {
 
- typedef
- struct atomic_flag {
+ typedef
+ struct atomic_flag {
 
 ...
 
@@ -22814,21 +22850,21 @@
 </TD>
 <TD WIDTH=307>
 
- A
- description for "Throws:
- Nothing." are
- not unified.
- 
- At
- the part without throw, "Throws:
- Nothing."
- should be described.
+ A
+ description for "Throws:
+ Nothing." are
+ not unified.
+ 
+ At
+ the part without throw, "Throws:
+ Nothing."
+ should be described.
 </TD>
 <TD WIDTH=270>
 
- Add
- "Throws:
- Nothing." to the following.
+ Add
+ "Throws:
+ Nothing." to the following.
 
 30.2.1.6
 , 1st
@@ -23018,20 +23054,19 @@
 </TD>
 <TD WIDTH=270>
 
- 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: 
+ Several
+ classes described in this Clause have a member native_handle
+ (of type native_handle_type)
+ . The
+ 
+ presence
+ of this member and its semantics is implementation defined. [ Note:
 This member allows implementations to provide access to
 implementation details. The name of the member and the type are
 specified to facilitate portable compile-time detection. Actual
 use of this member or the corresponding type is inherently
- non-portable. —end
- note ]
+ non-portable. —end
+ note ]
 
 
 </TD>
@@ -23060,12 +23095,12 @@
 </TD>
 <TD WIDTH=270>
 
- Implementations
- should use a monotonic
- clock to measure
+ 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.
+ jumps.
 
 
 </TD>
@@ -23197,11 +23232,11 @@
 </TD>
 <TD WIDTH=307>
 
- "CopyConstructible"
- and "MoveConstructible" in "Requires:
- F and each Ti in
+ "CopyConstructible"
+ and "MoveConstructible" in "Requires:
+ F and each Ti in
 Args shall be CopyConstructible if an lvalue and otherwise
- MoveConstructible." are reflected by interface.
+ MoveConstructible." are reflected by interface.
 
 
 
@@ -24145,8 +24180,8 @@
 
 template <class F>
 
- requires
- CopyConstructible<F> && Callable<F, ArgTypes...>
+ requires
+ CopyConstructible<F> && Callable<F, ArgTypes...>
 
 &&
 Convertible<Callable<F, ArgTypes...>::result_type, R>
@@ -24155,26 +24190,26 @@
 
  
 
- template
- <class F, Allocator
- Alloc>
+ template
+ <class F, Allocator
+ Alloc>
 
- requires
- CopyConstructible<F> && Callable<F, ArgTypes...>
+ requires
+ CopyConstructible<F> && Callable<F, ArgTypes...>
 
 &&
 Convertible<Callable<F, ArgTypes...>::result_type, R>
 
- explicit
- packaged_task(allocator_arg_t, const Alloc&
- a, F f);
+ explicit
+ packaged_task(allocator_arg_t, const Alloc&
+ a, F f);
 
  
 
 template <class F>
 
- requires
- CopyConstructible<F> && Callable<F, ArgTypes...>
+ requires
+ CopyConstructible<F> && Callable<F, ArgTypes...>
 
 &&
 Convertible<Callable<F, ArgTypes...>::result_type, R>
@@ -24184,19 +24219,19 @@
 
  
 
- template
- <class F, Allocator
- Alloc>
+ template
+ <class F, Allocator
+ Alloc>
 
- requires
- CopyConstructible<F> && Callable<F, ArgTypes...>
+ requires
+ CopyConstructible<F> && Callable<F, ArgTypes...>
 
 &&
 Convertible<Callable<F, ArgTypes...>::result_type, R>
 
- explicit
- packaged_task(allocator_arg_t, const Alloc&
- a, F&& f);
+ explicit
+ packaged_task(allocator_arg_t, const Alloc&
+ a, F&& f);
 
 
 
@@ -24309,29 +24344,33 @@
 38
 </TD>
 <TD WIDTH=77>
- C.2
- [diffs.library]
+ C.2
+ [diffs.library]
 </TD>
 <TD WIDTH=69>
 1
 </TD>
 <TD WIDTH=33>
- ed
+ ed
 </TD>
 <TD WIDTH=307>
- What
- is ISO/IEC 1990:9899/DAM 1? My guess is that's a typo for ISO/IEC
- 9899/Amd.1:1995
- which I'd have expected to be referenced here (the tables
- make
- reference to things which were introduced by Amd.1).
+ 
+ What
+ is ISO/IEC 1990:9899/DAM 1? My guess is that's a typo for ISO/IEC
+ 
+ 9899/Amd.1:1995
+ which I'd have expected to be referenced here (the tables
+ 
+ make
+ reference to things which were introduced by Amd.1).
 
 
 </TD>
 <TD WIDTH=270>
- One
+ 
+ One
 need probably a reference to the document which introduce char16_t
- and
+ and
 char32_t
 in C (ISO/IEC TR 19769:2004?).
 </TD>
@@ -24381,23 +24420,25 @@
 39
 </TD>
 <TD WIDTH=77>
- Index
+ Index
 </TD>
 <TD WIDTH=69>
 
 
 </TD>
 <TD WIDTH=33>
- ed
+ ed
 </TD>
 <TD WIDTH=307>
- Some
- definitions seem not indexed (such as /trivially copyable/ or
- /sequenced
+ 
+ Some
+ definitions seem not indexed (such as /trivially copyable/ or
+ 
+ /sequenced
 before/), indexing them would be useful (and marking specially the
 page -- say bold or italic -- which reference to the definition
 would increase the usefulness; having a separate index of all
- definitions is something which could also be considered).
+ definitions is something which could also be considered).
 
 
 </TD>

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