Boost-Commit mailing page: [Boost-commit] svn:boost r51612 - in sandbox/committee/LWG: . proposals

Date view	Thread view	Subject view	Author view

Subject: [Boost-commit] svn:boost r51612 - in sandbox/committee/LWG: . proposals
From: bdawes_at_[hidden]
Date: 2009-03-04 14:25:44

Next message: ockham_at_[hidden]: "[Boost-commit] svn:boost r51613 - in sandbox/SOC/2006/tree/trunk: boost/tree boost/tree/detail libs/tree/test"
Previous message: john_at_[hidden]: "[Boost-commit] svn:boost r51611 - trunk/libs/math/test"

Author: bemandawes
Date: 2009-03-04 14:25:42 EST (Wed, 04 Mar 2009)
New Revision: 51612
URL: http://svn.boost.org/trac/boost/changeset/51612

Log:
2PM Wednesday. All current sub-group diffs applied.
Removed:
   sandbox/committee/LWG/0xCD1_Comments.html
Text files modified:
   sandbox/committee/LWG/LWG_0xCD1_status.html | 203 ++++++++++++++++++++++++---------------
   sandbox/committee/LWG/proposals/n2636.html | 20 +--
   sandbox/committee/LWG/thread_safety.html | 24 ++--
   3 files changed, 140 insertions(+), 107 deletions(-)

Deleted: sandbox/committee/LWG/0xCD1_Comments.html
==============================================================================
--- sandbox/committee/LWG/0xCD1_Comments.html 2009-03-04 14:25:42 EST (Wed, 04 Mar 2009)
+++ (empty file)
@@ -1,13924 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-
-<meta name="generator" content=
-"Microsoft FrontPage 5.0">
- <meta name="generator" content="Microsoft FrontPage 5.0">
- <meta name="generator" content="Microsoft FrontPage 5.0">
- <meta http-equiv="CONTENT-TYPE" content=
- "text/html; charset=us-ascii">
-
- <title>LWG CD1 Status of Comments</title>
- <meta name="GENERATOR" content="Microsoft FrontPage 5.0">
- <meta name="AUTHOR" content="dow">
- <meta name="CREATED" content="20090221;19590000">
- <meta name="CHANGEDBY" content=" Barry E Hedquist">
- <meta name="CHANGED" content="20090222;18460000">
- <meta name="DESCRIPTION" content="FORM (ISO)">
-<style type="text/css">
- body { font-family: sans-serif; margin: 1em; }
-</style>
-
-<h1>Library Working Group 
-Status of CD1 National Body Comments</h1>
-Revised:
-03 Mar 2009 08:36:37 AM -0500
-
-<table border="1" bordercolor="#000000" cellpadding="7"
- cellspacing="0" style="border-collapse: collapse" width="1628">
-
- <tr valign="top">
- <td width="29">
- MB 
-
- <td width="75">
- Clause No./ 
- Subclause No./ 
- Annex (e.g. 3.1)
-
- <td width="31">
- Para/ 
- Figure/ Table/ Note<td width="38">
- Type 
-
- <td width="375">
- Comment (justification for change) by the MB
-
- <td width="466">
- Proposed change by the MB
-
- <td width="225">
- 
- Disposition
-
- 
-
- <tr valign="top">
- <td width="29">
- US 2
-
- <td width="75">
- 17-30
-
- <td width="31">
- 
-
- <td width="38">
- ge/te
-
- <td width="375">
- The
- active issues identified in WG21 N2806, C++ Standard
- Library Active Issues, must be addressed and appropriate
- action taken.
-
- 
- 
-
- 
- <a href=
- "http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">
- http://www.open-std.org/> 
- <a href=
- "http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">
- jtc1/sc22/wg21/docs/lwg-active.html</a>
-
- 
-
- <td width="466">
- Appropriate action would
- include making changes to the CD, identifying an issue as
- not requiring a change to the CD, or deferring the issue to
- a later point in time.
-
- <td width="225">
- 
-
- Acknowledged<tr valign="top">
- <td width="29">
- FR 2
-
- <td width="75">
- General 
- Comment
-
- <td width="31">
- Library
-
- <td width="38">
- ge
-
- <td width="375">
- The adoption of the library `constexpr' proposal was not
- reflected in the draft, despite formal WG21 committee vote.
-
- <td width="466">
- FR 2
-
- <td width="225">
- Editorial; sent to Pete Becker<tr valign="top">
- <td width="29">
- US 61
-
- <td width="75">
- 17 onward
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- The concepts core language feature is applied to only
- some of the Standard Library clauses, and even then not
- always consistently.
-
- <td width="466">
- Review all
- clauses of the Standard Library, and consistently apply
- concept technology wherever possible and appropriate. The
- proposed wording in WG21 N2781 exemplifies the necessary
- level of detail.
-
- 
-
- <td width="225">
- 
-
- Agreed. Duplicates CA2<tr valign="top">
- <td width="29">
- CA-2
-
- <td width="75">
- 17 Library
-
- <td width="31">
- 
-
- <td width="38">
- Ge
-
- <td width="375">
- 
- “Concepts” are a significant new addition to
- the language, but are not exploited uniformly in the
- library as documented in CD 14882.
-
- <td width="466">
- Fix
- the standard library so that “Concepts” are
- used appropriately in the library.
-
- <td width="225">
- 
-
- Agreed; We intend to address this.<tr valign="top">
- <td width="29">
- US 62
-
- <td width="75">
- 17-30
-
- <td width="31">
- 
-
- <td width="38">
- ge
-
- <td width="375">
- Provide concepts
- and requirements clauses for all standard library templates
-
- 
-
- <td width="466">
- 
-
- <td width="225">
- Agreed. Duplicates CA2 
-
- <tr valign="top">
- <td width="29">
- US 63
-
- <td width="75">
- 17-30
-
- 
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- The behavior of the library in the presence of threads
- is incompletely specified.
-
- For example, if thread 1 assigns to X, then writes data
- to file f, which is read by thread 2, and then accesses
- variable X, is thread 2 guaranteed to be able to see the
- value assigned to X by thread 1? In other words, does the
- write of the data "happen before" the read?
-
- Another example: does simultaneous access using operator
- at() to different characters in the same non-const string
- really introduce a data race?
-
- <td width="466">
- 
-
- <td width="225">
- 
-
- 17 SG: should go to threads group; misclassified in document
-
- Concurrency SG: Create an issue. Hans will look into it.<tr valign="top">
- <td width="29">
- DE-2
-
- <td width="75">
- 17 through 30
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- DE-2 Marking a constructor with "explicit" has semantics
- even for a constructor with zero or several parameters:
- Such a constructor cannot be used with list-initialization
- in a copy-initialization context, see 13.3.1.7. The
- standard library apparently has not been reviewed for
- marking non-single-parameter constructors as "explicit".
-
- <td width="466">
- Consider marking zero-parameter and multi-parameter
- constructors "explicit" in classes that have at least one
- constructor marked "explicit" and that do not have an
- initializer-list constructor.
-
- <td width="225">
- 
-
- Robert Klarer to address this one<tr valign="top">
- <td width="29">
- JP 21
-
- <td width="75">
- 
- 
-
- 17
- Library
-
- 
- 21.2, 21.4,
-
- 27.2, 27.6, 
- 27.7, 
- 27.8.1, 
- 28.4
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- 
- Support of char16_t/char32_t is insufficient. The basic_xxx
- classes of <iostream>, <fstream>,
- <regex>, etc. does not have typedefs for
- char16_t/char32_t.
-
- 
- Functions such as stoi, to_string in ‘21.4 Numeric
- Conversion’ does not support char16_t/char32_t types.
-
- <td width="466">
- Add commented
- lines corresponding to char16_t, char32_t.
-
- 
- 
-
- 
- 21.2 paragraph1
-
- 
-  
-
- 
- namespace std {
-
- 
-  ...
-
- 
-  
-
- 
-  // 21.4: numeric conversions
-
- 
-  ...
-
- 
-  
-
- 
-  int stoi(const u16string& str, size_t *idx = 0,
- int base = 10);
-
- 
-  long stol(const u16string& str, size_t *idx = 0,
- int base = 10);
-
- 
-  unsigned long stoul(const u16string& str, size_t
- *idx = 0, int base = 10);
-
- 
-  long long stoll(const u16string& str, size_t *idx
- = 0, int base = 10);
-
- 
-  unsigned long long stoull(const u16string& str,
- size_t *idx = 0, int base = 10);
-
- 
-  float stof(const u16string& str, size_t *idx =
- 0);
-
- 
-  double stod(const u16string& str, size_t *idx =
- 0);
-
- 
-  long double stold(const u16string& str, size_t
- *idx = 0);
-
- 
-  u16string to_u16string(long long val);
-
- 
-  u16string to_u16string(unsigned long long val);
-
- 
-  u16string to_u16string(long double val);
-
- 
-  
-
- 
-   int stoi(const u32string& str, size_t *idx = 0,
- int base = 10);
-
- 
-  long stol(const u32string& str, size_t *idx = 0,
- int base = 10);
-
- 
-  unsigned long stoul(const u32string& str, size_t
- *idx = 0, int base = 10);
-
- 
-  long long stoll(const u32string& str, size_t *idx
- = 0, int base = 10);
-
- 
-  unsigned long long stoull(const u32string& str,
- size_t *idx = 0, int base = 10);
-
- 
-  float stof(const u32string& str, size_t *idx =
- 0);
-
- 
-  double stod(const u32string& str, size_t *idx =
- 0);
-
- 
-  long double stold(const u32string& str, size_t
- *idx = 0);
-
- 
-  u32string to_u32string(long long val);
-
- 
-  u32string to_u32string(unsigned long long val);
-
- 
-  u32string to_u32string(long double val);
-
- }
-
- 
- 
-
- 
- 27.2
-
- 
-  
-
- 
- namespace std {
-
- 
-  ...
-
- 
-  typedef basic_ios<char> ios;
-
- 
-  typedef basic_ios<wchar_t> wios;
-
- 
-  typedef basic_ios<char16_t> u16ios;
-
- 
-  typedef basic_ios<char32_t> u32ios;
-
- 
-  
-
- 
-  ...
-
- 
-  typedef basic_ifstream<wchar_t> wifstream;
-
- 
-  typedef basic_ofstream<wchar_t> wofstream;
-
- 
-  typedef basic_fstream<wchar_t> wfstream;
-
- 
-  
-
- 
-  typedef basic_streambuf<char16_t> u16streambuf;
-
- 
-  typedef basic_istream<char16_t> u16istream;
-
- 
-  typedef basic_ostream<char16_t> u16ostream;
-
- 
-  typedef basic_iostream<char16_t> u16iostream;
-
- 
-  
-
- 
-  typedef basic_stringbuf<char16_t> u16stringbuf;
-
- 
-  typedef basic_istringstream<char16_t>
- u16istringstream;
-
- 
-  typedef basic_ostringstream<char16_t>
- u16ostringstream;
-
- 
-  typedef basic_stringstream<char16_t>
- u16stringstream;
-
- 
-  typedef basic_filebuf<char16_t> u16filebuf;
-
- 
-  
-
- 
-  typedef basic_ifstream<char16_t> u16ifstream;
-
- 
-  typedef basic_ofstream<char16_t> u16ofstream;
-
- 
-  typedef basic_fstream<char16_t> u16fstream;
-
- 
-  
-
- 
-  typedef basic_streambuf<char32_t> u32streambuf;
-
- 
-  typedef basic_istream<char32_t> u32istream;
-
- 
-  typedef basic_ostream<char32_t> u32ostream;
-
- 
-  typedef basic_iostream<char32_t> u32iostream;
-
- 
-  
-
- 
-  typedef basic_stringbuf<char32_t> u32stringbuf;
-
- 
-  typedef basic_istringstream<char32_t>
- u32istringstream;
-
- 
-  typedef basic_ostringstream<char32_t>
- u32ostringstream;
-
- 
-  typedef basic_stringstream<char32_t>
- u32stringstream;
-
- 
-  typedef basic_filebuf<char32_t> u32filebuf;
-
- 
-  
-
- 
-  typedef basic_ifstream<char32_t> u32ifstream;
-
- 
-  typedef basic_ofstream<char32_t> u32ofstream;
-
- 
-  typedef basic_fstream<char32_t>
- u32fstream;
-
- 
-  
-
- 
-  ...
-
- 
-  template <class state> class fpos;
-
- 
-  typedef
- fpos<char_traits<char>::state_type> streampos;
-
- 
-  typedef
- fpos<char_traits<wchar_t>::state_type>
- wstreampos;
-
- 
-  typedef
- fpos<char_traits<char16_t>::state_type>
- u16streampos;
-
- 
-  typedef
- fpos<char_traits<char32_t>::state_type>
- u32streampos;
-
- }
-
- 
- 
-
- 
- 27.6
-
- 
-  
-
- 
- namespace std {
-
- 
-  template <class charT, class traits =
- char_traits<charT> >
-
- 
-  class basic_istream;
-
- 
-  typedef basic_istream<char> istream;
-
- 
-  typedef basic_istream<wchar_t> wistream;
-
- 
-  typedef basic_istream<char16_t>
- u16istream;
-
- 
-  typedef basic_istream<char32_t> u32istream;
-
- 
-  
-
- 
-  template <class charT, class traits =
- char_traits<charT> >
-
- 
-  class basic_iostream;
-
- 
-  typedef basic_iostream<char> iostream;
-
- 
-  typedef basic_iostream<wchar_t> wiostream;
-
- 
-  typedef basic_iostream<char16_t>
- u16iostream;
-
- 
-  typedef basic_iostream<char32_t> u32iostream;
-
- }
-
- 
-  
-
- 
- namespace std {
-
- 
-  template <class charT, class traits =
- char_traits<charT> >
-
- 
-  class basic_ostream;
-
- 
-  typedef basic_ostream<char> ostream;
-
- 
-  typedef basic_ostream<wchar_t> wostream;
-
- 
-  typedef basic_ostream<char16_t>
- u16ostream;
-
- 
-  typedef basic_ostream<char32_t> u32ostream;
-
- }
-
- 
- 
-
- 
- 27.7 paragraph 1
-
- 
-  
-
- 
- namespace std {
-
- 
-  template <class charT, class traits =
- char_traits<charT>,
-
- 
-      class Allocator =
- allocator<charT> >
-
- 
-  class basic_stringbuf;
-
- 
-  
-
- 
-  typedef basic_stringbuf<char> stringbuf;
-
- 
-  typedef basic_stringbuf<wchar_t> wstringbuf;
-
- 
-  typedef basic_stringbuf<char16_t>
- u16stringbuf;
-
- 
-  typedef basic_stringbuf<char32_t> u32stringbuf;
-
- 
-  
-
- 
-  template <class charT, class traits =
- char_traits<charT>,
-
- 
-      class Allocator =
- allocator<charT> >
-
- 
-  class basic_istringstream;
-
- 
-  
-
- 
-  typedef basic_istringstream<char>
- istringstream;
-
- 
-  typedef basic_istringstream<wchar_t>
- wistringstream;
-
- 
-  typedef basic_istringstream<char16_t>
- u16istringstream;
-
- 
-  typedef basic_istringstream<char32_t>
- u32istringstream;
-
- 
-  
-
- 
-  template <class charT, class traits =
- char_traits<charT>,
-
- 
-      class Allocator =
- allocator<charT> >
-
- 
-  class basic_ostringstream;
-
- 
-  
-
- 
-  typedef basic_ostringstream<char>
- ostringstream;
-
- 
-  typedef basic_ostringstream<wchar_t>
- wostringstream;
-
- 
-  typedef basic_ostringstream<char16_t>
- u16ostringstream;
-
- 
-  typedef basic_ostringstream<char32_t>
- u32ostringstream;
-
- 
-  
-
- 
-  template <class charT, class traits =
- char_traits<charT>,
-
- 
-      class Allocator =
- allocator<charT> >
-
- 
-  class basic_stringstream;
-
- 
-  
-
- 
-  typedef basic_stringstream<char> stringstream;
-
- 
-  typedef basic_stringstream<wchar_t>
- wstringstream;
-
- 
-  typedef basic_stringstream<char16_t>
- u16stringstream;
-
- 
-  typedef basic_stringstream<char32_t>
- u32stringstream;
-
- }
-
- 
- 
-
- 
- 27.8.1 paragraph 1
-
- 
-  
-
- 
- namespace std {
-
- 
-  template <class charT, class traits =
- char_traits<charT> >
-
- 
-  class basic_filebuf;
-
- 
-  typedef basic_filebuf<char> filebuf;
-
- 
-  typedef basic_filebuf<wchar_t> wfilebuf;
-
- 
-  typedef basic_filebuf<char16_t>
- u16filebuf;
-
- 
-  typedef basic_filebuf<char32_t> u32filebuf;
-
- 
-  
-
- 
-  template <class charT, class traits =
- char_traits<charT> >
-
- 
-  class basic_ifstream;
-
- 
-  typedef basic_ifstream<char> ifstream;
-
- 
-  typedef basic_ifstream<wchar_t> wifstream;
-
- 
-  typedef basic_ifstream<char16_t>
- u16ifstream;
-
- 
-  typedef basic_ifstream<char32_t> u32ifstream;
-
- 
-  
-
- 
-  template <class charT, class traits =
- char_traits<charT> >
-
- 
-  class basic_ofstream;
-
- 
-  typedef basic_ofstream<char> ofstream;
-
- 
-  typedef basic_ofstream<wchar_t> wofstream;
-
- 
-  typedef basic_ofstream<char16_t>
- u16ofstream;
-
- 
-  typedef basic_ofstream<char32_t> u32ofstream;
-
- 
-  
-
- 
-  template <class charT, class traits =
- char_traits<charT> >
-
- 
-  class basic_fstream;
-
- 
-  typedef basic_fstream<char> fstream;
-
- 
-  typedef basic_fstream<wchar_t> wfstream;
-
- 
-  typedef basic_fstream<char16_t>
- u16fstream;
-
- 
-  typedef basic_fstream<char32_t> u32fstream;
-
- }
-
- 
- 
-
- 
- 28.4
-
- 
-  
-
- 
- namespace std {
-
- 
-  ...
-
- 
-  typedef basic_regex<char> regex;
-
- 
-  typedef basic_regex<wchar_t> wregex;
-
- 
-  typedef basic_regex<char16_t> u16regex;
-
- 
-  typedef basic_regex<char32_t> u32regex;
-
- 
-  
-
- 
-  ...
-
- 
-  typedef sub_match<const char*> csub_match;
-
- 
-  typedef sub_match<const wchar_t*> wcsub_match;
-
- 
-  typedef sub_match<const char16_t*>
- u16csub_match;
-
- 
-  typedef sub_match<const char32_t*>
- u16csub_match;
-
- 
-  typedef sub_match<string::const_iterator>
- ssub_match;
-
- 
-  typedef sub_match<wstring::const_iterator>
- wssub_match;
-
- 
-  typedef sub_match<u16string::const_iterator>
- u16ssub_match;
-
- 
-  typedef sub_match<u32string::const_iterator>
- u32ssub_match;
-
- 
-  
-
- 
-  ...
-
- 
-  typedef match_results<const char*> cmatch;
-
- 
-  typedef match_results<const wchar_t*> wcmatch;
-
- 
-  typedef match_results<const char16_t*>
- u16cmatch;
-
- 
-  typedef match_results<const char32_t*>
- u32cmatch;
-
- 
-  typedef match_results<string::const_iterator>
- smatch;
-
- 
-  typedef match_results<wstring::const_iterator>
- wsmatch;
-
- 
-  typedef
- match_results<u16string::const_iterator> u16smatch;
-
- 
-  typedef
- match_results<u32string::const_iterator> u32smatch;
-
- 
-  
-
- 
-  ...
-
- 
-  typedef regex_iterator<const char*>
- cregex_iterator;
-
- 
-  typedef regex_iterator<const wchar_t*>
- wcregex_iterator;
-
- 
-  typedef regex_iterator<const cha16r_t*>
- u16cregex_iterator;
-
- 
-  typedef regex_iterator<const char32_t*>
- u32cregex_iterator;
-
- 
-  typedef regex_iterator<string::const_iterator>
- sregex_iterator;
-
- 
-  typedef regex_iterator<wstring::const_iterator>
- wsregex_iterator;
-
- 
-  typedef
- regex_iterator<u16string::const_iterator>
- u16sregex_iterator;
-
- 
-  typedef
- regex_iterator<u32string::const_iterator>
- u32sregex_iterator;
-
- 
-  
-
- 
-  ...
-
- 
-  typedef regex_token_iterator<const char*>
- cregex_token_iterator;
-
- 
-  typedef regex_token_iterator<const wchar_t*>
- wcregex_token_iterator;
-
- 
-  typedef regex_token_iterator<const char16_t*>
- u16cregex_token_iterator;
-
- 
-  typedef regex_token_iterator<const char32_t*>
- u32cregex_token_iterator;
-
- 
-  typedef
- regex_token_iterator<string::const_iterator>
- sregex_token_iterator;
-
- 
-  typedef
- regex_token_iterator<wstring::const_iterator>
- 　　　wsregex_token_iterator;
-
- 
-  typedef
- regex_token_iterator<u16string::const_iterator>
- u16sregex_token_iterator;
-
- 
-  typedef
- regex_token_iterator<u32string::const_iterator>
- 　u32sregex_token_iterator;
-
- }
-
- 
-
- <td width="225">
- 
-
- Previously considered; we decided not to do it. We believe it is not too
- onerous to use wbuffer_convert and wstring_convert which were added as
- intermediaries to avoid proliferation of types.<tr valign="top">
- <td width="29">
- UK 
- 144
-
- <td width="75">
- 17.1
-
- <td width="31">
- 2
-
- <td width="38">
- Ed
-
- <td width="375">
- List of contents of library should be
- extened to cover new clauses
-
- <td width="466">
- Add "regular expressions, atomic operations
- and threads"
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 145
-
- <td width="75">
- 17.1
-
- <td width="31">
- 6
-
- <td width="38">
- Ed
-
- <td width="375">
- 
- Summary of numeric facilities should
- mention random numbers
-
- 
-
- <td width="466">
- Add random number framework to the list of
- library facilities
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 146
-
- <td width="75">
- 17.1
-
- <td width="31">
- 
-
- <td width="38">
- Ed
-
- <td width="375">
- Add a summary paragraph for regular
- expressions
-
- <td width="466">
- Add a summary paragraph for regular
- expressions
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 147
-
- <td width="75">
- 17.1
-
- <td width="31">
- 
-
- <td width="38">
- Ed
-
- <td width="375">
- Add a summary paragraph for threads
-
- <td width="466">
- Add a summary paragraph for threads
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 148
-
- <td width="75">
- 17.2
-
- <td width="31">
- Table 12
-
- <td width="38">
- Ed
-
- <td width="375">
- Table 12 is
- mentioned in and relates to section 17.2, but has been
- pushed down to appear directly after the title of section
- 17.3 which is rather unfortunate/confusing for the reader.
-
- 
-
- <td width="466">
- Make sure tables are rendered in the
- section to which they relate.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 149
-
- <td width="75">
- 17.3
-
- <td width="31">
- 
-
- <td width="38">
- Ed
-
- <td width="375">
- For consistency
- with narrow-oriented and wide-oriented streams, we should
- add terms for streams of Unicode character sequences
-
- 
-
- <td width="466">
- Define Utf16-oriented stream classes and
- Uft32-oriented stream classes for streams of
- char16_t/char32_t values.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 150
-
- <td width="75">
- 17.3
-
- <td width="31">
- 
-
- <td width="38">
- Ed
-
- <td width="375">
- The addition of move semantics to the
- language means that many library APIs leave an object in a
- safely-destructible state, where no other operations can
- safely be performed unless it is assigned a new value.
- Library presentation would be simplified and made more
- precise if we introduce a term for this state. By analogy
- with singular iterators suggest the term 'singular object'
- or 'the object is in a singular state'.
-
- <td width="466">
- Define 'singular
- state' such that an object with a singular state can only
- be assigned to or safely destroyed. Assiging a new value
- typically removes the singular state. Note that objects
- with a singular state may not be safely copied, so you
- cannot put an object into a singular state by copying
- another object in a singular state. Use this new term in
- the postcondition of all library APIs that move from an
- rvalue reference. It might also be used to simplify the
- definition of singular iterator to an iterator value with a
- singular state.
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 151
-
- <td width="75">
- 17.3.1
-
- <td width="31">
- 
-
- <td width="38">
- Ed
-
- <td width="375">
- Missing
- crossreference to 17.3.17 [defns.repositional.stream]
-
- 
-
- <td width="466">
- Add cross-reference in the existing empty
- brackets
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 152
-
- <td width="75">
- 17.3.12
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- Object state is
- using a definition of object (instance of a class) from
- outside the standard, rather than the 'region of storage'
- definiton in 1.8p1
-
- 
-
- <td width="466">
- Clarify terms and usage
-
- <td width="225">
- 
-
- we think we're removing this; Howard to create LWG issue. Howard, see [func.referenceclosure.cons]<tr valign="top">
- <td width="29">
- UK 
- 153
-
- <td width="75">
- 17.3.17
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- If a
- repositional stream can only seek to a position previously
- encountered, then an arbitrary-positional-stream cannot
- satisfy this definition, as cross-referenced in 17.3.17
-
- 
-
- <td width="466">
- Strike the word 'only'. A note might be
- added to reinforce the intent
-
- <td width="225">
- 
-
- editorial; sent to Pete Becker<tr valign="top">
- <td width="29">
- UK 
- 154
-
- 
-
- <td width="75">
- 17.3.20
-
- <td width="31">
- 
-
- <td width="38">
- Ed
-
- <td width="375">
- Missing definition of a stable partition
- algorithm
-
- <td width="466">
- Add definition from 25.2.12p7
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 155
-
- <td width="75">
- 17.3.3
-
- <td width="31">
- 
-
- <td width="38">
- Ed
-
- <td width="375">
- Add clause 28 to list that use this
- definition of character
-
- <td width="466">
- Add clause 28 to list that use this
- definition of character
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 156
-
- <td width="75">
- 17.3.4
-
- <td width="31">
- 
-
- <td width="38">
- Ed
-
- <td width="375">
- Add regular
- expressions to set of templates using character container
- type
-
- 
-
- <td width="466">
- Add regular expressions to set of templates
- using character container type
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 157
-
- <td width="75">
- 17.5.2.2
-
- <td width="31">
- 3
-
- <td width="38">
- Ed
-
- <td width="375">
- Add concepts to
- the ordered list of presentation
-
- 
-
- 
-
- <td width="466">
- Add concepts into the sequence
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 158
-
- <td width="75">
- 17.5.2.2
-
- <td width="31">
- 3
-
- <td width="38">
- Ed
-
- <td width="375">
- templates are neither classes nor functions
-
- <td width="466">
- Replace
- 'classes' and 'functions' with 'classes and class
- templates' and 'functions and function templates'
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 159
-
- <td width="75">
- 17.5.2.4
-
- <td width="31">
- Footnote 152
-
- <td width="38">
- Ed
-
- <td width="375">
- This informative
- footnote was relevant in 1998, not 2008. The term 'existing
- vendors' may imply something different now
-
- 
-
- <td width="466">
- Strike the footnote, or replace 'existing'
- with 'original' or similar
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 160
-
- <td width="75">
- 17.5.2.4
-
- <td width="31">
- 3
-
- <td width="38">
- Ed
-
- <td width="375">
- requires is now
- a keyword with a specific meaning related to concepts, and
- its use in library specifcation may be confusing. Generally
- the Requires clause is used to make requirements on the
- caller, not the library, so typically providing runtime
- pre-conditions. Suggest a new name to refflect that. Note
- that Clause 30 already seems to be written to this
- convention.
-
- 
-
- <td width="466">
- Replace 'Requires' with 'Preconditions'
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 161
-
- <td width="75">
- 17.5.2.4
-
- <td width="31">
- 4
-
- <td width="38">
- Ed
-
- <td width="375">
- This paragraph
- is redundant as the definition of the term 'handler
- function' is already provided in 17.3. Are we in danger of
- proving two definitions of the same terms? Which is the
- 'controlling' definition?
-
- 
-
- <td width="466">
- Strike 17.5.2.4p4
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 162
-
- <td width="75">
- 17.5.2.4
-
- <td width="31">
- 3
-
- <td width="38">
- Ed
-
- <td width="375">
- Clause 30 makes
- use of a 'Synchronization' semantic element, that
- frequently appears either between Effects: and
- Postconditions:, or between Returns: and Throws:
-
- 
-
- <td width="466">
- Add 'Synchronization' to the list either
- between Effects: and Postconditions:, or between Returns:
- and Throws:.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 163
-
- <td width="75">
- 17.5.2.4
-
- <td width="31">
- 3
-
- <td width="38">
- Te
-
- <td width="375">
- Many functions
- are defined as "Effects: Equivalent to a...", which seems
- to also define the preconditions, effects, etc. But this is
- not made clear.
-
- 
-
- <td width="466">
- Introduce an explicit "Equivalent to",
- which defines all of the properties of the function.
-
- <td width="225">
- 
-
- Tom Plum to open LWG issue; we believe this is related to LWG625<tr valign="top">
- <td width="29">
- UK 
- 164
-
- <td width="75">
- 17.5.3.2.1
-
- <td width="31">
- 1
-
- <td width="38">
- Ed
-
- <td width="375">
- This phrasing predates concepts. While this
- kind of description is still used, the examples provided
- are now all concepts, and should be replaced with
- appropriate examples
-
- <td width="466">
- Use better names
- for the examples. Ideally totally replace the need by
- constraining all templates in library, so that real
- concepts are all that is needed. Note if retained that
- CopyConstructible is mis-spelled.
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 165
-
- <td width="75">
- 17.5.3.2.2, 
- 17.5.3.2.3
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- constraints on
- bitmask and enumation types were supposed to be tightened
- up as part of the motivation for the constexpr feature -
- see paper n2235 for deails
-
- 
-
- <td width="466">
- Adopt wording in line with the motivation
- described in N2235
-
- <td width="225">
- 
-
- Robert Klarer to review<tr valign="top">
- <td width="29">
- UK 
- 166
-
- <td width="75">
- 17.5.3.2.4.1, 
- 17.5.3.3
-
- 
-
- <td width="31">
- 
-
- <td width="38">
- Ed
-
- <td width="375">
- List of library clauses should go up to 30,
- not 27
-
- <td width="466">
- Replace initial refernce to ch27 with ch30
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 167
-
- <td width="75">
- 17.5.3.4 
- Private 
- members
-
- <td width="31">
- 
-
- <td width="38">
- Ed
-
- <td width="375">
- Comment marker in wrong place.
-
- <td width="466">
- Change: //
- streambuf* sb; exposition only to streambuf* sb; //
- exposition only To reflect actual usage.
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 168
-
- <td width="75">
- 17.6.2.2
-
- <td width="31">
- 2
-
- <td width="38">
- Te
-
- <td width="375">
- We should make
- it clear (either by note or normatively) that namespace std
- may contain inline namespaces, and that entities specified
- to be defined in std may in fact be defined in one of these
- inline namespaces. (If we're going to use them for
- versioning, eg when TR2 comes along, we're going to need
- that.)
-
- 
-
- <td width="466">
- Replace "namespace std or namespaces nested
- within namespace std" with "namespace std or namespaces
- nested within namespace std or inline namespaces nested
- directly or indirectly within namespace std"
-
- <td width="225">
- 
-
- Howard will create issue to adopt UK words (some have reservations whether
- it is correct)<tr valign="top">
- <td width="29">
- UK 
- 169
-
- <td width="75">
- 17.6.2.2
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- This phrasing
- contradicts later freedom to implement the C standard
- library portions in the global namespace as well as std.
- (17.6.2.3p4)
-
- 
-
- <td width="466">
- Resolve conflict in either place
-
- <td width="225">
- 
-
- Bill Plaugher to open issue. If the wording is too broad we need to add an
- exception to the standard C library.<tr valign="top">
- <td width="29">
- UK 
- 170
-
- <td width="75">
- 17.6.2.3
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- One of goals of
- C++0x is to make language easier to teach and for
- 'incidental' programmers. The fine-grained headers of the
- C++ library are valuable in large scale systems for
- managing dependencies and optimising build times, but
- overcomplicated for simple development and tutorials. Add
- additional headers to support the whole library through a
- single include statement.
-
- 
-
- <td width="466">
- Add a new header <std> that has the
- effect of including everything in tables 13 and 14, except
- <iosfwd> and <cassert>. Add an additional
- header <fwd> that adds all declarations from
- <std> but no definitions.
-
- <td width="225">
- 
-
- Alisdair to open issue. We prefer
- <std>only. </std>
-
- <tr valign="top">
- <td width="29">
- UK 
- 171
-
- <td width="75">
- 17.6.2.4
-
- <td width="31">
- 3
-
- <td width="38">
- Ed
-
- <td width="375">
- Does
- freestanding implementation require a full implementation
- of all listed headers? The reference to abort, at_exit and
- exit is confusing. Is a conforming implementation allow to
- deliver partial forms of these headers? If so which ones?
- Are empty versions of everything but <cstdlib>
- conforming?
-
- 
-
- <td width="466">
- Either strike the references to abort,
- at_exit and exit, or clarify which headers only require
- partial support.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 172
-
- <td width="75">
- 17.6.2.4
-
- <td width="31">
- 3
-
- <td width="38">
- Te
-
- <td width="375">
- No reference to
- new functions quick_exit and at_quick_exit
-
- 
-
- <td width="466">
- Add reference to quick_exit and
- at_quick_exit
-
- <td width="225">
- 
-
- NAD. We do not belive at_exit and at_quick_exit should be required by
- freestanding implementations.<tr valign="top">
- <td width="29">
- UK 
- 173
-
- <td width="75">
- 17.6.2.4
-
- <td width="31">
- table 15
-
- <td width="38">
- Te
-
- <td width="375">
- 
- <initializer_list> is missing from headers required
- in freestanding implementations.
-
- 
-
- <td width="466">
- Add 18.8, initializer lists,
- <initializer_list>, to the end of the table.
-
- <td width="225">
- 
-
- LWG is interested in N2814, but we're concerned whether CWG will accept
- language recommendations.<tr valign="top">
- <td width="29">
- JP 23
-
- <td width="75">
- 17.6.2.4
-
- <td width="31">
- 2nd para, Table 15
-
- <td width="38">
- te
-
- <td width="375">
- There is a
- freestanding implementation including <type_traits>,
- <array>, <ratio>, lately added to Table 13, C++
- library headers. 
- Programmers think them useful and hope that these headers
- are also added to Table 15, C++ headers for freestanding
- implementations, that shows the set of headers which a
- freestanding implementation shall include at least.
-
- 
- 
-
- <td width="466">
- Add
- <type_traits>, <array>, <ration> to Table
- 15.
-
- <td width="225">
- 
-
- LWG is interested in N2814, but we're concerned whether CWG will accept
- language recommendations.
-
- add <type_traits> only. Alisdair will draft an issue.<tr valign="top">
- <td width="29">
- UK 
- 174
-
- <td width="75">
- 17.6.3.2
-
- <td width="31">
- 3
-
- <td width="38">
- Ed
-
- <td width="375">
- The phrasing is
- mildly ambiguous when using the word 'it' to refer back to
- the header - an unfotunate reading might confuse it with
- the translate unit, which is the subject of the surrounding
- clause.
-
- 
-
- <td width="466">
- Replace 'the first reference to any of the
- entities declared in that header by the translation unit'
- with 'the first reference to any of the entities that
- header declares in the translation unit'
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 175
-
- <td width="75">
- 17.6.4.2.1
-
- <td width="31">
- 2
-
- <td width="38">
- Te
-
- <td width="375">
- Local types can
- now be used to instantiate templates, but don't have
- external linkage
-
- 
-
- <td width="466">
- Remove the reference to external linkage
-
- <td width="225">
- 
-
- we accept the proposed solution. Martin will draft an issue.<tr valign="top">
- <td width="29">
- UK 
- 176
-
- <td width="75">
- 17.6.4.3.3
-
- <td width="31">
- Footnote 175
-
- 
-
- <td width="38">
- Ed
-
- <td width="375">
- Reference to namespace ::std should be
- 17.6.4.2
-
- <td width="466">
- Change referfence from 17.6.4.3 to 17.6.4.2
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 177
-
- <td width="75">
- 17.6.4.3.4
-
- <td width="31">
- 3
-
- <td width="38">
- Ed
-
- <td width="375">
- Sentence is
- redundant as double underscores are reserved in all
- contexts by 17.6.4.3.3
-
- 
-
- <td width="466">
- Strike the sentence
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 178
-
- <td width="75">
- 17.6.4.8
-
- <td width="31">
- 2
-
- <td width="38">
- Ed
-
- <td width="375">
- The last sentence of the third bullet
- "Operations on such types can report a failure by throwing
- an exception unless otherwise specified" is redundant as
- behaviour is already undefined.
-
- <td width="466">
- Strike the sentence
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 179
-
- <td width="75">
- 17.6.4.8
-
- <td width="31">
- 2
-
- <td width="38">
- Te
-
- <td width="375">
- According to the
- 4th bullet there is a problem if "if any replacement
- function or handler function or destructor operation throws
- an exception". There should be no problem throwing
- exceptions so long as they are caught within the function.
-
- 
-
- <td width="466">
- Replace the word 'throws' with 'propogates'
-
- <td width="225">
- 
-
- Agreed. Alisdair will draft an issue.<tr valign="top">
- <td width="29">
- JP 22
-
- <td width="75">
- 17.6.5.7
-
- <td width="31">
- 4th para, 1st
- line
-
- <td width="38">
- ed
-
- <td width="375">
- The
- statement below describes relation among two or more
- threads using words “between threads”: 
- [Note: This means, for example, that implementations
- can’t use a static object for internal purposes
- without synchronization because it could cause a data race
- even in programs that do not explicitly share objects
- between threads. —end note ]
-
- In
- such case, “among” is preferred instead of
- “between”.
-
- <td width="466">
- 
- Change "between threads" to "among threads".
-
- 
- There are same cases in 17.6.1 paragraph 2, 17.6.5.7
- paragraph 6, 30.1 paragraph 1, 30.3.1 paragraph 1 also.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 180
-
- <td width="75">
- 17.6.5.10
-
- <td width="31">
- 1, 4
-
- <td width="38">
- Te
-
- <td width="375">
- It should not be
- possible to strengthen the exception specification for
- virtual functions as this could break user code. Note this
- is not a problem in practice as there are no virtual
- functions with exception specifications in the current
- library, other than empty throw specifications which it is
- not possible to strengthen.
-
- 
-
- <td width="466">
- Add restriction that exception
- specification of virtual functions cannot be tightened.
-
- <td width="225">
- 
-
- NAD, the standard already has the desired restriction.<tr valign="top">
- <td width="29">
- UK 
- 181
-
- <td width="75">
- 17.6.5.10
-
- <td width="31">
- Footnote 186
-
- <td width="38">
- Te
-
- <td width="375">
- This footnote is
- wrong. C library functions do not have any exception
- specification, but might be treated as if they had an empty
- throw specification
-
- 
-
- <td width="466">
- Clarify that this note does not mean the
- functions are genuinely declared with the specification,
- but are treated as-if.
-
- <td width="225">
- 
-
- We agree that the footnote is wrong and it will be removed. Pete will handle
- as editorial.<tr valign="top">
- <td width="29">
- UK 
- 182
-
- <td width="75">
- 17.6.5.10
-
- <td width="31">
- Footnote 188
-
- <td width="38">
- Te
-
- <td width="375">
- It is very
- helpful to assume all exceptions thrown by the standard
- library derive from std::exception. The 'encouragement' of
- this note should be made normative.
-
- 
-
- <td width="466">
- Make this footnote normative
-
- <td width="225">
- 
-
- NAD. We cannot mandate all standard-library functions that might use some
- third-party library.<tr valign="top">
- <td width="29">
- UK 
- 184
-
- <td width="75">
- 18 -> 30
-
- <td width="31">
- 
-
- <td width="38">
- Ed
-
- <td width="375">
- The new
- alias-declaration syntax is generally easier to read than a
- typedef declaration. This is especially true for complex
- types like function pointers.
-
- 
-
- <td width="466">
- Replace all typedef declarations in the
- standard library with alias-declarations, except in the
- standard C library.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 24
-
- <td width="75">
- 18
-
- <td width="31">
- 2nd para, Table 16
-
- <td width="38">
- ed
-
- <td width="375">
- 
- Subclauses are listed in Table 16 as:
-
- "18.6 Type
- identification …"
-
- "18.8 Initializer
- lists …"
-
- "18.7 Exception
- handling …".
-
- <td width="466">
- 
- Sort them in the increasing order 
- "18.6 Type identification …"
-
- "18.7 Exception
- handling …".
-
- 
- "18.8 Initializer lists …"
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 25
-
- <td width="75">
- 18.1
-
- <td width="31">
- 
- 6th para , last line, SEE ALSO
-
- 
-
- <td width="38">
- ed
-
- <td width="375">
- 
- max_align_t is described in 18.1, so add 3.11 Alignment as
- the reference.
-
- <td width="466">
- Add
- "3.11, Alignment" to
- SEE ALSO.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- FR 32
-
- <td width="75">
- 18.2.1 
- [Numeric 
- limits]
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- The definition of
- numeric_limits<> as requiring a regular type is both
- conceptually wrong and operationally illogical. As we
- pointed before, this mistake needs to be corrected. For
- example, the template can be left unconstrained. In fact
- this reflects a much more general problem with
- concept_maps/axioms and their interpretations. It appears
- that the current text heavily leans toward experimental
- academic type theory.
-
- 
-
- <td width="466">
- We suggest that a more pragmatic approach, in the spirit
- of C and C++, be taken so that calls to constrained
- function templates are interpreted as assertions on
- *values*, not necessarily semantics assertions on the
- carrier type.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- DE-16
-
- <td width="75">
- 18.2.1
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- DE-16 The class
- template numeric_limits should not specify the Regular
- concept requirement for its template parameter, because it
- contains functions returning NaN values for floating-point
- types; these values violate the semantics of
- EqualityComparable. See also library issue 902 in WG21
- document N2794 "C++ Standard Library Active Issues List
- (Revision R60)", available at
- http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2794.html
- .
-
- 
-
- <td width="466">
- Specify a concept requirement with fewer constraints as
- appropriate, for example SemiRegular.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 26
-
- <td width="75">
- 18.2.1.1
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- 
- numeric_limits does not use concept.
-
- <td width="466">
- 
- Correct as follows.
-
- 
- 
-
- 
- template<class T> class numeric_limits<const
- T>;
-
- 
- template<class T> class numeric_limits<volatile
- T>;
-
- 
- template<class T> class numeric_limits<const
- volatile T>;
-
- 
- 
-
- 
- should be
-
- 
- 
-
- 
- template<Regular T> class
- numeric_limits<const T>;
-
- 
- template<Regular T> class
- numeric_limits<volatile T>;
-
- 
- template<Regular T> class
- numeric_limits<const volatile T>;
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- DE-17
-
- <td width="75">
- 18.2.6
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- DE-17 The class
- type_index should be removed; it provides no additional
- functionality beyond providing appropriate concept maps.
-
- 
-
- <td width="466">
- Specify concept maps for "const type_info *" as required
- by the ordered and unordered containers and remove the
- class type_index.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 185
-
- <td width="75">
- 18.3.1
-
- <td width="31">
- 2
-
- <td width="38">
- Ed
-
- <td width="375">
- There is no
- header <stdint>, it should either be <stdint.h>
- or <cstdint>
-
- 
-
- <td width="466">
- Replace <stdint> with <cstdint>
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- DE-18
-
- <td width="75">
- 18.4
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- DE-18 The
- proposed C++ standard makes a considerable number of
- existing programs that have well-defined behavior according
- to ISO/IEC 14882:2003 have undefined behavior without a
- diagnostic hint to the programmer at all. This applies to
- the presence of threads and to pointer safety (the latter
- was introduced to support garbage collection). In order to
- avoid requiring a full code review for user code,
- facilities should be present that allow the compile-time
- detection of the advanced features of the proposed C++
- standard. It is expected that C++ implementations will
- provide a means (for example, a command-line switch) to
- turn off either or both of threads and garbage collection
- support, turning potentially undefined programs into
- well-defined ones. 
- Note: This issue is contributing significantly to
- Germany's overall “no” vote.
-
- 
-
- <td width="466">
- Consider applying the changes proposed in WG21 document
- N2693 "Requirements on programs and backwards
- compatibility", available at
- http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2693.html
- .
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 186
-
- <td width="75">
- 18.4
-
- <td width="31">
- Footnote 221
-
- <td width="38">
- Ed
-
- <td width="375">
- What is the
- purpose of this comment? The standard stream objects (cin,
- cerr etc.) have a peculiar lifetime that extends beyond the
- program. They may never be destroyed so will not be
- responsible for flushing buffers at the stated time.
-
- 
-
- <td width="466">
- Remove the footnote
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 187
-
- <td width="75">
- 18.4
-
- <td width="31">
- 9
-
- <td width="38">
- Te
-
- <td width="375">
- The term "thread
- safe" is not defined nor used in this context anywhere else
- in the standard.
-
- 
-
- <td width="466">
- Clarify the intended meaing of "thread
- safe"
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 188
-
- <td width="75">
- 18.4
-
- <td width="31">
- 12
-
- <td width="38">
- Te
-
- <td width="375">
- The function
- _Exit does not appear to be defined in this standard.
- Should it be added to the table of functions
- included-by-reference to the C standard?
-
- 
-
- <td width="466">
- Depends on where _Exit comes from
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 189
-
- <td width="75">
- 18.4, 18.7
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- The addition of the [[noreturn]] attribute
- to the language will be an important aid for static
- analysis tools.
-
- <td width="466">
- The following
- functions should be declared in C++ with the [[noreturn]]
- attribute: abort exit quick_exit terminate unexpected
- rethrow_exception throw_with_nested
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 27
-
- <td width="75">
- 18.4, 18.9, 
- 18.7.2.2, 
- 18.7.3.1
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- 
- There are Standard library functions that never return to
- the caller. They are explained so in the Standard but not
- declared explicitly.
-
- <td width="466">
- 
- Consider to add the attribute [[noreturn]] to such
- functions,
-
- 
- 
-
- 
- 15.5.2 unexpected 
- 18.4: abort(), exit(), quick_exit, 
- 18.7.2.2: unexpected_handler, 
- 18.7.3.1: terminate_handler,
-
- 
- 18.7.6 rethrow_nested
-
- 18.7.6
- throw_with_nested 
- 18.9: longjmp.
-
- 
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 190
-
- <td width="75">
- 18.5.1
-
- <td width="31">
- various
-
- <td width="38">
- Te
-
- <td width="375">
- It is not entirely clear how the current
- specification acts in the presence of a garbage collected
- implementation.
-
- <td width="466">
- All deallocation
- functions taking a pointer parameter should have a
- Precondition : ptr is a safely-derived pointer value.
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 191
-
- <td width="75">
- 18.5.1.1
-
- <td width="31">
- 4
-
- <td width="38">
- Ed
-
- <td width="375">
- According to the second bullet, behaviour
- becomes undefined (for lack of a specification) if the user
- has not yet called set_new_handler.
-
- <td width="466">
- Rephrase the
- second bullet in terms of a new handler being installed,
- and update any definition of handler function necessary to
- be sure the term 'installed' is defined.
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 192
-
- <td width="75">
- 18.5.1.2
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- The declared
- signature is not compatible with the current requirement to
- throw std::length_error. It is too late to weaken the
- exception specification, so the only other change is to
- preserve new (improved) behaviour is to throw
- std::bad_alloc, or something derived from std::bad_alloc.
-
- 
-
- <td width="466">
- Fix 5.3.4p7 by required std::bad_alloc
- rather than std::length_error
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 193
-
- <td width="75">
- 18.5.2.2
-
- <td width="31">
- 2
-
- <td width="38">
- Te
-
- <td width="375">
- quick_exit has
- been added as a new valid way to terminate a program in a
- well defined way
-
- 
-
- <td width="466">
- Change 3rd bullet: call either abort(),
- exit() or quick_exit();
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 194
-
- <td width="75">
- 18.6
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- The inclusion of
- type_index and hash<type_index> in <typeinfo>
- brings dependencies into <typeinfo> which are
- inconsistent with the definition of freestanding C++ in
- 17.6.2.4.
-
- 
-
- <td width="466">
- Move type_index and hash<type_index>
- out of <typeinfo> and into a new header,
- <typeindex>.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 28
-
- <td width="75">
- 18.6, 
- 18.7, 
- 19.1
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- 
- Errors reported by Exception classes are of types char or
- std::string only. For example, std::exception is declared
- with char, std::string types, therefore types
- wchar_t/wstring, char16_t/u16string, or char32_t/u32string
- can not be used.
-
- 
-
- <td width="466">
- 
- Consider other types.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 29
-
- <td width="75">
- 18.7.6
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- 
- throw_with_nested does not use concept.
-
- <td width="466">
- 
- Correct as follows.
-
- 
- template<class T> void throw_with_nested(T&&
- t); // [[noreturn]]
-
- 
- 
-
- should be
-
- 
- 
-
- 
- template<CopyConstructible T> void
- throw_with_nested(T&& t); // [[noreturn]]
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 30
-
- <td width="75">
- 18.7.6
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- To
- handle nested exceptions strictly, error information of
- tree structure will be required though, the
- nested_exception does not support tree structure. It is
- insufficient as error handling.
-
- <td width="466">
- 
- Consider nested_exception to support tree structure.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 31
-
- <td width="75">
- 18.7.6
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- It
- is difficult to understand in which case nested_exception
- is applied.
-
- <td width="466">
- Consider to add
- a sample program which rethrows exception.
-
- 
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 195
-
- <td width="75">
- 18.8
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- The class
- definition of std::initializer_list contains concept-maps
- to Range which should be out of the class, and in
- <iterator_concepts> instead. Otherwise, it's not
- possible to use initializer_lists in a freestanding C++
- implementation.
-
- 
-
- <td width="466">
- Delete the two concept maps from
- std::initializer_list.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 196
-
- <td width="75">
- 18.8.3
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- Concept maps for initializer_list to Range
- should not be in language support headers, but instead in
- iterator concepts.
-
- <td width="466">
- Remove section
- 18.8.3 and put it in 24.1.8.1 instead, so that the
- concept_maps from initializer_list to Range are specified
- under Range instead of under initializer lists; also, so
- that they're implemented in <iterator_concepts>
- instead of <initializer_list>.
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 197
-
- <td width="75">
- 19
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- All the exception classes in this clause
- take a std::string argument by const reference. They should
- all be overloaded to accept std::string by rvalue rerefence
- for an efficient move as well.
-
- <td width="466">
- Provide a
- constructor for every exception class in clause 19
- accepting a std::string by rvalue reference, with the
- semantics that the passed string may be moved.
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 32
-
- <td width="75">
- 19.1
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- 
- Messages returned by the member function what() of standard
- exception classes seem difficult to judge.
-
- For
- example, following messages are returned by what() of
- std::bad_alloc of existing implementations:
-
- 
- 
-
- 
- Compiler: Message returned by what()
-
- 
- ---------------------------------------------
-
- 
- Borland C++ 5.6.4: no named exception thrown
-
- 
- Visual C++ 8.0: bad allocation
-
- 
- Code Warrior 8.0: exception
-
- g++
- 3.4.4: St9exception
-
- 
- 
-
- It is difficult
- to recognize what exception was thrown when using those
- compilers except Visual C++.
-
- 
- 
-
- <td width="466">
- 
- Consider to add footnote that recommends what() returns
- message easy to recognize what exception was thrown.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- US 64
-
- <td width="75">
- 19.3
-
- <td width="31">
- 1
-
- <td width="38">
- Ge
-
- <td width="375">
- “ See also: ISO C
- 7.1.4, 7.2, Amendment 1 4.3.”
- It is unclear why this cross reference is here. Amendment 1
- was to C89, not C99.
-
- <td width="466">
- Delete this
- cross reference. If necessary, expand the main text to
- include the relevant referenced text
-
- 
-
- <td width="225">
- 
-
- The statement made in the comment was already aired prior to the last vote.
- Without further input, the committee cannot remove a feature that was voted
- into the draft. We will look at this comment in the light of N2829, which
- attempts to make scoped allocators less intrusive.<tr valign="top">
- <td width="29">
- US 65
-
- <td width="75">
- 20
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- Scoped allocators and
- allocator propagation traits add a small amount of utility
- at the cost of a great deal of machinery. The machinery is
- user visible, and it extends to library components that
- don't have any obvious connection to allocators, including
- basic concepts and simple components like pair and tuple.
-
- <td width="466">
- 
- Sketch of proposed resolution: Eliminate scoped allocators,
- replace allocator propagation traits with a simple uniform
- rule (e.g. always propagate on copy and move), remove all
- mention of allocators from components that don't explicitly
- allocate memory (e.g. pair), and adjust container
- interfaces to reflect this simplification.
-
- 
- Components that I propose eliminating include HasAllocatorType
- <a href=
- "http://wiki.corp.google.com/twiki/bin/edit/Main/HasAllocatorType?topicparent=Main.CppStandardIssues">
- ?</a>, is_scoped_allocator,
- allocator_propagation_map, scoped_allocator_adaptor, and
- ConstructibleAsElement
- <a href=
- "http://wiki.corp.google.com/twiki/bin/edit/Main/ConstructibleAsElement?topicparent=Main.CppStandardIssues">
- ?</a>.
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 198
-
- <td width="75">
- 20
-
- <td width="31">
- 
-
- <td width="38">
- Ed
-
- <td width="375">
- The organization of clause 20 could be
- improved to better group related items, making the standard
- easier to navigate.
-
- <td width="466">
- 20.6.7, 20.6.8,
- 20.6.9 and 20.6.10 should be grouped under a section called
- "operator wrappers" or similar. The goal of all 4
- subsections combined is to provide a functor for every
- operator in the language. 20.6.17 class template hash
- should numerically appear immediately after the operator
- wrappers, as they are functors that are used in similar
- ways 20.6.11, 20.6.12, 20.6.13, 20.6.14, 20.6.15 are
- strongly related to 20.6.3, and to an extent 20.6.2. These
- should all come under a subheading of "function adapters"
- 20.7.1, 20.7.3, 20.7.4, 20.7.5, 20.7.6, 20.7.7 and 20.7.10
- should all be grouped as subclauses under [20.7.2
- Allocators] [20.7.12 unique_ptr] should be a sub-section of
- [20.7.13 smart pointers] [20.7.13 smart pointers] is
- important enough to have a high level bullet after [20.7
- memory], suggest renumbering as [20.8 smart pointers]
- [20.7.13.7 Pointer safety] is nothing to do with smart
- pointers and should become its own subclause [20.7.14
- Pointer safety] [20.9 date and time functions] should be
- moved under [20.8 time utilities] and retitled [20.8.6 C
- Library] (as per memory management/C Library) [20.6.18
- reference_closure] is fundamentally a language support
- feature and should move to clause 18, see separate comment
- [20.6.5 reference_wrapper] should be simplified and moved
- into [2.2 utility components], see separate comment [20.6.4
- result_of] should be reorganised as a type trait - see
- separate comment Tuples and pairs are closely related so
- merge tuple and pair into the same subclause - see more
- general comment on this
-
- 
-
- <td width="225">
- 
-
- Agree that this is editorial -- forward to project editor. (effective
- duplicate of US 69)<tr valign="top">
- <td width="29">
- UK 
- 199
-
- <td width="75">
- 20.1.1, 20.1.2
-
- <td width="31">
- 2
-
- <td width="38">
- Te
-
- <td width="375">
- The requirement
- that programs do not supply concept_maps should probably be
- users do not supply their own concept_map specializations.
- THe program will almost certainly supply concept_maps - the
- standard itself supplies a specialization for RvalueOf?
- references. Note that the term _program_ is defined in
- 3.5p1 and makes no account of the standard library being
- treated differently to user written code.
-
- 
-
- <td width="466">
- Replace the term 'program' with 'user'.
-
- <td width="225">
- 
-
- Agree change 'program' to 'user' in clauses 20.1.1 and 20.1.2<tr valign="top">
- <td width="29">
- UK 
- 200
-
- <td width="75">
- 20.1.4
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- All standard library use expects Predicates
- to be CopyConstructible, and this should be recognised
- easily without reatedly stating on every use-case.
-
- <td width="466">
- Either require
- CopyConstructible<F> as part of Predicate, or create
- a refined concept, StdPredicate, used throughout the
- library that requires CopyConstructible as well as
- Callable. Consider making (Std)Predicate SemiRegular.
-
- 
-
- <td width="225">
- 
-
- We agree that adding constraints to predicate is a good idea. Predicate
- should be further constrained, rather than creating a new StdPredicate to
- avoid the need users to constantly choose between them. At a minimum,
- Predicate should refine MoveConstructible. However, upon review of existing
- library components, CopyConstructible or even SemiRegular might be more
- appropriate for Predicate.<tr valign="top">
- <td width="29">
- UK 
- 201
-
- <td width="75">
- 20.1.5
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- The Consistency axiom for
- LessThanComparable will not compile.
-
- <td width="466">
- Add a requires
- clause to the Consistency axiomL requires
- HasLessEquals<T> &&
- HasGreaterEquals<T>, or split the Consistency axiom
- into two so that 'basic' consistency can be asserted
- regardless of the <=/>= requirement.
-
- 
-
- <td width="225">
- 
-
- After consultation with the submitter, we agreed that the suggestion was in
- error and there is nothing else to be done.<tr valign="top">
- <td width="29">
- JP 33
-
- <td width="75">
- 20.1.5
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- 
- LessThanComparable and EqualityComparable don't correspond
- to NaN.
-
- <td width="466">
- Apply
- concept_map to these concepts at FloatingPointType
-
- 
- 
-
- <td width="225">
- 
-
- We believe that no change is necessary, but it should be reviewed by a group
- devoted to numeric issues. Not every possible state for a type must
- participate in the axioms. For example, pointers are dereferenceable even if
- some pointers (e.g. the null pointer) should not be dereferenced.<tr valign="top">
- <td width="29">
- US 66
-
- <td width="75">
- 20.1.10
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- Application of the "Regular" concept to floating-point
- types appears to be controversial (see long discussion on
- std-lib reflector).
-
- <td width="466">
- State that the “Regular” concept does not
- apply to floating-point types.
-
- <td width="225">
- 
-
- Recommend that we handle the same as JP 33.<tr valign="top">
- <td width="29">
- JP 34
-
- <td width="75">
- 20.2
-
- <td width="31">
- 
- 1st para, 4th line
-
- 
-
- <td width="38">
- ed
-
- <td width="375">
- 
- Though N2672 pointed at adding
- "#include<initializer_list>", it isn't reflected.
-
- <td width="466">
- add
- followings
-
- 
- #include <initializer_list> // for concept_map
-
- <td width="225">
- 
-
- Agree that the omission of <code>#include
- <initializer_list></initializer_list>
- </code>was not agreed to in a vote and that the editor should reinstate it.
- There is some disagreement as to whether it actually should be
- there. Some believed it did not belong because we do not guarantee that one
- header includes another anywhere else in the standard. However, the paper
- that was voted in explicitly did make that guarantee. Removing that
- guarantee is beyond the scope of this review.<tr valign="top">
- <td width="29">
- US 67
-
- <td width="75">
- 20.2.1
-
- <td width="31">
- ¶ 5 first sent.
-
- <td width="38">
- ed
-
- <td width="375">
- Some connective words are missing.
-
- <td width="466">
- Insert “corresponding to” before “an
- lvalue reference type.”
-
- <td width="225">
- 
-
- Yes. Forward to project editor.<tr valign="top">
- <td width="29">
- JP 35
-
- <td width="75">
- 20.2.3
-
- <td width="31">
- 
- 6th para, 1st line
-
- 
-
- <td width="38">
- ed
-
- <td width="375">
- 
- Typo,
-
- "stdforward" should be
- "std::forward"
-
- <td width="466">
- Correct typo.
-
- <td width="225">
- 
-
- Yes. Forward to project editor.<tr valign="top">
- <td width="29">
- UK 
- 202
-
- <td width="75">
- 20.2.4
-
- <td width="31">
- 
-
- <td width="38">
- Ed
-
- <td width="375">
- The references
- to pair in the tuple-like access to pair functions qualify
- pair with std::pair even though they are in a namespace std
- block.
-
- 
-
- <td width="466">
- Remove the std:: qualification from these
- references to pair.
-
- <td width="225">
- 
-
- Yes. Forward to project editor.<tr valign="top">
- <td width="29">
- US 68
-
- <td width="75">
- 20.2.12
-
- <td width="31">
- IntegralLike
-
- <td width="38">
- te/ed
-
- <td width="375">
- The code defining the context is syntactically
- incorrect.
-
- <td width="466">
- Insert a comma in two places: at the end of the third
- line of refinements, and at the end of the fourth line of
- refinements.
-
- <td width="225">
- 
-
- Editorial. The correct section is 20.1.12, not 20.2.12. Forward to project
- editor.<tr valign="top">
- <td width="29">
- UK 
- 203
-
- <td width="75">
- 20.3.2
-
- <td width="31">
- 1-4
-
- <td width="38">
- Ed
-
- <td width="375">
- The ratio_xyz
- types have a misplaced '}'. For example: template <class
- R1, class R2> struct ratio_add { typedef see below}
- type; ;
-
- 
-
- <td width="466">
- Move the '}' to after the typedef: template
- <class R1, class R2> struct ratio_add { typedef see
- below type; };
-
- <td width="225">
- 
-
- Yes. Forward to project editor.<tr valign="top">
- <td width="29">
- JP 36
-
- <td width="75">
- 20.4.2.1
-
- <td width="31">
- 
- 19th para, 6th line
-
- 
-
- <td width="38">
- ed
-
- <td width="375">
- 
- Typo.
-
- "it
- it" should be "it is"
-
- <td width="466">
- 
- Correct typo.
-
- <td width="225">
- 
-
- Yes. Forward to project editor.<tr valign="top">
- <td width="29">
- UK 
- 204
-
- <td width="75">
- 20.5
-
- <td width="31">
- Table 41
-
- <td width="38">
- Te
-
- <td width="375">
- It is not
- possible to create a variant union based on a parameter
- pack expansion, e.g. to implement a classic discriminated
- union template.
-
- 
-
- <td width="466">
- Restore aligned_union template that was
- removed by LWG issue 856.
-
- <td width="225">
- 
-
- Agree that aligned_union is not completely redundant. We are investigating
- whether the need for aligned_union is compelling enough to reinstate.<tr valign="top">
- <td width="29">
- US 69
-
- <td width="75">
- 20.5
-
- <td width="31">
- 
-
- <td width="38">
- ed
-
- <td width="375">
- This section, dealing with tuple<>, should be in
- the same section as the similar utility pair<>.
-
- <td width="466">
- Restructure Clause 20 so as to bring these similar
- components together.
-
- <td width="225">
- 
-
- Editorial (effective duplicate of UK 198). Forward to project editor.<tr valign="top">
- <td width="29">
- UK 
- 205
-
- <td width="75">
- 20.5.3
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- 
- integral_constant objects should be usable in
- integral-constant-expressions. The addition to the language
- of literal types and the enhanced rules for constant
- expressions make this possible.
-
- 
-
- <td width="466">
- Add a constexpr conversion operator to
- class tempalate integral_constant: constexpr operator
- value_type() { return value; }
-
- <td width="225">
- 
-
- Agree: Add a constexpr conversion operator to class template
- integral_constant: <code>constexpr operator value_type() { return value; }</code><tr valign="top">
- <td width="29">
- UK 
- 206
-
- <td width="75">
- 20.5.5
-
- <td width="31">
- para 4
-
- <td width="38">
- Te
-
- <td width="375">
- Currently the
- std says: "In order to instantiate the template
- is_convertible<From, To>, the following code shall be
- well formed:" But the code shown is the requirement for the
- result of is_convertible to be a true_type, not a
- precondition on whether the template can be instantiated.
-
- 
-
- <td width="466">
- Change: "In order to instantiate the
- template is_convertible<From, To>, the following code
- shall be well formed:" To: "The template
- is_convertible<From, To> inherits either directly or
- indirectly from true_type if the following code is well
- formed:"
-
- <td width="225">
- 
-
- Agree with the proposed resolution: Section 20.5.5, Change: "In order to
- instantiate the template is_convertible<From, To>, the following code shall
- be well formed:" To: "The template is_convertible<From, To> inherits either
- directly or indirectly from true_type if the following code is well formed:"<tr valign="top">
- <td width="29">
- UK 
- 207
-
- <td width="75">
- 20.5.6.1
-
- <td width="31">
- Table 36
-
- <td width="38">
- Ed
-
- <td width="375">
- suffix "::type" is missing from the some of
- the examples.
-
- <td width="466">
- Change:
- Example:remove_const<const volatile int>::type
- evaluates to volatile int, whereas remove_const<const
- int*> is const int*. —end example To:
- Example:remove_const<const volatile int>::type
- evaluates to volatile int, whereas remove_const<const
- int*>::type is const int*. —end example And
- change: Example:remove_volatile<const volatile
- int>::type evaluates to const int, whereas
- remove_volatile<volatile int*> is volatile int*.
- —end example To: Example:remove_volatile<const
- volatile int>::type evaluates to const int, whereas
- remove_volatile<volatile int*>::type is volatile
- int*. —end example And change:
- Example:remove_cv<const volatile int>::type evaluates
- to int, whereas remove_cv<const volatile int*> is
- const volatile int*. —end example To:
- Example:remove_cv<const volatile int>::type evaluates
- to int, whereas remove_cv<const volatile int*>::type
- is const volatile int*. —end example
-
- 
-
- <td width="225">
- 
-
- We tend to agree. Forward to project editor. Also recommend that the word
- "is" be replaced with "evaluates to" in the same text.<tr valign="top">
- <td width="29">
- JP 37
-
- <td width="75">
- 20.5.7
-
- <td width="31">
- Table 41
-
- <td width="38">
- ed
-
- <td width="375">
- 
- Typo.
-
- There isn't a
- period at the end of enable_if's comments.
-
- 
- 
-
- If
- B is true, the member typedef type shall equal T;
- otherwise, there shall be no member typedef type
-
- 
- 
-
- 
- should be
-
- 
- 
-
- If
- B is true, the member typedef type shall equal T;
- otherwise, there shall be no member typedef type.
-
- 
-
- <td width="466">
- Add
- ”.”
-
- <td width="225">
- 
-
- Agree. Forward to project editor.<tr valign="top">
- <td width="29">
- US 70
-
- <td width="75">
- 20.6
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- Specifications now expressed via narrative text are more
- accurately and clearly expressed via executable code.
-
- <td width="466">
- Wherever
- concepts are available that directly match this
- section’s type traits, express the traits in terms of
- the concepts instead of via narrative text. Where the type
- traits do not quite match the corresponding concepts, bring
- the two into alignment so as to avoid two nearly-identical
- notions.
-
- 
-
- <td width="225">
- 
-
- (The correct reference is section 20.5, not 20.6) We think that this is a
- good idea, but it requires a lot of work. If someone submits a paper
- proposing specific changes, we would be happy to review it at the next
- meeting.<tr valign="top">
- <td width="29">
- US 71
-
- <td width="75">
- 20.6.7
-
- <td width="31">
- Table 51, last row, column 3
-
- <td width="38">
- ed
-
- <td width="375">
- The grammar is incorrect.
-
- <td width="466">
- Change “conversion are” to “conversion
- is”.
-
- <td width="225">
- 
-
- (The correct reference is section 20.5.7, table 41, last row). Agree:
- Forward to project editor. There are several ways to fix the grammar.<tr valign="top">
- <td width="29">
- JP 38
-
- <td width="75">
- 20.6.12.1.3
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- 
- add the move requirement for bind's return type. 
- 
-
- 
- For example, assume following th1 and th2,
-
- 
- 
- void f(vector<int> v) { } 
- 
- vector<int> v{ ... }; 
- thread th1([v]{ f(v); }); 
- thread th2(bind(f, v)); 
- 
- When function object are set to thread, v is moved to th1's
- lambda expression in a Move Constructor of lambda
- expression becuase th1's lambda expression has a Move
- Constructor. But bind of th2's return type doesn't have the
- requirement of Move, so it may not moved but copied.
-
- Add
- the requirement of move to get rid of this useless copy.
-
- And also, add
- the MoveConstructible as well as CopyConstructible.
-
- 
- 
-
- <td width="466">
- Add
- the following requirements. 
- "it has a public move constructor
- that performs a member-wise move."
-
- Add
- the MoveConstructible.
-
- <td width="225">
- 
-
- We were not clear about what the submitter really intended. Requiring that
- the result of bind be MoveConstructible?
- and/or CopyConstructible?
- might be a start, but we would like to communicate with the submitter.
- [NOTE: We would like to see a clarification of the wording for Returnable<t>
- that makes it clear that move-only types can be Returnable.] </t>
-
- <tr valign="top">
- <td width="29">
- JP 39
-
- <td width="75">
- 20.6.16.2
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- 
- There are no requires corresponding to F of std::function.
-
- <td width="466">
- 
- Correct as follows.
-
- 
- template<class F, Allocator A>
- function(allocator_arg_t, const A&, F);
-
- 
- template<class F, Allocator A>
- function(allocator_arg_t, const A&, F&&);
-
- 
- 
-
- should be
-
- 
- 
-
- 
- template<class F, Allocator A>
-
- 
- requires CopyConstructible<F> &&
- Callable<F, ArgTypes...>
-
- 
- && Convertible<Callable<F,
- ArgTypes...>::result_type, R>
-
- 
- function(allocator_arg_t, const A&, F);
-
- 
- template<class F, Allocator A>
-
- 
- requires CopyConstructible<F> &&
- Callable<F, ArgTypes...>
-
- 
- && Convertible<Callable<F,
- ArgTypes...>::result_type, R>
-
- 
- function(allocator_arg_t, const A&, F&&);
-
- 
-
- <td width="225">
- 
-
- Agree with one correction: CopyConstructible?
- should be ConstructibleWithAllocator?
- . Pablo to supply wording. Also check with Howard that omission was not
- deliberate.<tr valign="top">
- <td width="29">
- JP 40
-
- <td width="75">
- 20.6.16.2
-
- <td width="31">
- 
-
- <td width="38">
- ed
-
- <td width="375">
- 
- Thougn it's "Allocator Aloc" at other places, it's
- "Allocator A" only std::function constructor template
- parameter.
-
- <td width="466">
- 
- Correct as follows.
-
- 
- template<class F, Allocator A>
- function(allocator_arg_t, const A&, F);
-
- 
- template<class F, Allocator A>
- function(allocator_arg_t, const A&, F&&);
-
- 
- 
-
- should be
-
- 
- 
-
- 
- template<class F, Allocator Alloc>
- function(allocator_arg_t, const Alloc &, F);
-
- 
- template<class F, Allocator Alloc>
- function(allocator_arg_t, const Alloc &,
- F&&);
-
- 
- 
-
- <td width="225">
- 
-
- Agree, though minor. Forward to project editor (who may disregard).<tr valign="top">
- <td width="29">
- JP 41
-
- <td width="75">
- 20.6.16.2
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- 
- There are no requires corresponding to R and Args of
- UsesAllocator.
-
- <td width="466">
- 
- Correct as follows.
-
- 
- template <class R, class... Args>
-
- 
- concept_map UsesAllocator<function<R(Args...)>,
- Alloc> {
-
- 
- typedef Alloc allocator_type;
-
- }
-
- 
- 
-
- should be
-
- 
- 
-
- 
- template <Returnable R,
- CopyConstructible... Args>
-
- 
- concept_map UsesAllocator<function<R(Args...)>,
- Alloc> {
-
- 
- typedef Alloc allocator_type;
-
- }
-
- <td width="225">
- 
-
- This change would be redundant because function<> is already sufficiently
- constrained. No actions necessary.<tr valign="top">
- <td width="29">
- JP 42
-
- <td width="75">
- 20.6.16.2
-
- <td width="31">
- 
-
- <td width="38">
- ed
-
- <td width="375">
- The requires
- are wrong.
-
- R
- require Returnable, and ArgTypes requires CopyConstructible
- by a definition of function, then it's a mistake to
- designate followings by MoveConstructible.
-
- <td width="466">
- 
- Correct as follows.
-
- 
- 
-
- 
- template <MoveConstructible R, MoveConstructible...
- ArgTypes>
-
- 
- bool operator==(const function<R(ArgTypes...)>&,
- nullptr_t);
-
- 
- template <MoveConstructible R, MoveConstructible...
- ArgTypes>
-
- 
- bool operator==(nullptr_t, const
- function<R(ArgTypes...)>&);
-
- 
- template <MoveConstructible R, MoveConstructible...
- ArgTypes>
-
- 
- bool operator!=(const function<R(ArgTypes...)>&,
- nullptr_t);
-
- 
- template <MoveConstructible R, MoveConstructible...
- ArgTypes>
-
- 
- bool operator!=(nullptr_t, const
- function<R(ArgTypes...)>&);
-
- 
- template <MoveConstructible R, MoveConstructible...
- ArgTypes>
-
- 
- void swap(function<R(ArgTypes...)>&,
- function<R(ArgTypes...)>&);
-
- 
- 
-
- should be
-
- 
- 
-
- 
- template <Returnable R,
- CopyConstructible... ArgTypes>
-
- 
- bool operator==(const function<R(ArgTypes...)>&,
- nullptr_t);
-
- 
- template <Returnable R,
- CopyConstructible... ArgTypes>
-
- 
- bool operator==(nullptr_t, const
- function<R(ArgTypes...)>&);
-
- 
- template <Returnable R,
- CopyConstructible... ArgTypes>
-
- 
- bool operator!=(const function<R(ArgTypes...)>&,
- nullptr_t);
-
- 
- template <Returnable R,
- CopyConstructible... ArgTypes>
-
- 
- bool operator!=(nullptr_t, const
- function<R(ArgTypes...)>&);
-
- 
- template <Returnable R,
- CopyConstructible... ArgTypes>
-
- void
- swap(function<R(ArgTypes...)>&,
- function<R(ArgTypes...)>&);
-
- 
- 
-
- <td width="225">
- 
-
- As with JP 41, these constraints are redundant given that function<> is
- already constrained. So we recommend changing each occurence of "MoveConstructible"
- to "class". Note: this issue is also present in func.wrap.func.nullptr.<tr valign="top">
- <td width="29">
- UK 
- 208
-
- <td width="75">
- 20.6.17
-
- <td width="31">
- 1
-
- <td width="38">
- Te
-
- <td width="375">
- std::hash should
- be implemented for much more of the standard library. In
- particular for pair, tuple and all the standard containers.
-
- 
-
- <td width="466">
- .
-
- <td width="225">
- 
-
- Consensus is that this is an expansion of the scope of C++0X and so we
- recommend no action.<tr valign="top">
- <td width="29">
- UK 
- 209
-
- <td width="75">
- 20.7
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- Smart pointers cannot be used in
- constrained templates
-
- <td width="466">
- Provide
- constraints for smart pointers
-
- 
-
- 
-
- <td width="225">
- 
-
- We look forward to a paper on this topic. We recommend no action until a
- paper is available. We understand that a paper is forthcoming.<tr valign="top">
- <td width="29">
- UK 
- 213
-
- <td width="75">
- 20.7.6
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- std::allocator
- should be constrained to simplify its use on constrained
- contexts. This library component models allocation from
- free store via the new operator so choose constraints to
- match. The Allocator concept allows for a wider variety of
- allocators that users may choose to supply if their
- allocation model does not require operator new, without
- impacting the requirements of this template.
-
- 
-
- <td width="466">
- The primary allocator template should be
- constrained to require ObjectType<T> and
- FreeStoreAllocatable<T>. Further operations to be
- constrained as required.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 214
-
- <td width="75">
- 20.7.8
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- 
- raw_storage_iterator needs constraining as an iterator
- adaptor to be safely used in constrained templates
-
- 
-
- <td width="466">
- Constrain the raw_storage_iterator template
-
- <td width="225">
- 
-
- We look forward to a paper on this topic. We recommend no action until a
- paper is available.<tr valign="top">
- <td width="29">
- UK 
- 210
-
- <td width="75">
- 20.7.11
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- Specialized algorithms for memory
- managenment need requirements to be easily usable in
- constrained templates
-
- <td width="466">
- Provide
- constraints for all algorithms in 20.7.11
-
- 
-
- 
-
- <td width="225">
- 
-
- We look forward to a paper on this topic. We recommend no action until a
- paper is available.<tr valign="top">
- <td width="29">
- DE-20
-
- <td width="75">
- 20.7.12
-
- <td width="31">
- 
-
- <td width="38">
- ed
-
- <td width="375">
- DE-20 The section heading and the first sentence use the
- term "template function", which is undefined.
-
- <td width="466">
- Replace
- "template function" by "function template".
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- US 72
-
- <td width="75">
- 20.7.12
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- 
- bind should support move-only functors and bound arguments.
-
- 
-
- <td width="466">
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- DE-21
-
- <td width="75">
- 20.7.12.1.3
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- DE-21 The specification for bind claims twice that "the
- values and types for the bound arguments v1, v2, ..., vN
- are determined as specified below". No such specification
- appears to exist.
-
- <td width="466">
- Add the missing specification in the same section, or
- add a cross-reference indicating the section where the
- specification appears.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 211
-
- <td width="75">
- 20.7.12.2.3
-
- <td width="31">
- 11
-
- <td width="38">
- Te
-
- <td width="375">
- The nullptr_t
- type was introduced to resolve the null pointer literal
- problem. It should be used for the assignemnt operator, as
- with the constructor and elsewhere through the library.
-
- 
-
- <td width="466">
- Change signature here and in the synopsis
- to: unique_ptr& operator=(nullptr_t); Strike the
- sentance an note before the Effects clause.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 212
-
- <td width="75">
- 20.7.13.7
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- The
- pointer-safety API is nothing to do with smart pointers, so
- does not belong in 20.7.13. In fact it is a set of language
- support features are really belongs in clause 18, with the
- contents declared in a header that deals with
- language-support of memory management.
-
- 
-
- <td width="466">
- Move this specification to 18.5. Move the
- declarations into the header <new>.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- DE-22
-
- <td width="75">
- 20.7.16.2
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- DE-22 The conditions for deriving from
- std::unary_function and std::binary_function are unclear:
- The condition would also be satisfied if ArgTypes were
- std::vector<T1>, because it (arguably) "contains" T1.
-
- <td width="466">
- Consider stating the conditions in normative prose
- instead of in comments in the class definition. Use
- "consists of" instead of "contains". Consider using "if and
- only if" instead of "iff".
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- US 73
-
- <td width="75">
- 20.7.18
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- The
- std::reference_closure template is redundant with
- std::function and should be removed.
-
- 
-
- 
- std::reference_closure is a premature optimization that
- provides a limited subset of the functionality of
- std::function intended to improve performance in a narrow
- use case. However, the “parallel application
- performance” benchmark used to motivate the inclusion
- of std::reference_closure was flawed in several ways:
-
- <ol start="3">
- <li>
- it failed to
- enable a common optimization in std::function
- (implemented by all vendors), exacting a large and
- unrealistic penalty for copying std::function
- instances, and
-
- <li>
- it failed to
- account for parallel scheduler overhead or
- realistically-sized work units, both of which would
- dominate the costs measured by the benchmark in any
- realistic application.
- </ol>
-
- 
-
- <td width="466">
- Remove 20.7.18
- [func.referenceclosure].
-
- 
-
- Remove 5.1.1 paragraph 12.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- US 74
-
- <td width="75">
- 20.8
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- Scoped
- allocators represent a poor trade-off for standardization,
- since (1) scoped-allocator--aware containers can be
- implemented outside the C++ standard library but used with
- its algorithms, (2) scoped allocators only benefit a tiny
- proportion of the C++ community (since few C++ programmers
- even use today’s allocators), and (3) all C++ users,
- especially the vast majority of the C++ community that
- won’t ever use scoped allocators are forced to cope
- with the interface complexity introduced by scoped
- allocators. In essence, the larger community will suffer to
- support a very small subset of the community who can
- already implement their own data structures outside of the
- standard library. Therefore, scoped allocators should be
- removed from the working paper.
-
- Some evidence of
- the complexity introduced by scoped allocators:
-
- 20.3.3, 20.5:
- large increase in the number of pair and tuple constructors
-
- 23: confusing
- “AllocatableElement” requirements throughout.
-
- 
-
- <td width="466">
- Remove support
- for scoped allocators from the working paper. This includes
- at least the following changes:
-
- 
-
- Remove 20.8.3
- [allocator.element.concepts]
-
- 
-
- Remove 20.8.7
- [allocator.adaptor]
-
- 
-
- Remove 20.8.10
- [construct.element]
-
- 
-
- In Clause 23:
- replace requirements naming the AllocatableElement concept
- with requirements naming CopyConstructible,
- MoveConstructible, DefaultConstructible, or Constructible,
- as appropriate.
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- US 74
-
- <td width="75">
- 20.8.2.2
-
- <td width="31">
- (a) synopsis (b) after ¶ 14
-
- <td width="38">
- te/ed
-
- <td width="375">
- A concept name is twice misspelled.
-
- <td width="466">
- Change “Hasconstructor” to
- “HasConstructor” (twice).
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- US 75
-
- <td width="75">
- 20.8.2.2
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- Allocator concepts are incomplete
-
- <td width="466">
- See paper:
- http://www.halpernwightsoftware.com/WG21/n2810_allocator_defects.pdf
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 43
-
- <td width="75">
- 20.8.3
-
- <td width="31">
- 
-
- <td width="38">
- ed
-
- <td width="375">
- 
- Typo.
-
- 
- "alloc" should be "Alloc"
-
- <td width="466">
- 
- Correct as follows.
-
- 
- 
-
- 
- auto concept UsesAllocator<typename T, typename
- Alloc> {
-
- 
- requires Allocator<alloc>;
-
- 
- typename allocator_type = T::allocator_type;
-
- 
-  
-
- 
- should be
-
-  
-
- 
- auto concept UsesAllocator<typename T, typename
- Alloc> {
-
- 
- requires Allocator<Alloc>;
-
- typename
- allocator_type = T::allocator_type;
-
- 
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 215
-
- <td width="75">
- 20.8.3.3
-
- <td width="31">
- 6,8
-
- <td width="38">
- Ed
-
- <td width="375">
- Extra pair of
- {}, presumably some formatting code gone awry :
- duration& operator-{-}();
-
- 
-
- <td width="466">
- Remove the {} or fix formatting
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- US 77
-
- <td width="75">
- 20.8.4
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- 
- Allocator-specific move and copy behavior for containers
- (N2525) complicates a little-used and already-complicated
- portion of the standard library (allocators), and breaks
- the conceptual model of move-constructor and
- move-assignment operations on standard containers being
- efficient operations. The extensions for allocator-specific
- move and copy behavior should be removed from the working
- paper.
-
- With the
- introduction of rvalue references, we are teaching
- programmers that moving from a standard container (e.g., a
- vector<string>) is an efficient, constant-time
- operation. The introduction of N2525 removed that
- guarantee; depending on the behavior of four different
- traits (20.8.4), the complexity of copy and move operations
- can be constant or linear time. This level of customization
- greatly increases the complexity of standard containers,
- and benefits only a tiny fraction of the C++ community.
-
- 
-
- <td width="466">
- Remove 20.8.4.
-
- 
-
- Remove 20.8.5.
-
- 
-
- Remove all references to the facilities in
- 20.8.4 and 20.8.5 from clause 23.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- US 78
-
- <td width="75">
- 20.8.12, 
- 20.8.13.2
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- There is presently no way to
- convert directly from a <code>shared_ptr</code> to a
- <code>unique_ptr</code>.
-
- <td width="466">
- Add
- an interface that performs the conversion. See the
- attached, Issues with the C++ Standard" paper under Chapter
- 20, "Conversion from <code>shared_ptr</code> to
- <code>unique_ptr".</code>
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- US 79
-
- <td width="75">
- 20.8.12.2.1
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- 
- [unique.ptr.single.ctor]/5 no longer requires for D not to
- be a pointer type.  This restriction needs to be put
- back in.  Otherwise we have a run time failure that
- could have been caught at compile time:
-
- 
- 
-
- 
- unique_ptr<int, void(*)(void*)>
- p(malloc(sizeof(int)));  // should not compile
-
- 
- 
-
- 
- unique_ptr<int, void(*)(void*)>
- p(malloc(sizeof(int)), free);  // ok
-
- 
-
- <td width="466">
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 44
-
- <td width="75">
- 20.8.13.6
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- The
- 1st parameter p and 2nd parameter v is now
- shared_ptr<T> *.
-
- It
- should be shared_ptr<T>&, or if these are
- shared_ptr<T>* then add the "p shall not be a null
- pointer" at the requires.
-
- <td width="466">
- 
- Change shared_ptr<T>& or add the "p shall not be
- a null pionter" at the requires.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 45
-
- <td width="75">
- 20.9
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- 
- Rep, Period, Clock and Duration don't correspond to
- concept.
-
- 
- template <class Rep, class Period = ratio<1>>
- class duration;
-
- template
- <class Clock, class Duration = typename
- Clock::duration> class time_point;
-
- 
- 
-
- <td width="466">
- 
- Make concept for Rep, Period, Clock and Duration, and fix
- 20.9 and wait_until and wait_for's template parameter at
- 30.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- US 80
-
- <td width="75">
- 20.9.2.1
-
- <td width="31">
- Heading
-
- <td width="38">
- ed
-
- <td width="375">
- The section heading does not describe the contents.
-
- <td width="466">
- Change the
- heading “is_floating_point” to
- “treat_as_floating_point”. Optionally
- adjust the section’s label similarly.
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- US 81
-
- <td width="75">
- 20.9.3
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- 
- chrono::duration is missing the modulous operator for both
- member and non-member arithmetic. This operator is useful
- for finding the position of a duration within a bounded
- time frame. Having it be built in to duration is safer than
- requiring the client to extract and operate directly on the
- duration’s representation as the latter will not
- enforce the correct units of the operation.
-
- 
- 
-
- Ex:
-
- 
- 
-
- 
- milliseconds ms(...);
-
- 
- microseconds us(...);
-
- 
- 
-
- ms
- % us; // microseconds
-
- us
- % ms; // microseconds
-
- ms
- % 5; // milliseconds
-
- 5 %
- ms; // does not compile
-
- 
-
- <td width="466">
- Add:
-
- 
-
- 
- template <class Rep, class Period = ratio<1>>
-
- 
- class duration {
-
- 
- public:
-
- ...
-
- duration&
- operator%(const rep&);
-
- duration&
- operator%(const duration&);
-
- ..
-
- };
-
- 
-
- template
- <class Rep1, class Period,
-
- class Rep2>
-
- 
- duration<typename common_type<
-
- Rep1,
- Rep2>::type, Period>
-
- operator%(const
- duration<Rep1, Period>& d, const Rep2& s);
-
- 
-
- template
- <class Rep1, class Period1,
-
- class Rep2,
- class Period2>
-
- typename
- common_type<duration<Rep1, Period1>,
- duration<Rep2, Period2>>::type
-
- operator%(const
- duration<Rep1, Period1>& lhs, const
- duration<Rep2, Period2>& rhs);
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- US 82
-
- <td width="75">
- 20.9.5.3
-
- <td width="31">
- after ¶ 1
-
- <td width="38">
- ed
-
- <td width="375">
- The code synopsis has a minor alignment error.
-
- <td width="466">
- Align “rep” with the other symbols defined
- in this synopsis.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 216
-
- <td width="75">
- 21
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- All the containers use concepts for their
- iterator usage, exect for basic_string. This needs fixing.
-
- <td width="466">
- Use concepts for iterator template
- parameters throughout the chapter.
-
- <td width="225">
- 
-
- NB comments to be handled by Dave Abrahams and Howard Hinnant with advice
- from PJP: UK216 (which duplicates) JP46, JP48. JP46 supplies extensive
- proposed wording; start there.<tr valign="top">
- <td width="29">
- JP 46
-
- <td width="75">
- 21.2, 21.3
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- The
- basic_string does not use concept.
-
- <td width="466">
- The
- "class Alloc" is changed to "Allocator Alloc".
-
- The
- "class InputIterator" is changed to "InputIterator Iter".
-
- 
- 
-
- //
- 21.3, basic_string:
-
- 
- template<class charT, class traits =
- char_traits<charT>,
-
- 
- Allocator Alloc = allocator<charT> >
-
- 
- class basic_string;
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- basic_string<charT,traits,Alloc>
-
- 
- operator+(const
- basic_string<charT,traits,Alloc>& lhs,
-
- 
- const basic_string<charT,traits,Alloc>&
- rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- basic_string<charT,traits,Alloc>&&
-
- 
- operator+(basic_string<charT,traits,Alloc>&&
- lhs,
-
- 
- const basic_string<charT,traits,Alloc>&
- rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- basic_string<charT,traits,Alloc>&&
-
- 
- operator+(const
- basic_string<charT,traits,Alloc>& lhs,
-
- 
- basic_string<charT,traits,Alloc>&&
- rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- basic_string<charT,traits,Alloc>&&
-
- 
- operator+(basic_string<charT,traits,Alloc>&&
- lhs,
-
- 
- basic_string<charT,traits,Alloc>&&
- rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- basic_string<charT,traits,Alloc>
-
- 
- operator+(const charT* lhs,
-
- 
- const basic_string<charT,traits,Alloc>&
- rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- basic_string<charT,traits,Alloc>&&
-
- 
- operator+(const charT* lhs,
-
- 
- basic_string<charT,traits,Alloc>&&
- rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- basic_string<charT,traits,Alloc>
-
- 
- operator+(charT lhs, const
- basic_string<charT,traits,Alloc>& rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- basic_string<charT,traits,Alloc>&&
-
- 
- operator+(charT lhs,
- basic_string<charT,traits,Alloc>&&
- rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- basic_string<charT,traits,Alloc>
-
- 
- operator+(const
- basic_string<charT,traits,Alloc>& lhs,
-
- 
- const charT* rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- basic_string<charT,traits,Alloc>&&
-
- 
- operator+(basic_string<charT,traits,Alloc>&&
- lhs,
-
- 
- const charT* rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- basic_string<charT,traits,Alloc>
-
- 
- operator+(const
- basic_string<charT,traits,Alloc>& lhs,
- charT rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- basic_string<charT,traits,Alloc>&&
-
- 
- operator+(basic_string<charT,traits,Alloc>&&
- lhs, charT rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- bool operator==(const
- basic_string<charT,traits,Alloc>& lhs,
-
- 
- const basic_string<charT,traits,Alloc>&
- rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- bool operator==(const charT* lhs,
-
- 
- const basic_string<charT,traits,Alloc>&
- rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- bool operator==(const
- basic_string<charT,traits,Alloc>& lhs,
-
- 
- const charT* rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- bool operator!=(const
- basic_string<charT,traits,Alloc>& lhs,
-
- 
- const basic_string<charT,traits,Alloc>&
- rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- bool operator!=(const charT* lhs,
-
- 
- const basic_string<charT,traits,Alloc>&
- rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- bool operator!=(const
- basic_string<charT,traits,Alloc>& lhs,
-
- 
- const charT* rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- bool operator< (const
- basic_string<charT,traits,Alloc>& lhs,
-
- 
- const basic_string<charT,traits,Alloc>&
- rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- bool operator< (const
- basic_string<charT,traits,Alloc>& lhs,
-
- 
- const charT* rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- bool operator< (const charT* lhs,
-
- 
- const basic_string<charT,traits,Alloc>&
- rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- bool operator> (const
- basic_string<charT,traits,Alloc>& lhs,
-
- 
- const basic_string<charT,traits,Alloc>&
- rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- bool operator> (const
- basic_string<charT,traits,Alloc>& lhs,
-
- 
- const charT* rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- bool operator> (const charT* lhs,
-
- 
- const basic_string<charT,traits,Alloc>&
- rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- bool operator<=(const
- basic_string<charT,traits,Alloc>& lhs,
-
- 
- const basic_string<charT,traits,Alloc>&
- rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- bool operator<=(const
- basic_string<charT,traits,Alloc>& lhs,
-
- 
- const charT* rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- bool operator<=(const charT* lhs,
-
- 
- const basic_string<charT,traits,Alloc>&
- rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- bool operator>=(const
- basic_string<charT,traits,Alloc>& lhs,
-
- 
- const basic_string<charT,traits,Alloc>&
- rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- bool operator>=(const
- basic_string<charT,traits,Alloc>& lhs,
-
- 
- const charT* rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- bool operator>=(const charT* lhs,
-
- 
- const basic_string<charT,traits,Alloc>&
- rhs);
-
- 
-  
-
- //
- 21.3.8.8: swap
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- void swap(basic_string<charT,traits,Alloc>& lhs,
-
- 
- basic_string<charT,traits,Alloc>& rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- void swap(basic_string<charT,traits,Alloc>&&
- lhs,
-
- 
- basic_string<charT,traits,Alloc>& rhs);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- void swap(basic_string<charT,traits,Alloc>& lhs,
-
- 
- basic_string<charT,traits,Alloc>&& rhs);
-
- 
-  
-
- //
- 21.3.8.9: inserters and extractors
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- basic_istream<charT,traits>&
-
- 
- operator>>(basic_istream<charT,traits>&&
- is,
-
- 
- basic_string<charT,traits,Alloc>& str);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- basic_ostream<charT, traits>&
-
- 
- operator<<(basic_ostream<charT,
- traits>&& os,
-
- 
- const basic_string<charT,traits,Alloc>&
- str);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- basic_istream<charT,traits>&
-
- 
- getline(basic_istream<charT,traits>&& is,
-
- 
- basic_string<charT,traits,Alloc>& str,
-
- 
- charT delim);
-
- 
-  
-
- 
- template<class charT, class traits, Allocator
- Alloc>
-
- 
- basic_istream<charT,traits>&
-
- 
- getline(basic_istream<charT,traits>&& is,
-
- 
- basic_string<charT,traits,Alloc>& str);
-
- 
-  
-
- 
- 
-
- //
- 21.3 Class template basic_string
-
- 
- namespace std {
-
- 
- template<class charT, class traits =
- char_traits<charT>,
-
- 
- Allocator Alloc = allocator<charT> >
-
- 
- class basic_string {
-
- 
- public:
-
- //
- types:
-
- 
- typedef traits traits_type;
-
- 
- typedef typename traits::char_type value_type;
-
- 
- typedef Alloc allocator_type;
-
- 
- typedef typename Alloc::size_type size_type;
-
- 
- typedef typename Alloc::difference_type
- difference_type;
-
- 
- typedef typename Alloc::reference reference;
-
- 
- typedef typename Alloc::const_reference
- const_reference;
-
- 
- typedef typename Alloc::pointer pointer;
-
- 
- typedef typename Alloc::const_pointer const_pointer;
-
- 
- typedef implementation-defined iterator; // See 23.1
-
- 
- typedef implementation-defined const_iterator; // See 23.1
-
- 
- typedef std::reverse_iterator<iterator>
- reverse_iterator;
-
- 
- typedef std::reverse_iterator<const_iterator>
- const_reverse_iterator;
-
- 
- static const size_type npos = -1;
-
- 
-  
-
- //
- 21.3.2 construct/copy/destroy:
-
- 
- explicit basic_string(const Alloc& a =
- Alloc());
-
- 
- basic_string(const basic_string& str);
-
- 
- basic_string(basic_string&& str);
-
- 
- basic_string(const basic_string& str, size_type pos,
- size_type n = npos,
-
- 
- const Alloc& a = Alloc());
-
- 
- basic_string(const charT* s,
-
- 
- size_type n, const Alloc& a = Alloc());
-
- 
- basic_string(const charT* s, const Alloc& a =
- Alloc());
-
- 
- basic_string(size_type n, charT c, const Alloc&
- a = Alloc());
-
- 
- template<InputIterator Iter>
-
- 
- basic_string(Iter begin, Iter end,
-
- 
- const Alloc& a = Alloc());
-
- 
- basic_string(initializer_list<charT>, const
- Alloc& = Alloc());
-
- 
- basic_string(const basic_string&, const
- Alloc&);
-
- 
- basic_string(basic_string&&, const
- Alloc&);
-
- 
- ~basic_string();
-
- 
- basic_string& operator=(const basic_string& str);
-
- 
- basic_string& operator=(basic_string&& str);
-
- 
- basic_string& operator=(const charT* s);
-
- 
- basic_string& operator=(charT c);
-
- 
- basic_string& operator=(initializer_list<charT>);
-
- 
-  
-
- //
- 21.3.3 iterators:
-
- ...
-
- 
-  
-
- //
- 21.3.4 capacity:
-
- ...
-
- 
-  
-
- //
- 21.3.5 element access:
-
- ...
-
- 
-  
-
- //
- 21.3.6 modifiers:
-
- ...
-
- 
-  
-
- 
- basic_string& append(const basic_string& str);
-
- 
- basic_string& append(const basic_string& str,
- size_type pos,
-
- 
- size_type n);
-
- 
- basic_string& append(const charT* s, size_type n);
-
- 
- basic_string& append(const charT* s);
-
- 
- basic_string& append(size_type n, charT c);
-
- 
- template<InputIterator Iter>
-
- 
- basic_string& append(Iter first, Iter
- last);
-
- 
- basic_string& append(initializer_list<charT>);
-
- 
- void push_back(charT c);
-
- 
-  
-
- 
- basic_string& assign(const basic_string& str);
-
- 
- basic_string& assign(basic_string&& str);
-
- 
- basic_string& assign(const basic_string& str,
- size_type pos,
-
- 
- size_type n);
-
- 
- basic_string& assign(const charT* s, size_type n);
-
- 
- basic_string& assign(const charT* s);
-
- 
- basic_string& assign(size_type n, charT c);
-
- 
- template<InputIterator Iter>
-
- 
- basic_string& assign(Iter first, Iter
- last);
-
- 
- basic_string& assign(initializer_list<charT>);
-
- 
-  
-
- 
- basic_string& insert(size_type pos1, const
- basic_string& str);
-
- 
- basic_string& insert(size_type pos1, const
- basic_string& str,
-
- 
- size_type pos2, size_type n);
-
- 
- basic_string& insert(size_type pos, const charT* s,
- size_type n);
-
- 
- basic_string& insert(size_type pos, const charT* s);
-
- 
- basic_string& insert(size_type pos, size_type n, charT
- c);
-
- 
- iterator insert(const_iterator p, charT c);
-
- 
- void insert(const_iterator p, size_type n, charT c);
-
- 
- template<InputIterator Iter>
-
- 
- void insert(const_iterator p, Iter first,
- Iter last);
-
- 
- void insert(const_iterator p,
- initializer_list<charT>);
-
- 
-  
-
- ...
-
- 
- basic_string& replace(size_type pos1, size_type n1,
-
- 
- const basic_string& str);
-
- 
- basic_string& replace(size_type pos1, size_type n1,
-
- 
- const basic_string& str,
-
- 
- size_type pos2, size_type n2);
-
- 
- basic_string& replace(size_type pos, size_type n1,
- const charT* s,
-
- 
- size_type n2);
-
- 
- basic_string& replace(size_type pos, size_type n1,
- const charT* s);
-
- 
- basic_string& replace(size_type pos, size_type n1,
- size_type n2,
-
- 
- charT c);
-
- 
- basic_string& replace(iterator i1, iterator i2,
-
- 
- const basic_string& str);
-
- 
- basic_string& replace(iterator i1, iterator i2, const
- charT* s,
-
- 
- size_type n);
-
- 
- basic_string& replace(iterator i1, iterator i2, const
- charT* s);
-
- 
- basic_string& replace(iterator i1, iterator i2,
-
- 
- size_type n, charT c);
-
- 
- template<InputIterator Iter>
-
- 
- basic_string& replace(iterator i1, iterator i2,
-
- 
- Iter j1, Iter j2);
-
- 
- basic_string& replace(iterator, iterator,
- initializer_list<charT>);
-
- 
-  
-
- ...
-
- 
-  
-
- //
- 21.3.7 string operations:
-
- ...
-
- 
-  
-
- 
- template <class charT, class traits, Allocator
- Alloc>
-
- 
- struct constructible_with_allocator_suffix<
-
- 
- basic_string<charT, traits, Alloc> > :
- true_type { };
-
- 
- 
-
- <td width="225">
- 
-
- See UK 216<tr valign="top">
- <td width="29">
- JP 47
-
- <td width="75">
- 21.3
-
- <td width="31">
- 
-
- <td width="38">
- ed
-
- <td width="375">
- 
- Typo. Missing ”>”
-
- 
- template <class charT, class traits, Allocator Alloc
-
- 
- 
-
- 
- should be
-
- 
- 
-
- 
- template <class charT, class traits, Allocator Alloc>
-
- 
-
- <td width="466">
- 
- Correct typo.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 48
-
- <td width="75">
- 21.3
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- 
- char_traits does not use concept.
-
- For
- example, create CharTraits concept and change as follows:
-
- 
- 
-
- 
- template<class charT, CharTraits traits =
- char_traits<charT>,
-
- 
- class Allocator = allocator<charT> >
-
- class
- basic_string {
-
- 
- 
-
- <td width="466">
- Add
- a concept for char_traits.
-
- <td width="225">
- 
-
- See UK 216<tr valign="top">
- <td width="29">
- UK 
- 217
-
- <td width="75">
- 21.3
-
- <td width="31">
- 
-
- <td width="38">
- Ed
-
- <td width="375">
- basic_string refers to
- constructible_with_allocator_suffix, which I thought was
- removed?
-
- <td width="466">
- Remove the
- lines: template <class charT, class traits, class Alloc
- struct constructible_with_allocator_suffix<
- basic_string<charT, traits, Alloc> > : true_type {
- };
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 218
-
- <td width="75">
- 21.3.1
-
- <td width="31">
- 3
-
- <td width="38">
- Te
-
- <td width="375">
- The identity
- "&*(s.begin() + n) == &*s.begin() + n" relies on
- operator& doing the "right thing", which (AFAICS) there
- is no requirement for. See my comment under clauses
- "23.2.1, 23.2.6" (p1 in both cases) - this is the same
- issue, but I've created a separate comment for basic_string
- because it is in a different chapter.
-
- 
-
- <td width="466">
- See my recommendations for "23.2.1,
- 23.2.6".
-
- <td width="225">
- 
-
- NAD, we think. basic_string elements have to be POD and PODs may not have
- overloaded operator&. Need to check whether this is true in light of relaxed
- POD constraints.<tr valign="top">
- <td width="29">
- UK 
- 219
-
- <td width="75">
- 21.3.6.6 
- [string. 
- replace]
-
- <td width="31">
- 11
-
- <td width="38">
- Ed
-
- <td width="375">
- Effects refers to "whose first begin() - i1
- elements" However i1 is greater than begin()...
-
- <td width="466">
- Effects refers to "whose first i1 - begin()
- elements"
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 220
-
- <td width="75">
- 21.3.8.9
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- The
- operator<< for basic_string takes the output stream
- by r-value reference. This is different from the same
- operator for error_code (19.4.2.6), bitset (20.2.6.3),
- shared_ptr (20.7.13.2.8), complex (26.3.6) and sub_match
- (28.4)
-
- 
-
- <td width="466">
- Use the same reference type for the all the
- library types. This should be the r-value reference. There
- are other places in the standard where TR1, and new
- classes, did not receive an 'R-value' update.
-
- <td width="225">
- 
-
- We did it differently for basic_string because otherwise rvalue strreaming
- was producing confusing results with strings, but this difference will be
- fixed by N2831 if it's accepted.<tr valign="top">
- <td width="29">
- FR 33
-
- <td width="75">
- 22.1.1 
- [locale]
-
- <td width="31">
- 3
-
- <td width="38">
- ed
-
- <td width="375">
- ios_base::iostate err = 0;
-
- 
-
- iostate is a bitmask type and
- so could be an enumeration. Probably using
-
- goodbit is the solution.
-
- <td width="466">
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 49
-
- <td width="75">
- 22.1.3.2.2
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- 
- codecvt does not use concept. For example, create
- CodeConvert concept and change as follows.
-
- 
- template<CodeConvert Codecvt, class Elem =
- wchar_t> class wstring_convert {
-
- <td width="466">
- Add
- a concept for codecvt.
-
- <td width="225">
- 
-
- to be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plaugher<tr valign="top">
- <td width="29">
- JP 50
-
- <td width="75">
- 22.1.3.2.2
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- Add
- custom allocator parameter to wstring_convert, since we
- cannot allocate memory for strings from a custom allocator.
-
- <td width="466">
- 
- Correct as follows.
-
- 
- template<class Codecvt, class Elem = wchar_t> class
- wstring_convert {
-
- 
- public:
-
- 
- typedef std::basic_string<char> byte_string;
-
- 
- typedef std::basic_string<Elem> wide_string;
-
- 
-  
-
- should be
-
- 
-  
-
- 
- template<class Codecvt, class Elem = wchar_t,
-
- 
- Allocator WideAllocator = allocator<Elem>,
-
- 
- Allocator ByteAllocator = allocator<char>>
-
- 
- class wstring_convert {
-
- 
- public:
-
- 
- typedef std::basic_string<char,
- char_traits<char>, ByteAllocator>
- byte_string;
-
- typedef
- std::basic_string<Elem, char_traits<Elem>,
- WideAllocator> wide_string;
-
- 
- 
-
- <td width="225">
- 
-
- to be handled by PJ Plaugher<tr valign="top">
- <td width="29">
- FI 4
-
- <td width="75">
- 22.2.1.4.1
-
- 22.2.1.4.2
-
- <td width="31">
- 
-
- <td width="38">
- ed
-
- <td width="375">
- <tt>to_end and to_limit are both used. Only one is
- needed.</tt>
-
- <td width="466">
- Change to_limit to to_end.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- FI 5
-
- <td width="75">
- <tt>22.2.1.4.2</tt>
-
- <td width="31">
- #3
-
- <td width="38">
- ed
-
- <td width="375">
- <tt>[ Note: As
- a result of operations on state, it can return ok or
- partial and set next == from and to_next != to. —end
- note ]</tt> 
- 
- 
-
- <tt>"next"
- should be "from_next."</tt>
-
- <tt>Also, the
- sentence applies to all the examples, including do_in and
- do_out.</tt>
-
- <tt>Reasoning: When reading one element of multibyte
- source data such as UTF-8, it is possible that from_next is
- incremented, to_next is unaltered, state is altered and
- return value is partial. 
- When reading one element of wide character data, the output
- can be several multibyte characters, so it is possible that
- from_next is unaltered, to_next is advanced, state is
- altered and return value is partial.</tt>
-
- <td width="466">
- <tt>[ Note: As a result of operations on state, do_in
- and do_out can return</tt> 
- <tt>ok or partial and set from_next == from and/or to_next
- != to. —end</tt> 
- <tt>note ]</tt>
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- FI 6
-
- <td width="75">
- 22.2.1.5
-
- See also 
- 22.2.1.4 
- (1,2,3)
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- 
- <tt>codecvt_byname is only specified to work with locale
- names. There is no built-in means to find a codecvt with a
- character set's name. A locale and a character set are not
- the same. If the user has data which is encoded in a
- certain character set and she wants to create a codecvt
- which can convert from that character set to another one,
- she must iterate through locales to find one, or use
- external means (iconv, ICU's uconv). Specifying a locale
- with the character set is not a suitable solution, since
- there is no built-in mapping from character sets to
- locales. It is only possible to inquire the character set
- once the locale is known.</tt>
-
- 
-
- <td width="466">
- <tt>There should be a built-in means to find a codecvt
- with a pair of character set names.</tt>
-
- <td width="225">
- 
-
- Martin Sebor interested in solving this problem (also POSIX group), but
- addressing it controversial because it's probably too late in the process
- for what looks like a new feature.<tr valign="top">
- <td width="29">
- FI 7
-
- <td width="75">
- 22.2.1.4
-
- <td width="31">
- 1,2,3
-
- <td width="38">
- ed
-
- <td width="375">
- The word
- "codeset" is used, whereas the word "character set" is used
- elsewhere in the text. The words are intended to convey the
- same concept, so only one should be used (or always both
- together).
-
- 
-
- <td width="466">
- Change "codeset" to "character set."
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 51
-
- <td width="75">
- 22.2.5.1.1
-
- <td width="31">
- 7th para, 1st
- line
-
- <td width="38">
- ed
-
- <td width="375">
- A
- parameter `end’ should be `fmtend’. 
- get() function had two `end’ parameters at N2321.
-
- 
- iter_type get (iter_type s, iter_type end, ios_base& f,
- ios_base::iostate& err, tm* t, const char_type* fmt,
- const char_type *end) const;
-
- The function
- prototype of get() has been corrected at N2800, but a
- Requires statement still refers `end’ parameter.
-
- 
- 
-
- <td width="466">
- 
- Correct as follows.
-
- 
- Requires: [fmt,end) shall be a valid range.
-
- 
- 
-
- 
- should be
-
- 
- 
-
- 
- Requires: [fmt,fmtend) shall be a valid range.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 52
-
- <td width="75">
- 22.2.5.1, 
- 22.2.5.2, 
- 22.2.6.1
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- 
- InputIterator does not use concept.
-
- <td width="466">
- 
- Correct as follows.
-
- 
- 
-
- 
- 22.2.5.1
-
- 
-  
-
- 
- template <class charT, class InputIterator =
- istreambuf_iterator<charT> >
-
- 
- class time_get : public locale::facet, public time_base {
-
- 
- public:
-
- 
- typedef charT char_type;
-
- 
- typedef InputIterator iter_type;
-
- 
-  
-
- 
- should be
-
- 
-  
-
- 
- template <class charT, InputIterator InputIter =
- istreambuf_iterator<charT> >
-
- 
- class time_get : public locale::facet, public time_base {
-
- 
- public:
-
- 
- typedef charT char_type;
-
- 
- typedef InputIter iter_type;
-
- 
-  
-
- 
-  
-
- 
- 22.2.5.2
-
- 
-  
-
- 
- template <class charT, class InputIterator =
- istreambuf_iterator<charT> >
-
- 
- class time_get_byname : public time_get<charT,
- InputIterator> {
-
- 
- public:
-
- 
- typedef time_base::dateorder dateorder;
-
- 
- typedef InputIterator iter_type;
-
- 
-  
-
- 
- should be
-
- 
-  
-
- 
- template <class charT, InputIterator InputIter =
- istreambuf_iterator<charT> >
-
- 
- class time_get_byname : public time_get<charT,
- InputIter> {
-
- 
- public:
-
- 
- typedef time_base::dateorder dateorder;
-
- 
- typedef InputIter iter_type;
-
- 
-  
-
- 
-  
-
- 
- 22.2.6.1
-
- 
-  
-
- 
- template <class charT,
-
- 
- class InputIterator = istreambuf_iterator<charT> >
-
- 
- class money_get : public locale::facet {
-
- 
- public:
-
- 
- typedef charT char_type;
-
- 
- typedef InputIterator iter_type;
-
- 
-  
-
- 
- should be
-
- 
-  
-
- 
- template <class charT,
-
- 
- InputIterator InputIter =
- istreambuf_iterator<charT> >
-
- 
- class money_get : public locale::facet {
-
- 
- public:
-
- 
- typedef charT char_type;
-
- 
- typedef InputIter iter_type;
-
- 
-
- <td width="225">
- 
-
- to be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plaugher<tr valign="top">
- <td width="29">
- JP 53
-
- <td width="75">
- 22.2.5.3 , 
- 22.2.5.4
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- 
- OutputIterator does not use concept.
-
- <td width="466">
- 
- Correct as follows.
-
- 
-  
-
- 
- 22.2.5.3
-
- 
-  
-
- 
- template <class charT, class OutputIterator =
- ostreambuf_iterator<charT> >
-
- 
- class time_put : public locale::facet {
-
- 
- public:
-
- 
- typedef charT char_type;
-
- 
- typedef OutputIterator iter_type;
-
- 
-  
-
- 
- 　should be
-
- 
-  
-
- 
- template <class charT, OutputIterator OutputIter
- = ostreambuf_iterator<charT> >
-
- 
- class time_put : public locale::facet {
-
- 
- public:
-
- 
- typedef charT char_type;
-
- 
- typedef OutputIter iter_type;
-
- 
-  
-
- 
-  
-
- 
- 22.2.5.4
-
- 
-  
-
- 
- template <class charT, class OutputIterator =
- ostreambuf_iterator<charT> >
-
- 
- class time_put_byname : public time_put<charT,
- OutputIterator>
-
- {
-
- 
- public:
-
- 
- typedef charT char_type;
-
- 
- typedef OutputIterator iter_type;
-
- 
-  
-
- 
- should be
-
- 
-  
-
- 
- template <class charT, OutputIterator OutputIter
- = ostreambuf_iterator<charT> >
-
- 
- class time_put_byname : public time_put<charT,
- OutputIter>
-
- {
-
- 
- public:
-
- 
- typedef charT char_type;
-
- typedef OutputIter
- iter_type;
-
- <td width="225">
- 
-
- to be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plaugher<tr valign="top">
- <td width="29">
- JP 54
-
- <td width="75">
- 23
-
- <td width="31">
- 
- 2nd para, Table 79
-
- 
-
- <td width="38">
- ed
-
- <td width="375">
- 
- There is not <forward_list> in Table 79.
-
- <td width="466">
- Add
- <forward_list> between <deque> and
- <list>.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 221
-
- <td width="75">
- 23
-
- <td width="31">
- Table 79
-
- <td width="38">
- Ed
-
- <td width="375">
- The table is missing the new
- <forward_list> header.
-
- <td width="466">
- Add
- <forward_list> to the table for sequence containers.
- Alternative (technical) solution might be to merge
- <forward_list> into <list>.
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 222
-
- <td width="75">
- 23
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- It is not clear
- what purpose the Requirement tables serve in the Containers
- clause. Are they the definition of a library Container? Or
- simply a conventient shorthand to factor common semantics
- into a single place, simplifying the description of each
- subsequent container? This becomes an issue for
- 'containers' like array, which does not meet the
- default-construct-to-empty requirement, or forward_list
- which does not support the size operation. Are these
- components no longer containers? Does that mean the
- remaining requirements don't apply? Or are these
- contradictions that need fixing, despite being a clear
- design decision?
-
- 
-
- <td width="466">
- Clarify all the tables in 23.1 are there as
- a convenience for documentation, rather than a strict set
- of requirements. Containers should be allowed to relax
- specific requirements if they call attention to them in
- their documentation. The introductory text for array should
- be expanded to mention a default constructed array is not
- empty, and forward_list introduction should mention it does
- not provide the required size operation as it cannot be
- implemented efficiently.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 55
-
- <td width="75">
- 23.1.1
-
- <td width="31">
- 
- 3rd para, 4th line
-
- 
-
- <td width="38">
- ed
-
- <td width="375">
- It
- seems that “the MinimalAllocator concep” is the
- typo of “the MinimalAllocator concept”.
-
- <td width="466">
- 
- Change to … models the MinimalAllocator
- concept.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 223
-
- <td width="75">
- 23.1.1
-
- <td width="31">
- 3
-
- <td width="38">
- Te
-
- <td width="375">
- The library does
- not define the MinimalAllocator or ScopedAllocator
- concepts, these were part of an earlier Allocators proposal
- that was rejected.
-
- 
-
- <td width="466">
- Remove the references to MinimalAllocator
- and ScopedAllocator, or add definitions for these concepts
- to clause 20.7.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 224
-
- <td width="75">
- 23.1.1
-
- <td width="31">
- 8
-
- <td width="38">
- Te
-
- <td width="375">
- This paragraph implicitly requires all
- containers in clause 23 to support allocators, which
- std::array does not.
-
- <td width="466">
- Add an 'unless
- otherwise specified' rider somewhere in p8, or move the
- whole array container from clause 23 [containers] to clause
- 20 [utilies] to accompany bitset, pair and tuple.
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 225
-
- <td width="75">
- 23.1.1
-
- <td width="31">
- Table 81
-
- <td width="38">
- Ed
-
- <td width="375">
- Inconsistent
- words used to say the same thing. Table 80 describes
- iterator/const_iterator typedef as returning an "iterator
- type whose value type is T". Table 81 expresses the same
- idea as an "iterator type pointing to T". Express identical
- ideas with the same words to avoid accidentally introducing
- subtlety and confusion
-
- 
-
- <td width="466">
- Change return types for
- X::(const)_reverse_iterator to say "iterator type whose
- value type is (const) T".
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 226
-
- <td width="75">
- 23.1.1
-
- <td width="31">
- 10
-
- <td width="38">
- Te
-
- <td width="375">
- <array>
- must be added to this list. In particular it doesn't
- satisfy: - no swap() function invalidates any references,
- pointers, or iterators referring to the elements of the
- containers being swapped. and probably doesn't satisfy:
- — no swap() function throws an exception.
-
- 
-
- <td width="466">
- If <array> remains a container, this
- will have to also reference array, which will then have to
- say which of these points it satisfies.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 227
-
- <td width="75">
- 23.1.1
-
- <td width="31">
- Table 80
-
- <td width="38">
- Ed
-
- <td width="375">
- The post-condition for a = rv uses the word
- “construction” when it means
- “assignment”
-
- <td width="466">
- Replace the word
- “construction” with the word
- “assignment”
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 228
-
- <td width="75">
- 23.1.1
-
- <td width="31">
- 3
-
- <td width="38">
- Ed
-
- <td width="375">
- Line 4 contains
- a spelling mistake in the fragment "MinimalAllocator
- concep."
-
- 
-
- <td width="466">
- Replace "concep" with "concept"
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 229
-
- <td width="75">
- 23.1.1
-
- <td width="31">
- 3
-
- <td width="38">
- Ed
-
- <td width="375">
- The fragment "A container may directly call
- constructors" is not technically correct as constructors
- are not callable.
-
- <td width="466">
- Replace "A
- container may directly call constructors and destructors
- for its stored objects" with something similar to "A
- container may directly construct its stored objects and
- call destructors for its stored objects"
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 230
-
- <td width="75">
- 23.1.2
-
- <td width="31">
- 1
-
- <td width="38">
- Te
-
- <td width="375">
- 
- “implementations shall consider the following
- functions to be const” - what does this mean? I don't
- understand what it means by implementations considering the
- functions to be const – surely they are either
- declared const or not?
-
- 
-
- <td width="466">
- Clarify what is meant and what requirements
- an implementation must satisfy.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 56
-
- <td width="75">
- 23.1.3
-
- <td width="31">
- 12th para, Table 84
-
- <td width="38">
- ed
-
- <td width="375">
- 
- `array’ is unstated in Table 84 - Optional sequence
- container operations.
-
- <td width="466">
- Add
- `array’ to Container field for the following
- Expression.
-
- a.front()
-
- a.back()
-
- a[n]
-
- a.at(n)
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 231
-
- <td width="75">
- 23.1.3
-
- <td width="31">
- 9-11
-
- <td width="38">
- Te
-
- <td width="375">
- These paragraphs
- are redundant now that Concepts define what it means to be
- an Iterator and guide overload resolution accordingly.
-
- 
-
- <td width="466">
- Strike 23.1.3p9-11. Make sure
- std::basic_string has constraints similar to std::vector to
- meet this old guarantee.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 232
-
- <td width="75">
- 23.1.3
-
- <td width="31">
- Table 84
-
- <td width="38">
- Te
-
- <td width="375">
- match_results
- may follow the requirements but is not listed a general
- purpose library container.
-
- 
-
- <td width="466">
- Remove reference to match_results against
- a[n] operation
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 233
-
- <td width="75">
- 23.1.3
-
- <td width="31">
- Table 84
-
- <td width="38">
- Te
-
- <td width="375">
- Add references to the new containers.
-
- <td width="466">
- Add reference to
- array to the rows for: a.front(), a. back(), a[n] a.at(n).
- Add reference to forward_list to the rows for: a.front(),
- a.emplace_front(args), a.push_front(t), a.push_front(rv),
- a.pop_front(). Add reference to basic_string to the row
- for: a.at(n).
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 234
-
- <td width="75">
- 23.1.3
-
- <td width="31">
- Table 84
-
- <td width="38">
- Te
-
- <td width="375">
- Ther reference
- to iterator in semantics for back should also allow for
- const_iterator when called on a const-qualified container.
- This would be ugly to specify in the 03 standard, but is
- quite easy with the addition of auto in this new standard.
-
- 
-
- <td width="466">
- Replace iterator with auto in semantics for
- back: { auto tmp = a.end(); --tmp; return *tmp; }
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 235
-
- <td width="75">
- 23.1.3
-
- <td width="31">
- 1
-
- <td width="38">
- Ed
-
- <td width="375">
- “The library provides three basic
- kinds of sequence containers: vector, list, and
- deque” - text appears to be out of date re addition
- of array and forward_list
-
- <td width="466">
- Change the text
- to read: “The library provides five basic kinds of
- sequence containers: array, deque, forward_list, list and
- vector”.
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 236
-
- <td width="75">
- 23.1.3
-
- <td width="31">
- 2
-
- <td width="38">
- Ed
-
- <td width="375">
- [ I've moved (1)
- into a separate comment because I believe it is editorial
- in the simple sense, whereas (2) and (3) are not so
- straight forward ] (2) “vector is the type of
- sequence container that should be used by default” --
- As I understand it vector was considered first port of call
- because the things it has in common with the native array
- make programmers (especially those new to the container
- library) feel like they are on familiar territory. However,
- we now have the array container, so I think this should be
- recommended as the first port of call. (3) This paragraph
- is actually giving guidance on the use of the containers
- and should not be normative text
-
- 
-
- <td width="466">
- Remove this paragraph
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 237
-
- <td width="75">
- 23.1.3
-
- <td width="31">
- 2
-
- <td width="38">
- Ed
-
- <td width="375">
- vector, list, and deque offer the
- programmer different complexity trade-offs and should be
- used accordingly - this ignores array and forward_list
-
- <td width="466">
- Modify the text
- to read: "array, deque, forward_list, list and vector offer
- the programmer different complexity trade-offs and should
- be used accordingly"
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 238
-
- <td width="75">
- 23.1.4
-
- <td width="31">
- 6
-
- <td width="38">
- Te
-
- <td width="375">
- Leaving it
- unspecified whether or not iterator and const_iterator are
- the same type is dangerous, as user code may or may not
- violate the One Definition Rule by providing overloads for
- both types. It is probably too late to specify a single
- behaviour, but implementors should document what to expect.
- Observing that problems can be avoided by users restricting
- themselves to using const_iterator, add a note to that
- effect.
-
- 
-
- <td width="466">
- Change 'unspecified' to 'implementation
- defined'. Add "[Note: As itererator and const_iterator have
- identical semantics in this case, and iterator is
- convertible to const_iterator, users can avoid violating
- the One Definition Rule by always using const_iterator in
- their function parameter lists -- end note]
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 239
-
- <td width="75">
- 23.1.4
-
- <td width="31">
- 85
-
- <td width="38">
- Te
-
- <td width="375">
- It is not possible to take a move-only key
- out of an unordered container, such as (multi)set or
- (multi)map, or the new hashed containers.
-
- <td width="466">
- Add below
- a.erase(q), a.extract(q), with the following notation:
- a.extract(q), Return type pair<key, iterator>
- Extracts the element pointed to by q and erases it from the
- set. Returns a pair containing the value pointed to by q
- and an iterator pointing to the element immediately
- following q prior to the element being erased. If no such
- element exists,returns a.end().
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 240
-
- <td width="75">
- 23.1.6.1
-
- <td width="31">
- 12
-
- <td width="38">
- Te
-
- <td width="375">
- The axiom
- EmplacePushEquivalence should be asserting the stronger
- contract that emplace and insert return the same iterator
- value, not just iterators that dereference to the same
- value. This is a similar statement that is easier to
- express and should be equivalent - the idea that insert and
- emplace might return iterator values that do not compare
- equal but point to the same element should fail somewhere
- in the iterator concepts. Also, this axiom should be
- renamed to reflect its connection with insert, rather than
- push_front/push_back,
-
- 
-
- <td width="466">
- Remove the * to deference the returned
- iterator either side of the == in the
- EmplacePushEquivalence axiom, rename the axiom
- EmplacementInsertionEquivalence : requires
- InsertionContainer<C> &&
- Constructible<value_type, Args...> axiom
- EmplacementInsertionEquivalence(C c, const_iterator
- position, Args... args) { emplace(c, position, args...) ==
- insert(c, position, value_type(args...)); }
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 57
-
- <td width="75">
- 23.1.6.3
-
- <td width="31">
- 
- 1st para, 4th line
-
- 
-
- <td width="38">
- ed
-
- <td width="375">
- 
- Typo, duplicated "to"
-
- 
- "to to model insertion container concepts."
-
- <td width="466">
- 
- Remove one.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 241
-
- <td width="75">
- 23.2.1
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- std::array does
- not have an allocator, so need to document an exception to
- the requirements of 23.1.1p3
-
- 
-
- <td width="466">
- add exception to 23.1.1p3
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 242
-
- <td width="75">
- 23.2.1
-
- <td width="31">
- 3
-
- <td width="38">
- Ed
-
- <td width="375">
- std:: qualification no longer needed for
- reverse_iterator.
-
- <td width="466">
- remove std::
- qualification from std::reverse_iterator<iterator>
- and std::reverse_iterator<const_iterator>
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 243
-
- <td width="75">
- 23.2.1
-
- <td width="31">
- 3
-
- <td width="38">
- Te
-
- <td width="375">
- Most containers,
- and types in general have 3 swaps: swap(T&, T&)
- swap(T&&, T&) swap(T&, T&&) But
- array only has swap(T&, T&).
-
- 
-
- <td width="466">
- add the other two swaps.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 244
-
- <td width="75">
- 23.2.1, 
- 23.2.6
-
- <td width="31">
- 1
-
- <td width="38">
- Te
-
- <td width="375">
- The validity of
- the expression &a[n] == &a[0] + n is contingent on
- operator& doing the “right thing” (as
- captured by the CopyConstructible requirements in table 30
- in C++2003). However this constraint has been lost in the
- Concepts of C++0x. This applies to vector and array (it
- actually applies to string also, but that's a different
- chapter, so I'll file a separate comment there and
- cross-reference).
-
- 
-
- <td width="466">
- Define a ContiguousStrorage and apply it to
- vector,array and string. The Concept (supplied by Alisdair
- M) looks like this: Concept< typename C >
- ContiguousStrorage { requires Container<C>; typename
- value_type = C::value_type; value_type * data( C ); axiom
- Contiguous { C c; true = equal_ranges( data( c), data(c) +
- size(c), begin(c)); } };
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 245
-
- <td width="75">
- 23.2.3
-
- <td width="31">
- 2
-
- <td width="38">
- Te
-
- <td width="375">
- The predicate types used in special member
- function of forward_list should be CopyConstructible, as
- per the algorithms of the same name. Note: an alternate
- solution would be to require these callable concepts to be
- CopyConstructible in clause 20, which would simplify the
- library specification in general. See earlier comment for
- details, that would render this one redundant.
-
- <td width="466">
- Add
- CopyConstructible requirement to the following signatures:
- template <Predicate<auto, T> Pred> requires
- CopyConstructible<Pred> void remove_if(Pred pred);
- template <EquivalenceRelation<auto, T>
- BinaryPredicate> requires
- CopyConstructible<BinaryPredicate> void
- unique(BinaryPredicate binary_pred); template
- <StrictWeakOrder<auto, T> Compare> requires
- CopyConstructible<Compare> void
- merge(forward_list<T,Alloc>&& x, Compare
- comp); template <StrictWeakOrder<auto, T>
- Compare> requires CopyConstructible<Compare> void
- sort(Compare comp);
-
- 
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 58
-
- <td width="75">
- 23.2.3.2
-
- <td width="31">
- 
- 1st line
- before 1st para
-
- 
-
- <td width="38">
- ed
-
- <td width="375">
- 
- Unnecessary "{" exists before a word iterator like
- "{iterator before_begin()".
-
- <td width="466">
- 
- Remove "{"
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 59
-
- <td width="75">
- 23.2.4.4
-
- <td width="31">
- 
-
- <td width="38">
- ed
-
- <td width="375">
- 
- Types of the third and forth parameter of splice() are
- iterator at 23.2.4.4, though types of them are
- const_iterator at 23.2.4. (They are both const_iterator on
- N2350)
-
- <td width="466">
- 
- Correct as follows.
-
- 
- void splice(const_iterator position,
- list<T,Allocator>&& x, iterator i);
-
- 
- void splice(const_iterator position,
- list<T,Allocator>&& x,
-
- 
- iterator first, iterator last);
-
- 
- 
-
- 
- should be
-
- 
- 
-
- 
- void splice(const_iterator position,
- list<T,Allocator>&& x, const_iterator i);
-
- 
- void splice(const_iterator position,
- list<T,Allocator>&& x,
-
- const_iterator
- first, const_iterator last);
-
- 
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- US 83
-
- <td width="75">
- 23.2.6.2
-
- <td width="31">
- 7
-
- <td width="38">
- ed
-
- <td width="375">
- 
- "shrink_to_fint" should be "shrink_to_fit".
-
- 
- 
-
- 
-
- <td width="466">
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 246
-
- <td width="75">
- 23.3.2.2
-
- <td width="31">
- 
-
- <td width="38">
- Ed
-
- <td width="375">
- The content of
- this sub-clause is purely trying to describe in words the
- effect of the requires clauses on these operations, now
- that we have Concepts. As such, the desctiption is more
- confusing than the signature itself. The semantic for these
- functions is adequately covered in the requirements tables
- in 23.1.4.
-
- 
-
- <td width="466">
- Strike 23.3.2.2 entirely. (but do NOT
- strike these signatures from the class template
- definition!)
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 247
-
- <td width="75">
- 24.1
-
- <td width="31">
- 
-
- <td width="38">
- Ge
-
- <td width="375">
- Iterator
- concepts are not extensive enough to merit a whole new
- header, and should be merged into <concpts>. This is
- particularly important for supporting the new for loop
- syntax which requires access to the Range concept. The
- required header to enable this syntax shoud have a simple
- name, like <concepts>, rather than something awkward
- to type like <iterator_concepts>.
-
- 
-
- <td width="466">
- Move the concepts of
- <iterator_concepts> into the <concepts> header.
- We take no position on moving the text from Clause 24 to
- Clause 20 though.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 248
-
- <td width="75">
- 24.1
-
- <td width="31">
- 6
-
- <td width="38">
- Ed
-
- <td width="375">
- The text "so for
- any iterator type there is an iterator value that points
- past the last element of a corresponding container" is
- slightly misleading. Iterators can refer into generalised
- ranges and sequences, not just containers. A broader term
- than 'container' should be used.
-
- 
-
- <td width="466">
- Replace the reference to container with a
- more appropriate concept
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 250
-
- <td width="75">
- 24.1.1
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- A default implementation should be supplied
- for the post-increment operator to simplify implementation
- of iterators by users.
-
- <td width="466">
- Copy the Effects clause into the concept
- description as the default implementation. Assumes a
- default value for postincrement_result
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 251
-
- <td width="75">
- 24.1.1
-
- <td width="31">
- 3
-
- <td width="38">
- Te
-
- <td width="375">
- The
- post-increment operator is dangerous for a general
- InputIterator. The multi-pass guarantees that make it
- meaningful are defined as part of the ForwardIterator
- refinement. Any change will affect only constrained
- templates that have not yet been written, so should not
- break existing user iterators which remain free to add
- these operations. This change will also affect the
- generalised OutputIterator, although there is no percieved
- need for the post-increment operator in this case either.
-
- 
-
- <td width="466">
- Move declaration of postincrement operator
- and postincrement_result type from Interator concept to the
- ForwardIterator concept
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 252
-
- 
-
- <td width="75">
- 24.1.2
-
- <td width="31">
- 3
-
- <td width="38">
- Ed
-
- <td width="375">
- istream_iterator is not a class, but a
- class template
-
- <td width="466">
- Change 'class' to 'class template' in the
- note.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 253
-
- <td width="75">
- 24.1.3
-
- <td width="31">
- 1
-
- <td width="38">
- Ed
-
- <td width="375">
- First sentance
- does not make gramatical sense, Seems to be missing the
- words 'if it' by comparison with similar sentance in other
- subsections
-
- 
-
- <td width="466">
- Add the words 'if it' : "X satisfies the
- requirements of an output iterator IF IT meets the
- syntactic and semantic requirements"
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 254
-
- <td width="75">
- 24.1.3
-
- <td width="31">
- 5
-
- <td width="38">
- Te
-
- <td width="375">
- This
- postcondition for pre-increment operator should be written
- as an axiom
-
- 
-
- <td width="466">
- Move the postcondition into the concept
- definition as an axiom
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 255
-
- <td width="75">
- 24.1.4
-
- <td width="31">
- 4
-
- <td width="38">
- Te
-
- <td width="375">
- This
- postcondition for pre-increment operator should be written
- as an axiom
-
- 
-
- <td width="466">
- Move the postcondition into the concept
- definition as an axiom
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 256
-
- <td width="75">
- 24.1.5
-
- <td width="31">
- 3, 4, 5
-
- <td width="38">
- Te
-
- <td width="375">
- The relationship between pre- and post-
- decrement should be expressed as an axiom.
-
- <td width="466">
- Move the text
- specification of pre/post-conditions and behaviour into an
- axiom within the BidirectionalIterator concept
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 257
-
- <td width="75">
- 24.1.5
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- There is a
- reasonable default for postdecrement_result type, which is
- X. X is required to be regular, therefore CopyConstructible
- and a valid ResultType. Together with the next comment this
- simplifies user defined iterator implentations
-
- 
-
- <td width="466">
- Add the default : typename
- postincrement_result = X;
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 258
-
- <td width="75">
- 24.1.5
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- A default
- implementation should be supplied for the post-decrement
- operator to simplify implementation of iterators by users.
-
- 
-
- <td width="466">
- Copy the Effects clause into the concept
- description as the default implementation. Assumes a
- default value for postincrement_result
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 259
-
- <td width="75">
- 24.1.5
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- 
- postdecrement_result is effectively returning a copy of the
- original iterator value, so should have similar
- constraints, rather than just HasDereference. If Concepts
- do not support this circularity of definition suggest that
- concepts feature may want a little more work
-
- 
-
- <td width="466">
- Add the requirement: requires Iterator<
- postdecrement_result >;
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 260
-
- <td width="75">
- 24.1.5
-
- <td width="31">
- 6
-
- <td width="38">
- Te
-
- <td width="375">
- The effects clause for post-decrement
- iterator should be available as an axiom and a default
- implementation, where the compiler can make better use of
- it.
-
- <td width="466">
- Move the Effects
- clause into the BidirectionalIterator concept definition as
- an axiom, and as the default implementation for the
- operation.
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 249
-
- <td width="75">
- 24.1.6
-
- <td width="31">
- 2
-
- <td width="38">
- Te
-
- <td width="375">
- The semantic for
- operator+= should also be provided as a default
- implementation to simplify implementation of user-defined
- iterators
-
- 
-
- <td width="466">
- Copy the text from the effects clause into
- the RandomAccessIterator concept as the default
- implementaiton.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 261
-
- <td width="75">
- 24.1.6
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- To simplify user
- defined random access iterator types, the
- subscript_reference type should default to reference
-
- 
-
- <td width="466">
- typename subscript_reference = reference;
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 262
-
- <td width="75">
- 24.1.6
-
- <td width="31">
- 3, 4
-
- <td width="38">
- Te
-
- <td width="375">
- Effects and post-conditions for operator+
- are more useful if expressed as axioms, and supplied as
- default implementations.
-
- <td width="466">
- Move the effects
- and Postcondition definitions into the RandomAccessIterator
- concept and copy the code in the specification as the
- default implementation of these operations.
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 263
-
- <td width="75">
- 24.1.6
-
- <td width="31">
- 5
-
- <td width="38">
- Te
-
- <td width="375">
- This requirement on operator-= would be
- better expressed as a default implementation in the
- concept, with a matching axiom
-
- <td width="466">
- Move the
- specification for operator-= from the returns clause into
- an axiom and default implementation within the
- RandomAccessIterator concept
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 264
-
- <td width="75">
- 24.1.6
-
- <td width="31">
- 6
-
- <td width="38">
- Te
-
- <td width="375">
- Effects clauses are better expressed as
- axioms where possible.
-
- <td width="466">
- Move code in
- operator- effects clause into RandomAccessIterator concept
- as both a default implementation and an axiom
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 265
-
- <td width="75">
- 24.1.6
-
- <td width="31">
- 8
-
- <td width="38">
- Te
-
- <td width="375">
- This effects
- clause is nonesense. It looks more like an axiom stating
- equivalence, and certainly an effects clause cannot change
- the state of two arguments passed by const reference
-
- 
-
- <td width="466">
- Strike the Effects clause
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 266
-
- <td width="75">
- 24.1.6
-
- <td width="31">
- 9
-
- <td width="38">
- Te
-
- <td width="375">
- This sentance should be provided as a
- default definition, along with a matching axiom
-
- <td width="466">
- Move the Returns
- clause into the spefication for RandomAccessIterator
- operator- as a default implementation. Move the Effects
- clause as the matching axiom.
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 267
-
- <td width="75">
- 24.1.6
-
- <td width="31">
- 24.1.6
-
- <td width="38">
- Te
-
- <td width="375">
- The code in the
- Requires clause for RandomAccessIterator operator[] would
- be better expressed as an axiom.
-
- 
-
- <td width="466">
- Rewrite the Requires clause as an axiom in
- the RandomAccessIterator concept
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 268
-
- <td width="75">
- 24.1.6
-
- <td width="31">
- 12
-
- <td width="38">
- Ed
-
- <td width="375">
- This note is
- potentialy confusing as __far enters the syntax as a clear
- language extension, but the note treats it as a regular
- part of the grammar. It might be better expressed using
- attributes in the current wording.
-
- 
-
- <td width="466">
- Clean up the note to either avoid using
- language extension, or spell out this is a constraint to
- support extensions.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 60
-
- <td width="75">
- 24.1.8
-
- <td width="31">
- 1st para
-
- <td width="38">
- te
-
- <td width="375">
- 
- Capability of an iterator is too much restricted by
- concept.
-
- 
- 
-
- 
- Concept of std::Range is defined as:
-
- 
- 
-
- 
- concept Range<typename T> {
-
- 
- InputIterator iterator;
-
- 
- iterator begin(T&);
-
- 
- iterator end(T&);
-
- }
-
- 
- 
-
- So
- the following code generates an error.
-
- 
- 
-
- 
- template <std::Range Rng>
-
- 
- void sort(Rng& r)
-
- {
-
- 
- // error! Rng::iterator does not satisfy requirements of a
- random
-
- 
- // access iterator.
-
- 
- std::sort(begin(r), end(r));
-
- }
-
- 
- 
-
- 
- std::vector<int> v; // vector::iterator is a random
- access iterator.
-
- 
- sort(v);
-
- 
- 
-
- 
- This is because the concept of an iterator of std::Range is
- InputIterator. For this reason, a random access iterator
- loses its capability when passed to a std::Range parameter.
-
- 
- 
-
- To
- be able to work the above code, we need to write as
- follows:
-
- 
- 
-
- 
- template <std::Range T>
-
- 
- requires std::RandomAccessIterator<T::iterator>
- &&
-
- 
- std::ShuffleIterator<T::iterator> &&
-
- 
- std::LessThanComparable<T::iterator::value_type>
-
- 
- void sort(T& r)
-
- {
-
- 
- sort(begin(r), end(r));
-
- }
-
- 
- 
-
- 
- std::vector<int> v;
-
- 
- sort(v);
-
- 
- 
-
- It
- needs quiet a few amount of codes like this only to recover
- random access capability from InputIterator concept.
-
- 
- 
-
- We
- can write the following valid code with Boost.Range, which
- is implemented with using C++03 SFINAE.
-
- 
- 
-
- 
- template <class Range>
-
- 
- void sort(Range& r)
-
- {
-
- 
- std::sort(boost::begin(r), boost::end(r));
-
- }
-
- 
- 
-
- 
- std::vector<int> v;
-
- 
- sort(v); // OK
-
- 
- 
-
- One of the
- motivation to introduce concepts are supporting template
- programming techniques by language directly to eliminate
- hacky techniques such as tag-dispatch, SFINAE and Type
- Traints. But SFINAE will be kept using because it needs
- quite a few amount of codes without using SFAINAE.
-
- 
- 
-
- <td width="466">
- Add
- InputRange, OutputRange, ForwardRange, BidirectionalRange
- and RandomAccessRange.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 269
-
- <td width="75">
- 24.3
-
- <td width="31">
- 3
-
- <td width="38">
- Ed
-
- <td width="375">
- 'decrements for
- negative n' seems to imply a negative number of decrement
- operations, which is odd.
-
- 
-
- <td width="466">
- Need simple, clearer wording
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 270
-
- <td width="75">
- 24.3
-
- <td width="31">
- 4
-
- <td width="38">
- Te
-
- <td width="375">
- The reachability
- constraint in p5 means that a negavite result, implying
- decrements operations in p4, is not possible
-
- 
-
- <td width="466">
- Split the two overloads into separate
- descriptions, where reachability is permitted to be in
- either direction for RandomAccessIterator
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 271
-
- <td width="75">
- 24.3
-
- <td width="31">
- 6,7
-
- <td width="38">
- Te
-
- <td width="375">
- next/prev return
- an incremented iterator without changing the value of the
- original iterator. However, even this may invalidate an
- InputIterator. A ForwardIterator is required to guarantee
- the 'multipass' property.
-
- 
-
- <td width="466">
- Replace InputIterator constraint with
- FOrwardIterator in next and prev function templates.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 272
-
- <td width="75">
- 24.4
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- reverse_iterator
- and move_iterator use different formulations for their
- comparison operations. move_iterator merely requires the
- minimal set of operations, < and ==, from its underlying
- iterator and synthesizes all oprations from these two.
- reverse_iterator relies on the undelying iterator to
- support all comparision operations directly. In practice,
- move_iterator can only be implemented this way as it must
- support iterator types that are merely InputIterators, and
- so SemiRegular and not Regular. However, reserse_iterator
- has an existing specification and any change of semantic
- could change behaviour of conforming programs today -
- although an iterator that yields different results for (a
- > b) than (b < a) may fall foul of some semantic
- consistency requirements, even if the syntax is met.
-
- 
-
- <td width="466">
- Rephrase the reverse_iterator comparison
- operations using only operators < and ==, as per the
- move_iterator specification.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 274
-
- <td width="75">
- 24.4, 24.5
-
- <td width="31">
- 
-
- <td width="38">
- Ed
-
- <td width="375">
- The subclauses
- for standard iterator adaptors could be better organised.
- There are essentially 3 kinds of iterator wrappers
- provided, stream iterators adapt streams and get their own
- subsection. insert iterators adapt containers, and get
- their own subsection but it is inserted into the middle of
- 24.4 Predifined iterators. reverse_iterator and
- move_iterator adpat other iterators, but their presentation
- is split by insert iterators
-
- 
-
- <td width="466">
- Promote 24.4.2 [insert.iterators] up one
- level to 24.6. Emphasize that insert iterators adapt
- containers Retarget 24.4 [predef.iterators] as iterator
- adapters for iterator templates that wrap other iterators.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 275
-
- <td width="75">
- 24.4.1.1
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- The constructor
- template taking a single Iterator argument will be selected
- for Copy Initialization instead of the non-template
- constructor taking a single Iterator argument selected by
- Direct Initialization.
-
- 
-
- <td width="466">
- The reverse_iterator template constructor
- taking a single Iterator argument should be explicit.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 276
-
- <td width="75">
- 24.4.1.1
-
- <td width="31">
- 
-
- <td width="38">
- Ed
-
- <td width="375">
- It is odd to
- have a mix of declaration stlyes for operator+ overloads.
- Prefer if either all are member functions, or all are
- 'free' functions.
-
- 
-
- <td width="466">
- Make the member operators taking a
- difference_type argument non-member operators
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 277
-
- <td width="75">
- 24.4.1.2.1
-
- <td width="31">
- 1
-
- <td width="38">
- Te
-
- <td width="375">
- The default
- constructor default-initializes current, rather than
- value-initializes. This means that when Iterator
- corresponds to a trivial type, the current member is left
- un-initialized, even when the user explictly requests value
- intialization! At this point, it is not safe to perform any
- operations on the reverse_iterator other than assign it a
- new value or destroy it. Note that this does correspond to
- the basic definition of a singular iterator.
-
- 
-
- <td width="466">
- i/ Specify value initialization rather than
- default intialization or ii/ specify = default; rather than
- spell out the semantic. This will at least allow users to
- select value initialization and copy the iterator value. or
- iii/ Add a note to the description emphasizing the singular
- nature of a value-initialized reserve iterator.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 278
-
- <td width="75">
- 24.4.1.2.1
-
- <td width="31">
- 3
-
- <td width="38">
- Te
-
- <td width="375">
- There is an
- inconsistency between the constructor taking an iterator
- and the constructor template taking a reverse_iterator
- where one passes by value, and the other by const
- reference. The by-value form is preferred as it allows for
- efficient moving when copy elision fails to kick in.
-
- 
-
- <td width="466">
- Change the const reverse_iterator
- & parameter to pass-by-value
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 279
-
- <td width="75">
- 24.4.1.2.12, 
- 24.4.3.2.12
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- The reason the
- return type became unspecified is LWG issue 386. This
- reasoning no longer applies as there are at least two ways
- to get the right return type with the new language
- facilities added since the previous standard.
-
- 
-
- <td width="466">
- Specify the return type using either
- decltype or the Iter concept map
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 280
-
- <td width="75">
- 24.4.1.2.4
-
- <td width="31">
- 
-
- <td width="38">
- Ed
-
- <td width="375">
- The presence of
- the second iterator value is surprising for many readers
- who underestimate the size of a reverse_iterator object.
- Adding the exposition only member that is required by the
- semantic will reduce confusion.
-
- 
-
- <td width="466">
- Add reverse_iterator expsoition only member
- tmp as a comment to class declaration, as a private member
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 281
-
- <td width="75">
- 24.4.1.2.5
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- The current
- specification for return value will always be a true
- pointer type, but reverse_iterator supports proxy iterators
- where the pointer type may be some kind of 'smart pointer'
-
- 
-
- <td width="466">
- Replace the existing returns specification
- with a copy of the operator* specification that returns
- this->tmp.operator->
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 282
-
- <td width="75">
- 24.4.2.1, 
- 24.4.2.2.2, 
- 24.4.2.3, 
- 24.4.2.4.2, 
- 24.4.2.5, 
- 24.4.2.6.2
-
- <td width="31">
- n/a
-
- <td width="38">
- Te
-
- <td width="375">
- Insert iterators of move-only types will
- move from lvalues
-
- <td width="466">
- Add an additional constrained overload for
- operator= that requires
- !CopyConstructible<Cont::value_type> and mark it
- =delete.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 283
-
- <td width="75">
- 24.4.2.5, 
- 24.4.2.6.4
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- postincrement operator overloads
- traditionally return by value - insert_iterator is declared
- as return by reference. The change is harmless in this
- case, but either front/back_insert_iterator should take the
- matching change for consistency, or this function should
- return-by-value
-
- <td width="466">
- change operator++(int) overload to return
- by value, not reference. Affects both class summary and
- operator definition in p
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 61
-
- <td width="75">
- 24.4.3.2.1
-
- <td width="31">
- 2nd para, 1st
- line
-
- <td width="38">
- ed
-
- <td width="375">
- 
- Typo.
-
- 
- "intializing" should be "initializing"
-
- <td width="466">
- Add
- "i"
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 284
-
- <td width="75">
- 24.5
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- The stream
- iterators need constraining with concepts/requrires
- clauses.
-
- 
-
- <td width="466">
- Provide constraints
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 285
-
- <td width="75">
- 24.5.1
-
- <td width="31">
- 1,2
-
- <td width="38">
- Ed
-
- <td width="375">
- Much of the
- content of p1 and the whole of p2 is a redundant
- redefinition of InputIterator. It should be simplified
-
- 
-
- <td width="466">
- Strike p2. Simplify p1 and add a
- cross-reference to the definition of InputIterator concept.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 286
-
- <td width="75">
- 24.5.1
-
- <td width="31">
- 3
-
- <td width="38">
- Ed
-
- <td width="375">
- To the casual
- reader it is not clear if it is intended to be able to
- assign to istream_iterator objects. Specifying the copy
- constructor but relying on the implicit copy-assign
- operator is confusing.
-
- 
-
- <td width="466">
- Either provide a similar definition to the
- copy-assign operator as for the copy constructor, or strike
- the copy constructor
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 287
-
- <td width="75">
- 24.5.1.1
-
- <td width="31">
- 2
-
- <td width="38">
- Te
-
- <td width="375">
- It is not clear
- what the intial state of an istream_iterator should be. Is
- _value_ initialized by reading the stream, or default/value
- initialized? If it is initialized by reading the stream,
- what happens if the initialization is deferred until first
- dereference, when ideally the iterator value should have
- been that of an end-of-stream iterator which is not safely
- dereferencable?
-
- 
-
- <td width="466">
- Specify _value_ is initialized by reading
- the stream, or the iterator takes on the end-of-stream
- value if the stream is empty
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 288
-
- <td width="75">
- 24.5.1.1
-
- <td width="31">
- 3
-
- <td width="38">
- Ed
-
- <td width="375">
- The provided specification is vacuous,
- offering no useful information.
-
- <td width="466">
- Either strike
- the specification of the copy constructor, or simply
- replace it with an = default definition.
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 289
-
- <td width="75">
- 24.5.1.2
-
- <td width="31">
- 6
-
- <td width="38">
- Ed
-
- <td width="375">
- It is very hard
- to pick up the correct specification for
- istream_iterator::operator== as the complete specification
- requires reading two quite disconnected paragraphs,
- 24.5.1p3, and 24.5.1.2p6. Reading just the specifaction of
- the operation itself suggests that end-of-stream iterators
- are indistinguishable from 'valid' stream iterators, which
- is a very dangerous misreading.
-
- 
-
- <td width="466">
- Merge 24.5.1p3, equality comparison of
- end-of-stream-iterators, into 24.5.1.2p6, the specification
- of the equality operator for istream_iterator.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 290
-
- <td width="75">
- 24.5.2
-
- <td width="31">
- 1
-
- <td width="38">
- Te
-
- <td width="375">
- The character
- type of a string delimiter for an ostream_iterator should
- be const charT *, the type of the elements, not char *, a
- narrow character string.
-
- 
-
- <td width="466">
- Replace char * with const charT *
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 291
-
- <td width="75">
- 24.5.2.2
-
- <td width="31">
- 2
-
- <td width="38">
- Te
-
- <td width="375">
- ostream_iterator
- postincrement operator returns by reference rather than by
- value. This may be a small efficiency gain, but it is
- otherwise unconventional. Prefer return-by-value.
-
- 
-
- <td width="466">
- ostream_iterator operator++(int);
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- FR 34
-
- <td width="75">
- 24.5.3 
- [istreambuf. 
- iterator]
-
- <td width="31">
- 
-
- <td width="38">
- ed
-
- <td width="375">
- There are two public
- sections, and the content of the second one is indented
- with respect to the first. I don't it should be.
-
- 
-
- <td width="466">
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 292
-
- <td width="75">
- 24.5.3
-
- <td width="31">
- 1
-
- <td width="38">
- Ed
-
- <td width="375">
- Prefer the use
- of the new nullptr constant to the zero literal when using
- a null pointer in text.
-
- 
-
- <td width="466">
- Change istreambuf_iterator(0) to
- istreambuf_iterator(nullptr)
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 293
-
- <td width="75">
- 24.5.3
-
- <td width="31">
- 2,3,4
-
- <td width="38">
- Ed
-
- <td width="375">
- The listed paragraphs redundantly redefine
- an input iterator, and redundancy can be a dangerous thing
- in a specification. Suggest a simpler phrasing below.
-
- <td width="466">
- 2. The result of
- operator*() on an end of stream is undefined. For any other
- iterator value a char_type value is returned. 3. Two end of
- stream iterators are always equal. An end of stream
- iterator is not equal to a non-end of stream iterator. 4.
- As istreambuf_iterator() is an InputIterator but not a
- ForwardIterator, istreambuf_iterators object can be used
- only for one-pass algorithms. It is not possible to assign
- a character via an input iterator.
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 294
-
- <td width="75">
- 24.5.3.2
-
- <td width="31">
- 2
-
- <td width="38">
- Te
-
- <td width="375">
- Implicit converting constructors can be
- invoked at surprising times, so there should always be a
- good reason for declaring one.
-
- <td width="466">
- Mark the two
- single-argument constructors take a stream or stream buffer
- as explicit. The proxy constructor should remain implicit.
- explicit
- istreambuf_iterator(basic_istream<charT,traits>&
- s) throw(); explicit
- istreambuf_iterator(basic_streambuf<charT,traits>* s)
- throw();
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 295
-
- <td width="75">
- 25
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- THere is a level
- of redundancy in the library specification for many
- algorithms that can be eliminated with the combination of
- concepts and default parameters for function templates.
- Eliminating redundancy simplified specification and reduces
- the risk of inttroducing accidental inconsistencies.
-
- 
-
- <td width="466">
- Adopt n2743, or an update of that paper.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 62
-
- <td width="75">
- 25, 25.3.1.5, 
- 26.3.6.5
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- 
- The return types of is_sorted_until function and
- is_heap_until function are iterator. But basically, the
- return type of is_xxx function is bool. And the return type
- of lower_bound function and upper_bound is iterator.
-
- 
- So we think that it is reasonable to change those two
- functions.
-
- 
-
- <td width="466">
- 
- Change "is_sorted_until" to "sorted_bound"
-
- 
- Change "is_heap" to "heap_bound"
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 296
-
- <td width="75">
- 25.1.8
-
- <td width="31">
- 1
-
- <td width="38">
- Te
-
- <td width="375">
- The 'Returns' of
- adjacent_find requires only HasEqualTo, or a Predicate.
- Requiring EqualityComparable or EquivalenceRelation seems
- too strong and not useful.
-
- 
-
- <td width="466">
- Change EqualityComparable to HasEqualTo and
- EquivalnceRelation to Predicate
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 297
-
- <td width="75">
- 25.2.11
-
- <td width="31">
- 6
-
- <td width="38">
- Ed
-
- <td width="375">
- The definition
- of rotate_copy is very complicated. It is equivalent to:
- return copy(first, middle, copy(middle, last, result));
-
- 
-
- <td width="466">
- Change 'effects' to, returns, requires,
- complexity to: effects: equivalent to: return copy(first,
- middle, copy(middle, last, result));
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 298
-
- <td width="75">
- 25.2.13
-
- <td width="31">
- 13
-
- <td width="38">
- Te
-
- <td width="375">
- partition_point requires a partitioned
- array
-
- <td width="466">
- requires: is_partitioned(first, last, pred)
- != false;
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 299
-
- <td width="75">
- 25.2.2
-
- <td width="31">
- 
-
- <td width="38">
- Ed
-
- <td width="375">
- Should be consistent in style use of
- concepts in template parameter lists. The
- auto-OutputIterator sytle used in std::copy is probably
- preferred.
-
- <td width="466">
- Change way signature is declared:
- template<InputIterator InIter, OutputIterator<auto,
- RvalueOf<InIter::reference>::type> OutIter>
- OutIter move(InIter first, InIter last, OutIter result);
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 300
-
- <td width="75">
- 25.2.3
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- Since publishing
- the original standard, we have learned that swap is a
- fundamental operation, and several common idioms rely on it
- - especially those related to exception safety. As such it
- belongs in the common <utility> header rather than
- the broader <algorithm> header, and likewise should
- move to clause 20. For backwards compatiblility the
- algorithm header should be required to #include
- <utility>, which would be covered in the resolution
- of LWG issue 343. There are already dependencies in
- <algorithm> on types declared in this header, so this
- comment does not create a new dependency.
-
- 
-
- <td width="466">
- Move primary swap template from
- <algorithm> into <utility>. Move 25.2.3 to
- somewhere under 20.2. Require <algorithm> to #include
- <utility> to access pair and provide legacy support
- for finding swap.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 301
-
- <td width="75">
- 25.2.5
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- replace and
- replace_if have the requirement: OutputIterator<Iter,
- Iter::reference> Which implies they need to copy some
- values in the range the algorithm is iterating over. This
- is not however the case, the only thing that happens is
- const T&s might be copied over existing elements (hence
- the OutputIterator<Iter, const T&>
-
- 
-
- <td width="466">
- Remove OutputIterator<Iter,
- Iter::reference> from replace and replace_if
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 302
-
- <td width="75">
- 25.3
-
- <td width="31">
- 4
-
- <td width="38">
- Ed
-
- <td width="375">
- the concept
- StrictWeakOrder covers the definition of a strict weak
- ordering, described in paragraph 4.
-
- 
-
- <td width="466">
- Remove 4, and mention StrictWeakOrder in
- paragraph 1.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 303
-
- <td width="75">
- 25.3
-
- <td width="31">
- 6
-
- <td width="38">
- Ed
-
- <td width="375">
- This paragraph just describes
- is_partitioned
-
- <td width="466">
- 6 A sequence
- [start,finish) is partitioned with respect to an expression
- f(e) if is_partitioned(start, finish, e) != false
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 304
-
- <td width="75">
- 25.3.6
-
- <td width="31">
- 
-
- <td width="38">
- Ed
-
- <td width="375">
- The requires
- clauses of push_heap, pop_heap and make_heap are
- inconsistently formatted, dispite being identical
-
- 
-
- <td width="466">
- Format them identically.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 305
-
- <td width="75">
- 25.3.7
-
- <td width="31">
- 1, 9, 17
-
- <td width="38">
- Te
-
- <td width="375">
- The negative requirement on IsSameType is a
- hold-over from an earlier draught with a variadic template
- form of min/max algorith. It is no longer necessary.
-
- <td width="466">
- Strike the !IsSameType<T, Compare>
- constraint on min/max/minmax algorithms
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- US 84
-
- <td width="75">
- 26
-
- <td width="31">
- 
-
- <td width="38">
- ge
-
- <td width="375">
- 
- Parts of the numerics chapter are not concept enabled.
-
- 
-
- <td width="466">
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- FR 35
-
- <td width="75">
- 26.3 
- [Complex 
- numbers]
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- Instantiations of the class
- template complex<> have to be allowed for integral
- types, to reflect existing practice and ISO standards
- (LIA-III).
-
- 
-
- <td width="466">
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 306
-
- <td width="75">
- 26.4
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- Random number
- library component cannot be used in constrained templates
-
- 
-
- <td width="466">
- Provide constraints for the random number
- library
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 63
-
- <td width="75">
- 26.4.8.5.1
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- No
- constructor of discrete_distribution that accepts
- initializer_list.
-
- 
- discrete_distribution initialize distribution by a given
- range (iterators), but temporary variable of a container or
- an array is needed in the following case.
-
- 
- 
-
- int
- ar[] = {1, 2, 3};
-
- 
- discrete_distribution<> dist(ar, ar+3);
-
- 
- 
-
- Other libraries
- also accept initializer_list, so change
- discrete_distribution library to accept initializer_list
- too.
-
- 
- 
-
- <td width="466">
- Add
- the following constructer.
-
- 
- discrete_distribution(initializer_list<result_type>);
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 64
-
- <td width="75">
- 26.5.2
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- 
- “valarray<T>& operator+=
- (initializer_list<T>);” is not defined.
-
- 
- 
-
- <td width="466">
- Add
- valarray<T>& operator+=
- (initializer_list<T>);
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 307
-
- <td width="75">
- 26.7
-
- <td width="31">
- Footnote 288
-
- <td width="38">
- Ed
-
- <td width="375">
- The footnote
- refers to TR1, which is not a defined term in this
- standard. Drop the reference to TR1, those templates are a
- regular part of the standard now and how they were
- introduced is no longer relevant.
-
- 
-
- <td width="466">
- Drop the reference to TR1.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- US 85
-
- <td width="75">
- 27
-
- <td width="31">
- 
-
- <td width="38">
- ge
-
- <td width="375">
- The
- input/output chapter is not concept enabled.
-
- 
-
- <td width="466">
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 308
-
- <td width="75">
- 27
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- 
- iostreams library cannot be used from
- constrained templates
-
- 
-
- <td width="466">
- Provide constraints for the iostreams
- library, clause 27
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 65
-
- <td width="75">
- 27.4.4
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- Switch from
- “unspecified-bool-type” to　“explicit operator bool()
- const”.
-
- 
- 
-
- <td width="466">
- 
- Replace "operator unspecified-bool-type() const;"
- with "explicit operator bool() const;"
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 66
-
- <td width="75">
- 27.4.4.3
-
- <td width="31">
- 1st para
-
- <td width="38">
- te
-
- <td width="375">
- Switch from
- “unspecified-bool-type” to　“explicit operator bool()
- const”
-
- 
- 
-
- <td width="466">
- 
- Replace "operator unspecified-bool-type() const;"
- with "explicit operator bool() const;"
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- FR 36
-
- <td width="75">
- 27.6.1.2.2 
- [istream. 
- formatted. 
- arithmetic]
-
- <td width="31">
- 1, 2, and 3
-
- <td width="38">
- ed
-
- <td width="375">
- iostate err = 0;
-
- 
-
- iostate is a bitmask type and
- so could be an enumeration. Probably using
-
- goodbit is the solution.
-
- 
-
- <td width="466">
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- FR 37
-
- <td width="75">
- 27.6.1.2.2 
- [istream. 
- formatted. 
- arithmetic]
-
- <td width="31">
- 3
-
- <td width="38">
- ed
-
- <td width="375">
- else if (lval <
- numeric_limits<int>::min()
-
- ||
- numeric_limits<int>::max() < lval))
-
- 
-
- The parentheses aren't
- balanced.
-
- 
-
- <td width="466">
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 67
-
- <td width="75">
- 27.7.1
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- 
- basic_stringbuf dose not use concept.
-
- <td width="466">
- 
- Replace “class Allocator” to “Allocator
- Alloc”.
-
- 
-   Correct as follows.
-
- 
- 
-
- 
- namespace std {
-
- 
- template <class charT, class traits =
- char_traits<charT>,
-
- 
- Allocator Alloc = allocator<charT> >
-
- 
- class basic_stringbuf : public
- basic_streambuf<charT,traits> {
-
- 
- public:
-
- ...
-
- 
- 
-
- //
- 27.7.1.1 Constructors:
-
- 
- explicit basic_stringbuf(ios_base::openmode which
-
- =
- ios_base::in | ios_base::out);
-
- 
- explicit basic_stringbuf
-
- 
- (const basic_string<charT,traits,Alloc>&
- str,
-
- 
- ios_base::openmode which = ios_base::in | ios_base::out);
-
- 
- basic_stringbuf(basic_stringbuf&& rhs);
-
- 
-  
-
- ...
-
- 
-  
-
- 
-  
-
- //
- 27.7.1.3 Get and set:
-
- 
- basic_string<charT,traits,Alloc> str() const;
-
- 
- void str(const
- basic_string<charT,traits,Alloc>& s);
-
- 
-  
-
- ...
-
- };
-
- 
-  
-
- 
- template <class charT, class traits, Allocator
- Alloc>
-
- 
- void swap(basic_stringbuf<charT, traits,
- Alloc>& x,
-
- 
- basic_stringbuf<charT, traits, Alloc>& y);
-
- 
- template <class charT, class traits, Allocator
- Alloc>
-
- 
- void swap(basic_stringbuf<charT, traits,
- Alloc>&& x,
-
- 
- basic_stringbuf<charT, traits, Alloc>& y);
-
- 
- template <class charT, class traits, Allocator
- Alloc>
-
- 
- void swap(basic_stringbuf<charT, traits,
- Alloc>& x,
-
- 
- basic_stringbuf<charT, traits,
- Alloc>&& y);
-
- }
-
- 
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 68
-
- <td width="75">
- 27.7.2
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- 
- basic_istringstream dose not use concept.
-
- <td width="466">
- 
- Replace “class Allocator” to “Allocator
- Alloc”.
-
- 
-   Correct as follows.
-
- 
-  
-
- 
- namespace std {
-
- 
- template <class charT, class traits =
- char_traits<charT>,
-
- 
- Allocator Alloc = allocator<charT> >
-
- 
- class basic_istringstream : public
- basic_istream<charT,traits> {
-
- 
- public:
-
- 
- typedef charT char_type;
-
- 
- typedef typename traits::int_type int_type;
-
- 
- typedef typename traits::pos_type pos_type;
-
- 
- typedef typename traits::off_type off_type;
-
- 
- typedef traits traits_type;
-
- 
- typedef Alloc allocator_type;
-
- 
- 
-
- //
- 27.7.2.1 Constructors:
-
- 
- explicit basic_istringstream(ios_base::openmode which =
- ios_base::in);
-
- 
- explicit basic_istringstream(
-
- 
- const basic_string<charT,traits,Alloc>&
- str,
-
- 
- ios_base::openmode which = ios_base::in);
-
- 
- basic_istringstream(basic_istringstream&& rhs);
-
- 
-  
-
- //
- 27.7.2.2 Assign and swap:
-
- 
- basic_istringstream&
- operator=(basic_istringstream&& rhs);
-
- 
- void swap(basic_istringstream&& rhs);
-
- 
-  
-
- //
- 27.7.2.3 Members:
-
- 
- basic_stringbuf<charT,traits,Alloc>* rdbuf()
- const;
-
- 
-  
-
- 
- basic_string<charT,traits,Alloc> str() const;
-
- 
- void str(const
- basic_string<charT,traits,Alloc>& s);
-
- 
-  
-
- 
- private:
-
- //
- basic_stringbuf<charT,traits,Alloc> sb;
- exposition only
-
- };
-
- 
-  
-
- 
- template <class charT, class traits, Allocator
- Alloc>
-
- 
- void swap(basic_istringstream<charT, traits,
- Alloc>& x,
-
- 
- basic_istringstream<charT, traits, Alloc>&
- y);
-
- 
- template <class charT, class traits, Allocator
- Alloc>
-
- 
- void swap(basic_istringstream<charT, traits,
- Alloc>&& x,
-
- 
- basic_istringstream<charT, traits, Alloc>&
- y);
-
- 
- template <class charT, class traits, Allocator
- Alloc>
-
- 
- void swap(basic_istringstream<charT, traits,
- Alloc>& x,
-
- 
- basic_istringstream<charT, traits,
- Alloc>&& y);
-
- }
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 69
-
- <td width="75">
- 27.7.3
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- 
- basic_ostringstream dose not use concept.
-
- <td width="466">
- 
- Replace “class Allocator” to “Allocator
- Alloc”.
-
- 
-   Correct as follows.
-
- 
- 
-
- 
- namespace std {
-
- 
- template <class charT, class traits =
- char_traits<charT>,
-
- 
- Allocator Alloc = allocator<charT> >
-
- 
- class basic_ostringstream : public
- basic_ostream<charT,traits> {
-
- 
- public:
-
- //
- types:
-
- 
- typedef charT char_type;
-
- 
- typedef typename traits::int_type int_type;
-
- 
- typedef typename traits::pos_type pos_type;
-
- 
- typedef typename traits::off_type off_type;
-
- 
- typedef traits traits_type;
-
- 
- typedef Alloc allocator_type;
-
- 
-  
-
- //
- 27.7.3.1 Constructors/destructor:
-
- 
- explicit basic_ostringstream(ios_base::openmode which =
- ios_base::out);
-
- 
- explicit basic_ostringstream(
-
- 
- const basic_string<charT,traits,Alloc>&
- str,
-
- 
- ios_base::openmode which = ios_base::out);
-
- 
- basic_ostringstream(basic_ostringstream&& rhs);
-
- 
-  
-
- //
- 27.7.3.2 Assign/swap:
-
- 
- basic_ostringstream&
- operator=(basic_ostringstream&& rhs);
-
- 
- void swap(basic_ostringstream&& rhs);
-
- 
-  
-
- //
- 27.7.3.3 Members:
-
- 
- basic_stringbuf<charT,traits,Alloc>* rdbuf()
- const;
-
- 
- basic_string<charT,traits,Alloc> str() const;
-
- 
- void str(const
- basic_string<charT,traits,Alloc>& s);
-
- 
- private:
-
- //
- basic_stringbuf<charT,traits,Alloc> sb;
- exposition only
-
- };
-
- 
-  
-
- 
- template <class charT, class traits, Allocator
- Alloc>
-
- 
- void swap(basic_ostringstream<charT, traits,
- Alloc>& x,
-
- 
- basic_ostringstream<charT, traits, Alloc>&
- y);
-
- 
- template <class charT, class traits, Allocator
- Alloc>
-
- 
- void swap(basic_ostringstream<charT, traits,
- Alloc>&& x,
-
- 
- basic_ostringstream<charT, traits, Alloc>&
- y);
-
- 
- template <class charT, class traits, Allocator
- Alloc>
-
- 
- void swap(basic_ostringstream<charT, traits,
- Alloc>& x,
-
- 
- basic_ostringstream<charT, traits,
- Alloc>&& y);
-
- }
-
- 
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 71
-
- <td width="75">
- 27.7.3
-
- <td width="31">
- 
-
- <td width="38">
- ed
-
- <td width="375">
- 
- Typo.
-
- "template" is missing in
- "class basic_ostringstream" of the title of the chapter.
-
- <td width="466">
- 
- Correct as follows.
-
- 
- 27.7.3 Class basic_ostringstream
-
- 
- 
-
- 
- should be
-
- 
- 
-
- 27.7.3 Class template
- basic_ostringstream
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 72
-
- <td width="75">
- 27.7.4
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- 
- basic_stringstream dose not use concept.
-
- <td width="466">
- 
- Replace "class Allocator" to "Allocator Alloc".
-
- 
-   Correct as follows.
-
- 
-  
-
- 
- namespace std {
-
- 
- template <class charT, class traits =
- char_traits<charT>,
-
- 
- Allocator Alloc = allocator<charT> >
-
- 
- class basic_stringstream
-
- :
- public basic_iostream<charT,traits> {
-
- 
- public:
-
- //
- types:
-
- 
- typedef charT char_type;
-
- 
- typedef typename traits::int_type int_type;
-
- 
- typedef typename traits::pos_type pos_type;
-
- 
- typedef typename traits::off_type off_type;
-
- 
- typedef traits traits_type;
-
- 
- typedef Alloc allocator_type;
-
- 
-  
-
- //
- constructors/destructor
-
- 
- explicit basic_stringstream(
-
- 
- ios_base::openmode which = ios_base::out|ios_base::in);
-
- 
- explicit basic_stringstream(
-
- 
- const basic_string<charT,traits,Alloc>&
- str,
-
- 
- ios_base::openmode which = ios_base::out|ios_base::in);
-
- 
- basic_stringstream(basic_stringstream&& rhs);
-
- 
-  
-
- //
- 27.7.5.1 Assign/swap:
-
- 
- void swap(basic_stringstream&& rhs);
-
- 
-  
-
- //
- Members:
-
- 
- basic_stringbuf<charT,traits,Alloc>* rdbuf()
- const;
-
- 
- basic_string<charT,traits,Alloc> str() const;
-
- 
- void str(const
- basic_string<charT,traits,Alloc>& str);
-
- 
- private:
-
- //
- basic_stringbuf<charT, traits> sb; exposition only
-
- };
-
- 
-  
-
- 
- template <class charT, class traits, Allocator
- Alloc>
-
- 
- void swap(basic_stringstream<charT, traits,
- Alloc>& x,
-
- 
- basic_stringstream<charT, traits, Alloc>&
- y);
-
- 
- template <class charT, class traits, Allocator
- Alloc>
-
- 
- void swap(basic_stringstream<charT, traits,
- Alloc>&& x,
-
- 
- basic_stringstream<charT, traits, Alloc>&
- y);
-
- 
- template <class charT, class traits, Allocator
- Alloc>
-
- 
- void swap(basic_stringstream<charT, traits,
- Alloc>& x,
-
- 
- basic_stringstream<charT, traits,
- Alloc>&& y);
-
- }
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 73
-
- <td width="75">
- 27.8.1.14
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- It is a problem
- from C++98, fstream cannot appoint a filename of wide
- character string(const wchar_t and const wstring&).
-
- 
- 
-
- <td width="466">
- Add
- interface corresponding to wchar_t, char16_t and char32_t.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- US 86
-
- <td width="75">
- 28
-
- <td width="31">
- 
-
- <td width="38">
- ge
-
- <td width="375">
- The
- regular expressions chapter is not concept enabled.
-
- 
-
- <td width="466">
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 309
-
- <td width="75">
- 28
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- Regular
- expressions cannot be used in constrained templates
-
- 
-
- <td width="466">
- Provide constraints for the regular
- expression library, clause 28
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 310
-
- <td width="75">
- 28
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- The regex chapter uses iterators in the old
- pre-concept style, it should be changed to use concepts
- instead.
-
- <td width="466">
- Use concepts for iterator template
- arguments throughout.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 314
-
- <td width="75">
- 28.4
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- The swap
- overloads for regex classes are only supplied for l-value
- references. Other sections of the library (eg 21 strings or
- 23 containers) provide two extra overloads taking an
- r-value reference as the first and second argument
- respectively.
-
- 
-
- <td width="466">
- Add the missing overloads to 28.4 and the
- corresponding later sections in 28 for each swap function.
- We want to accept AMs paper which proposes a single
- overload with two r-value references
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 315
-
- <td width="75">
- 28.4
-
- <td width="31">
- p6
-
- <td width="38">
- Te
-
- <td width="375">
- 6 Effects:
- string_type str(first, last); return
- use_facet<collate<charT> >(
- getloc()).transform(&*str.begin(), &*str.end()); Is
- it legal to dereference str.end() ?
-
- 
-
- <td width="466">
- Reword to effect clause to use legal
- iterator dereferences
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 316
-
- <td width="75">
- 28.4 ff
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- The constructors
- for regex classes do not have an r-value overload.
-
- 
-
- <td width="466">
- Add the missing r-value constructors to
- regex classes.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 317
-
- <td width="75">
- 28.8
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- basic_string has both a constructor and an
- assignment operator that accepts an initializer list,
- basic_regex should have the same.
-
- <td width="466">
- In the
- basic_regex synopsis, after: basic_regex&
- operator=(const charT* ptr); add: basic_regex&
- operator=(initializer_list<charT> il); And after
- paragraph 20 add: basic_regex&
- operator=(initializer_list<charT> il); Effects:
- returns assign(il.begin(), il.end());
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- JP 74
-
- <td width="75">
- 28.8
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- 
- “basic_regx & operator=
- (initializer_list<T>);” is not defined.
-
- 
- 
-
- <td width="466">
- Add
- basic_regx & operator= (initializer_list<T>);
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 318
-
- <td width="75">
- 28.8.2
-
- <td width="31">
- para 22
-
- <td width="38">
- Ed
-
- <td width="375">
- Constructor
- definition should appear with the other constructors not
- after assignment ops.
-
- 
-
- <td width="466">
- Move para 22 to just after para 17.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 319
-
- <td width="75">
- 28.12.2
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- It was always expected that
- regex_token_iterator would be constructible from an array
- literal: indeed ideally this is the prefered method of
- initializing such an object. However, the best we could do
- in C++0x was: template <std::size_t N>
- regex_token_iterator(BidirectionalIterator a,
- BidirectionalIterator b, const regex_type& re, const
- int (&submatches)[N], regex_constants::match_flag_type
- m = regex_constants::match_default); Now that we have
- initializer_lists we should use them to remove this
- particular wart.
-
- <td width="466">
- To the synopsis
- for regex_token_iterator, after template <std::size_t
- N> regex_token_iterator(BidirectionalIterator a,
- BidirectionalIterator b, const regex_type& re, const
- int (&submatches)[N], regex_constants::match_flag_type
- m = regex_constants::match_default); add
- regex_token_iterator(BidirectionalIterator a,
- BidirectionalIterator b, const regex_type& re,
- initializer_list<int> submatches,
- regex_constants::match_flag_type m =
- regex_constants::match_default); In 28.12.2.1 add the
- declaration: regex_token_iterator(BidirectionalIterator a,
- BidirectionalIterator b, const regex_type& re,
- initializer_list<int> submatches,
- regex_constants::match_flag_type m =
- regex_constants::match_default); And to the end of para 3
- add: The forth constructor initializes the member subs to
- hold a copy of the sequence of integer values in the range
- [submatches.begin(), submatches.end()).
-
- 
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- US 87
-
- <td width="75">
- 29
-
- <td width="31">
- 
-
- <td width="38">
- ge
-
- <td width="375">
- The
- atomics chapter is not concept enabled. The adopted paper,
- N2427, did have those concepts.
-
- 
-
- <td width="466">
- 
-
- <td width="225">
- Create an issue for concepts in the atomics chapter. See
- N2427. Needs to also consider issues 923 and 924. 
-
- <tr valign="top">
- <td width="29">
- UK 
- 311
-
- <td width="75">
- 29
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- Atomic types
- cannot be used generically in a constrained template
-
- 
-
- <td width="466">
- Provide constraints for the atomics
- library, clause 29
-
- <td width="225">
- Duplicate of US 87. 
-
- <tr valign="top">
- <td width="29">
- UK 
- 312
-
- <td width="75">
- 29
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- The contents of the <stdatomic.h>
- header are not listed anywhere, and <cstdatomic> is
- listed as a C99 header in chapter 17. If we intend to use
- these for compatibility with a future C standard, we should
- not use them now.
-
- <td width="466">
- Remove <cstdatomic> from the C99
- headers in table 14. Add a new header <atomic> to the
- headers in table 13. Update chapter 29 to remove reference
- to <stdatomic.h> and replace the use of
- <cstdatomic> with <atomic>. If and when WG14
- adds atomic operations to C we can add corresponding
- headers to table 14 with a TR.
-
- <td width="225">
- Create an issue. Assigned to Lawrence Crowl. May be
- resolvable with a footnote for clarity stating that the header is
- defined where it exists. 
-
- <tr valign="top">
- <td width="29">
- JP 75
-
- <td width="75">
- 29
-
- <td width="31">
- 
-
- <td width="38">
- ed
-
- <td width="375">
- A
- definition of enum or struct is the style of C using
- typedef.
-
- <td width="466">
- 
- Change to a style of C++.
-
- 
- Correct as follows.
-
- 
- 
-
- 
- 29.1
-
- 
-  
-
- 
- namespace std {
-
- 
- typedef enum memory_order {
-
- 
- memory_order_relaxed, memory_order_consume,
- memory_order_acquire,
-
- 
- memory_order_release, memory_order_acq_rel,
- memory_order_seq_cst
-
- }
- memory_order;
-
- }
-
- 
- 
-
- 
- should be
-
- 
- 
-
- 
- namespace std {
-
- 
- enum memory_order {
-
- 
- memory_order_relaxed, memory_order_consume,
- memory_order_acquire,
-
- 
- memory_order_release, memory_order_acq_rel,
- memory_order_seq_cst
-
- };
-
- }
-
- 
- 
-
- 
- 29.3.1
-
- 
- 
-
- 
- namespace std {
-
- 
- typedef struct atomic_bool {
-
- ...
-
- }
- atomic_bool;
-
- }
-
- 
- 
-
- 
- should be
-
- 
- 
-
- 
- namespace std {
-
- 
- struct atomic_bool {
-
- ...
-
- };
-
- }
-
- 
- 
-
- 
- namespace std {
-
- 
- typedef struct atomic_itype {
-
- ...
-
- }
- atomic_itype;
-
- }
-
- 
- 
-
- 
- should be
-
- 
- 
-
- 
- namespace std {
-
- 
- struct atomic_itype {
-
- ...
-
- };
-
- }
-
- 
- 
-
- 
- 29.3.2
-
- 
- 
-
- 
- namespace std {
-
- 
- typedef struct atomic_address {
-
- ...
-
- }
- atomic_address;
-
- }
-
- 
- 
-
- 
- should be
-
- 
- 
-
- 
- namespace std {
-
- 
- struct atomic_address {
-
- ...
-
- };
-
- }
-
- 
- 
-
- 
- 29.5
-
- 
- 
-
- 
- namespace std {
-
- 
- typedef struct atomic_flag {
-
- ...
-
- }
- atomic_flag;
-
- }
-
- 
- 
-
- 
- should be
-
- 
- 
-
- 
- namespace std {
-
- 
- struct atomic_flag {
-
- ...
-
- };
-
- }
-
- <td width="225">
- Recommend to reject the comment: We believe the current
- syntax is most appropriate for an interface that is intended to be
- highly compatible with C. 
-
- <tr valign="top">
- <td width="29">
- UK 
- 313
-
- <td width="75">
- 29.1
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- seq_cst fences don't necessarily guarantee
- ordering
- http://home.twcny.rr.com/hinnant/cpp_extensions/issues_preview/lwg-active.html#926
-
- <td width="466">
- Add a new
- paragraph after 29.1 [atomics.order]p5 that says For atomic
- operations A and B on an atomic object M, where A and B
- modify M, if there are memory_order_seq_cst fences X and Y
- such that A is sequenced before X, Y is sequenced before B,
- and X precedes Y in S, then B occurs later than A in the
- modifiction order of M.
-
- 
-
- <td width="225">
- Hans to make proposal. See LWG Issue 926. 
-
- <tr valign="top">
- <td width="29">
- US 88
-
- <td width="75">
- 29.2
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- The "lockfree" facilities do
- not tell the programmer enough.
-
- <td width="466">
- 
- Expand the "lockfree" facilities. See the attached paper
- "Issues with the C++ Standard" under Chapter 29,
- "atomics.lockfree doesn't tell the programmer enough"
-
- 
-
- <td width="225">
- Create an issue, will require more discussion. Assigned
- to Lawrence. Description of issue should be based on what is in the
- additional notes for US 88. 
-
- <tr valign="top">
- <td width="29">
- US 89
-
- <td width="75">
- 29.3.1
-
- <td width="31">
- Table 122
-
- <td width="38">
- te
-
- <td width="375">
- The
- types in the table "Atomics for standard typedef types"
- should be typedefs, not classes. These semantics are
- necessary for compatibility with C.
-
- 
-
- <td width="466">
- Change the classes to
- typedefs.
-
- <td width="225">
- LWG Issue 937. Direct the editor to turn the types into
- typedefs as proposed in the comment. Paper approved by committee used
- typedefs, this appears to have been introduced as an editorial change.
- Rationale: for compatibility with C.<tr valign="top">
- <td width="29">
- US 90
-
- <td width="75">
- 29.4
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- Are atomic functions allowed
- to have non-volatile overloads?
-
- <td width="466">
- 
- Allow non-volatile overloads. See the attached paper
- "Issues with the C++ Standard, under Chapter 29, "Are
- atomic functions allowed to have non-volatile overloads?"
-
- 
-
- <td width="225">
- Create an issue. Assigned to Lawrence Crowl. Should
- explicitly consider the process shared issue. 
-
- <tr valign="top">
- <td width="29">
- US 91
-
- <td width="75">
- 29.4
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- Whether or not a failed
- compare_exchange is a RMW operation (as used in 1.10
- [intro.multithread]) is unclear.
-
- <td width="466">
- 
- Make failing compare_exchange operations not be RMW. See
- the attached paper under "atomic RMW status of failed
- compare_exchange"
-
- 
-
- <td width="225">
- Create an issue, goes to review. Attention: Howard.
- Group agrees with the resolution as proposed by Anthony Williams in the
- attached note. 
-
- <tr valign="top">
- <td width="29">
- US 92
-
- <td width="75">
- 29.4
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- The effect of
- memory_order_consume with atomic RMW operations is unclear.
-
- <td width="466">
- 
- Follow the lead of fences [atomics.fences], and promote
- memory_order_consume to memory_order_acquire with RMW
- operations.
-
- 
-
- <td width="225">
- Create an issue. Assigned to Lawrence. Resolution
- requires proposed wording. 
-
- <tr valign="top">
- <td width="29">
- JP 76
-
- <td width="75">
- 30
-
- <td width="31">
- 
-
- <td width="38">
- ed
-
- <td width="375">
- A
- description for "Throws: Nothing." are not unified.
-
- At
- the part without throw, "Throws: Nothing." should be
- described.
-
- <td width="466">
- Add
- "Throws: Nothing." to the following.
-
- 
- 30.2.1.6 , 1st paragraph
-
- 
- 30.3.3.1 , 4th paragraph
-
- 
- 30.3.3.2.1 , 6th paragraph
-
- 
- 30.4.1 , 7th and 8th paragraph
-
- 30.4.2 ,
- 6th,
- 7th,19th,21th and 25th
- paragraph
-
- 
- 
-
- <td width="225">
- Pass on to editor. 
-
- <tr valign="top">
- <td width="29">
- US 93
-
- <td width="75">
- 30
-
- <td width="31">
- 
-
- <td width="38">
- ge
-
- <td width="375">
- The
- thread chapter is not concept enabled.
-
- 
-
- <td width="466">
- 
-
- <td width="225">
- Create an issue. Need to find volunteers to work on
- this. 
-
- <tr valign="top">
- <td width="29">
- UK 
- 320
-
- 
-
- <td width="75">
- 30
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- Threads library cannot be used in
- constrained templates
-
- <td width="466">
- Provide constraints for the threads
- library, clause 30
-
- <td width="225">
- Duplicate of US 93. 
-
- <tr valign="top">
- <td width="29">
- UK 
- 321
-
- <td width="75">
- 30
-
- <td width="31">
- 
-
- <td width="38">
- Ed
-
- <td width="375">
- Throughout this
- clause, the term Requires: is used to introduce compile
- time requirements, which we expect to be replaced with
- concepts and requires in code. Run-time preconditions are
- introduced with the term "Preconditions:" which is not a
- defined part of the library documentation structure
- (17.5.2.4). However, this is exactly the direction that BSI
- would like to see the organisation move, replacing
- Requires: clauses with Preconditions: clasues throught the
- library. See comment against clause 17 for more details.
-
- 
-
- <td width="466">
- Decument Preconditions: paragraphs in
- 17.5.2.4, and use consistently through rest of the library.
-
- <td width="225">
- Pass on to editor. 
-
- <tr valign="top">
- <td width="29">
- US 94
-
- <td width="75">
- 30.1.2
-
- <td width="31">
- 1
-
- <td width="38">
- te
-
- <td width="375">
- The first sentence of para 1 suggests that no other
- library function is permitted to call operating system or
- low level APIs.
-
- <td width="466">
- Rewrite para 1
- as: “ Some functions described
- in this Clause are specified to throw exceptions of type
- system_error (19.4.5
- ). Such exceptions shall be thrown if
- a call to an operating system or underlying API results in
- an error that prevents the library function from satisfying
- its postconditions or from returning a meaningful
- value.”
-
- 
-
- <td width="225">
- 
-
- Reclassify as editorial. Pass on to editor, wording roughly as proposed.<tr valign="top">
- <td width="29">
- US 95
-
- <td width="75">
- 30.1.3
-
- <td width="31">
- 1
-
- <td width="38">
- te
-
- <td width="375">
- “native_handle_type” is a typedef, not a
- class member.
-
- <td width="466">
- Several classes
- described in this Clause have a member native_handle (of
- type native_handle_type) . The
-
- 
- presence of this member and its semantics is implementation
- defined. [ Note: This member allows implementations to
- provide access to implementation details. The name of the
- member and the type are specified to facilitate portable
- compile-time detection. Actual use of this member or the
- corresponding type is inherently non-portable. —end
- note ]
-
- 
-
- <td width="225">
- 
-
- Not a defect. native_handle_type is a typedef, but it is also a member of
- the classes in question.<tr valign="top">
- <td width="29">
- US 96
-
- <td width="75">
- 30.1.4
-
- <td width="31">
- 2
-
- <td width="38">
- te
-
- <td width="375">
- There is no definition here for monotonic clock.
-
- <td width="466">
- Implementations
- should use a monotonic clock to measure time for
- these functions. A monotonic clock measures real time, but
- cannot be set, and is guaranteed to have no negative clock
- jumps.
-
- 
-
- <td width="225">
- 
-
- Create an issue, together with UK 322. Detlef will write the issue, but not
- proposed wording. Refer also to sections [time.clock.req] and [time.clock.monotonic].<tr valign="top">
- <td width="29">
- UK 
- 322
-
- <td width="75">
- 30.1.4
-
- <td width="31">
- 2
-
- <td width="38">
- Te
-
- <td width="375">
- Not all systms
- can provide a monotonic clock. How are they expected to
- treat a _for function?
-
- 
-
- <td width="466">
- Add at least a note explaining the intent
- for systems that do not support a monotonic clock.
-
- <td width="225">
- 
-
- Create an issue, together with UK 96. Note that the specification as is
- already allows a non-monotonic clock due to the word "should" rather than
- "shall". If this wording is kept, a footnote should be added to make the
- meaning clear.<tr valign="top">
- <td width="29">
- UK 
- 323
-
- <td width="75">
- 30.2.1
-
- <td width="31">
- 1
-
- <td width="38">
- Te
-
- <td width="375">
- The presence of
- a non-explicit variadic template constructor alongside an
- explicit single-argument constructor can lead to behaviour
- that is not intended: the variadic constructor will be
- selected for implicit conversions, defeating the purpose of
- the explicit single-argument constructor. Additionally the
- single-argument constructor is redundant; the variadic
- constructor can provide identical functionality with one
- *fewer* copies if the supplied func is an lvalue.
-
- 
-
- <td width="466">
- Mark constructor template <class F,
- class ...Args> thread(F&& f, Args&&...
- args); as explicit and remove the single-argument
- constructor.
-
- <td width="225">
- 
-
- Create an issue, goes to review. Attention: Howard. Group agrees with the
- proposed resolution.<tr valign="top">
- <td width="29">
- UK 
- 324
-
- <td width="75">
- 30.2.1.1
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- thread::id
- objects should be as useable in hashing containers as they
- are in ordered associative containers.
-
- 
-
- <td width="466">
- Add thread::id
- support for std::hash
-
- 
-
- 
-
- 
-
- <td width="225">
- 
-
- Not a defect. See [unord.hash], where std::thread:id is already listed as a
- required specialization for std::hash().<tr valign="top">
- <td width="29">
- JP 77
-
- <td width="75">
- 30.2.1.2
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- 
- "CopyConstructible" and "MoveConstructible" in
- "Requires: F and each Ti in Args shall be
- CopyConstructible if an lvalue and otherwise
- MoveConstructible." are reflected by interface.
-
- 
- 
-
- <td width="466">
- Add
- a concept for constructor of thread.
-
- <td width="225">
- 
-
- Subset of US 93. Should be addressed under the issue corresponding to US 93.<tr valign="top">
- <td width="29">
- JP 78
-
- <td width="75">
- 30.2.1.2
-
- <td width="31">
- 
- 4th para, 1st line
-
- 
-
- <td width="38">
- ed
-
- <td width="375">
- In
- "F and each Ti in Args", 'Ti' is not clear.
-
- <td width="466">
- 
- Replace "Ti" with "args"
-
- <td width="225">
- 
-
- Pass on to editor.<tr valign="top">
- <td width="29">
- US 97
-
- <td width="75">
- 30.2.1.3
-
- <td width="31">
- 1
-
- <td width="38">
- te
-
- <td width="375">
- detach-on-destruction may result in
- “escaped” threads accessing objects with
- bounded lifetime after the end of their lifetime.
-
- <td width="466">
- See document WG21 N2802=08-0312 written by Hans Boehm.
-
- <td width="225">
- 
-
- Create an issue. To be discussed in full library group.<tr valign="top">
- <td width="29">
- US 98
-
- <td width="75">
- 30.2.1.3, 
- 30.2.1.4
-
- <td width="31">
- 
-
- <td width="38">
- 
-
- <td width="375">
- The current defined behavior
- for the std::thread destructor is to detach the thread.
- Unfortunately, this behavior exposes programmers to tricky,
- hard-to-diagnose, undefined behavior.
-
- <td width="466">
- 
- Change destruction behavior to undefined behavior, with a
- note strongly encouraging termination. See the attached
- paper "Issues with the C++ Standard" under Chapter 30,
- "Implicit thread detach is harmful".
-
- 
-
- <td width="225">
- 
-
- Duplicate of US 97.<tr valign="top">
- <td width="29">
- UK 
- 325
-
- <td width="75">
- 30.3.3
-
- <td width="31">
- 2
-
- <td width="38">
- Te
-
- <td width="375">
- We believe constexpr literal values should
- be a more natural expression of empty tag types than extern
- objects as it should improve the compilers ability to
- optimize the empty object away completely.
-
- <td width="466">
- Replace the
- extern declarations: extern const defer_lock_t defer_lock;
- extern const try_to_lock_t try_to_lock; extern const
- adopt_lock_t adopt_lock; with constexpr values constexpr
- defer_lock_t defer_lock{}; constexpr try_to_lock_t
- try_to_lock{}; constexpr adopt_lock_t adopt_lock{};
-
- 
-
- <td width="225">
- 
-
- Create an issue. Move to review, attention: Howard. The current
- specification is a "hack", and the proposed specification is a better
- "hack".<tr valign="top">
- <td width="29">
- UK 
- 326
-
- <td width="75">
- 30.3.3.2.1
-
- <td width="31">
- 7
-
- <td width="38">
- Te
-
- <td width="375">
- The precondition
- that the mutex is not owned by this thread offers
- introduces the risk of un-necessary undefined behaviour
- into the program. The only time it matters whether the
- current thread owns the mutex is in the lock operation, and
- that will happen subsequent to construction in this case.
- The lock operation has the identical pre-condition, so
- there is nothing gained by asserting that precondition
- earlier and denying the program the right to get into a
- valid state before calling lock.
-
- 
-
- <td width="466">
- Strike 30.3.3.2.1p7
-
- <td width="225">
- 
-
- Create an issue. Move to review, attention: Howard. Proposed resolution is
- fine.<tr valign="top">
- <td width="29">
- UK 
- 327
-
- <td width="75">
- 30.3.3.2.2
-
- <td width="31">
- 4, 9, 14, 19
-
- <td width="38">
- Te
-
- <td width="375">
- Not clear what
- the specification for error condition
- resource_deadlock_would_occur means. It is perfectly
- possible for this thread to own the mutex without setting
- owns to true on this specific lock object. It is also
- possible for lock operations to succeed even if the thread
- does own the mutex, if the mutex is recursive. Likewise, if
- the mutex is not recursive and the mutex has been locked
- externally, it is not always possible to know that this
- error condition should be raised, depending on the host
- operating system facilities. It is possible that 'i.e.' was
- supposed to be 'e.g.' and that suggests that recursive
- locks are not allowed. That makes sense, as the
- exposition-only member owns is boolean and not a integer to
- count recursive locks.
-
- 
-
- <td width="466">
- Add a precondition !owns. Change the 'i.e.'
- in the error condition to be 'e.g.' to allow for this
- condition to propogate deadlock detection by the host OS.
-
- <td width="225">
- 
-
- Create an issue. Assigned to Lawrence Crowl. Note: not sure what try_lock
- means for recursive locks when you are the owner. POSIX has language on
- this, which should ideally be followed. Proposed fix is not quite right, for
- example, try_lock should have different wording from lock.<tr valign="top">
- <td width="29">
- UK 
- 328
-
- <td width="75">
- 30.3.3.2.2
-
- <td width="31">
- 20
-
- <td width="38">
- Te
-
- <td width="375">
- There is a missing precondition that owns
- is true, or an if(owns) test is missing from the effect
- clause
-
- <td width="466">
- Add a
- precondition that owns == true. Add an error condition to
- detect a violation, rather than yield undefined behaviour.
-
- 
-
- <td width="225">
- 
-
- Handle in same issue as UK 327. Also uncertain that the proposed resolution
- is the correct one.<tr valign="top">
- <td width="29">
- UK 
- 329
-
- <td width="75">
- 30.5
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- future, promise and packaged_task provide a
- framework for creating future values, but a simple function
- to tie all three components together is missing. Note that
- we only need a *simple* facility for C++0x. Advanced thread
- pools are to be left for TR2.
-
- <td width="466">
- Provide a simple
- function along the lines of: template< typename F,
- typename ... Args > requires Callable< F, Args...
- > future< Callable::result_type > async(
- F&& f, Args && ... ); Semantics are similar
- to creating a thread object with a packaged_task invoking f
- with forward<Args>(args...) but details are left
- unspecified to allow different scheduling and thread
- spawning implementations. It is unspecified whether a task
- submitted to async is run on its own thread or a thread
- previously used for another async task. If a call to async
- succeeds, it shall be safe to wait for it from any thread.
- The state of thread_local variables shall be preserved
- during async calls. No two incomplete async tasks shall see
- the same value of this_thread::get_id(). [Note: this
- effectively forces new tasks to be run on a new thread, or
- a fixed-size pool with no queue. If the library is unable
- to spawn a new thread or there are no free worker threads
- then the async call should fail.]
-
- 
-
- <td width="225">
- 
-
- Not a defect. This class of feature has been rejected by the committee as a
- whole multiple times.<tr valign="top">
- <td width="29">
- UK 
- 330
-
- <td width="75">
- 30.5.1
-
- <td width="31">
- 
-
- <td width="38">
- Ed
-
- <td width="375">
- 30.5.1 (and then 30.5.7) refer to a
- specialisation of
- constructible_with_allocator_prefix<> However this
- trait is not in the CD, so references to it should be
- removed.
-
- <td width="466">
- Remove the
- reference to constructible_with_allocator_prefix in 30.5.1
- Remove paragraph 30.5.7
-
- 
-
- <td width="225">
- 
-
- Related to JP 79 and therefore subset of US 93. Should be addressed under
- the issue corresponding to US 93.<tr valign="top">
- <td width="29">
- JP 79
-
- <td width="75">
- 30.5.1
-
- <td width="31">
- 
-
- <td width="38">
- te
-
- <td width="375">
- The
- concept of UsesAllocator and Allocator should be used.
-
- <td width="466">
- 
- Correct as follows.
-
- 
-  
-
- 
- template <class R, class Alloc>
-
- 
- struct uses_allocator<promise<R>, Alloc>;
-
- 
- template <class R>
-
- 
- struct
- constructible_with_allocator_prefix<promise<R>
- >;
-
- 
-  
-
- 
- should be
-
- 
-  
-
- 
- template<class R, Allocator Alloc>
-
- concept_map
- UsesAllocator<promise<R>, Alloc>;
-
- 
- 
-
- <td width="225">
- 
-
- Subset of US 93. Should be addressed under the issue corresponding to US 93.<tr valign="top">
- <td width="29">
- UK 
- 331
-
- <td width="75">
- 30.5.3
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- Not clear what
- it means for a public constructor to be 'exposition only'.
- If the intent is purely to support the library calling this
- constructor then it can be made private and accessed
- through friendship. Otherwise it should be documented for
- public consumption.
-
- 
-
- <td width="466">
- Declare the constructor as private with a
- note about intended friendship, or remove the
- exposition-only comment and document the semantics.
-
- <td width="225">
- 
-
- Create an issue. Assigned to Detlef. Suggested resolution probably makes
- sense.<tr valign="top">
- <td width="29">
- UK 
- 332
-
- <td width="75">
- 30.5.4
-
- <td width="31">
- 
-
- <td width="38">
- Ed
-
- <td width="375">
- It is not clear
- without reference to the original proposal how to use a
- future. In particular, the only way for the user to
- construct a future is via the promise API which is
- documented after the presentation of future. Most library
- clauses feature a small description of their components and
- intended use, it would be most useful in this case.
-
- 
-
- <td width="466">
- Provide a small introductory paragraph,
- docuenting intended purpose of the future class template
- and the way futures can only be created via the promise
- API.
-
- <td width="225">
- 
-
- Pass on to editor. Detlef has volunteered to provide some wording.<tr valign="top">
- <td width="29">
- UK 
- 333
-
- <td width="75">
- 30.5.4
-
- <td width="31">
- 5
-
- <td width="38">
- Ge
-
- <td width="375">
- We expect the complicated 3-signature
- specifcation for future::get() to be simplified to a single
- signature with a requires clause by the application of
- concepts.
-
- <td width="466">
- Requires fully baked concepts for clause 30
-
- <td width="225">
- 
-
- Subset of US 93. Should be addressed under the issue corresponding to US 93.<tr valign="top">
- <td width="29">
- UK 
- 334
-
- <td width="75">
- 30.5.4
-
- <td width="31">
- 5
-
- <td width="38">
- Te
-
- <td width="375">
- Behaviour of
- get() is undefined if calling get() while not is_ready().
- The intent is that get() is a blocking call, and will wait
- for the future to become ready.
-
- 
-
- <td width="466">
- Effects: If is_ready() would return false,
- block on the asynchronous result associated with *this.
-
- <td width="225">
- 
-
- Create an issue. Move to review, attention: Howard. Proposed resolution is
- fine.<tr valign="top">
- <td width="29">
- UK 
- 335
-
- <td width="75">
- 30.5.4
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- 
- std::unique_future is MoveConstructible, so you can
- transfer the association with an asynchronous result from
- one instance to another. However, there is no way to
- determine whether or not an instance has been moved from,
- and therefore whether or not it is safe to wait for it.
- std::promise<int> p; std::unique_future<int>
- uf(p.get_future()); std::unique_future<int>
- uf2(std::move(uf)); uf.wait(); // oops, uf has no result to
- wait for.
-
- 
-
- <td width="466">
- Add a "waitable()" function to
- unique_future (and shared_future) akin to
- std::thread::joinable(), which returns true if there is an
- associated result to wait for (whether or not it is ready).
- Then we can say: if(uf.waitable()) uf.wait();
-
- <td width="225">
- 
-
- Create an issue. Requires input from Howard. Probably NAD.<tr valign="top">
- <td width="29">
- UK 
- 336
-
- <td width="75">
- 30.5.4
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- It is possible
- to transfer ownership of the asynchronous result from one
- unique_future instance to another via the move-constructor.
- However, it is not possible to transfer it back, and nor is
- it possible to create a default-constructed unique_future
- instance to use as a later move target. This unduly limits
- the use of unique_future in code. Also, the lack of a
- move-assignment operator restricts the use of unique_future
- in containers such as std::vector - vector::insert requires
- move-assignable for example.
-
- 
-
- <td width="466">
- Add a default constructor with the
- semantics that it creates a unique_future with no
- associated asynchronous result. Add a move-assignment
- operator which transfers ownership.
-
- <td width="225">
- 
-
- Create an issue. Detlef will look into it.<tr valign="top">
- <td width="29">
- JP 80
-
- <td width="75">
- 30.5.4 , 
- 30.5.5
-
- <td width="31">
- 
-
- <td width="38">
- ed
-
- <td width="375">
- 
- Typo, duplicated ">"
-
- "class
- Period>>"
-
- 
- 
-
- <td width="466">
- 
- Remove one
-
- <td width="225">
- 
-
- Pass on to editor.<tr valign="top">
- <td width="29">
- UK 
- 337
-
- <td width="75">
- 30.5.5
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- shared_future
- should support an efficient move constructor that can avoid
- unnecessary manipulation of a reference count, much like
- shared_ptr
-
- 
-
- <td width="466">
- Add a move constructor
-
- <td width="225">
- 
-
- Create an issue. Detlef will look into it.<tr valign="top">
- <td width="29">
- UK 
- 338
-
- <td width="75">
- 30.5.5
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- shared_future is currently
- CopyConstructible, but not CopyAssignable. This is
- inconsistent with shared_ptr, and will surprise users.
- Users will then write work-arounds to provide this
- behaviour. We should provide it simply and efficiently as
- part of shared_future. Note that since the shared_future
- member functions for accessing the state are all declared
- const, the original usage of an immutable shared_future
- value that can be freely copied by multiple threads can be
- retained by declaring such an instance as "const
- shared_future".
-
- <td width="466">
- Remove "=delete"
- from the copy-assignment operator of shared_future. Add a
- move-constructor shared_future(shared_future&&
- rhs), and a move-assignment operator shared_future&
- operator=(shared_future&& rhs). The postcondition
- for the copy-assignment operator is that *this has the same
- associated state as rhs. The postcondition for the
- move-constructor and move assignment is that *this has the
- same associated as rhs had before the
- constructor/assignment call and that rhs has no associated
- state.
-
- 
-
- <td width="225">
- 
-
- Create an issue. Detlef will look into it.<tr valign="top">
- <td width="29">
- UK 
- 339
-
- <td width="75">
- 30.5.6
-
- <td width="31">
- 6, 7
-
- <td width="38">
- Te
-
- <td width="375">
- Move assignment is goiing in the wrong
- direction, assigning from *this to the passed rvalue, and
- then returning a reference to an unusable *this
-
- <td width="466">
- Strike 6. 7
- Postcondition: associated state of *this is the same as the
- associated state of rhs before the call. rhs has no
- associated state.
-
- 
-
- <td width="225">
- 
-
- Create an issue. Move to review, attention: Howard. Proposed resolution is
- fine.<tr valign="top">
- <td width="29">
- UK 
- 340
-
- <td width="75">
- 30.5.6
-
- <td width="31">
- 11, 12, 13
-
- <td width="38">
- Te
-
- <td width="375">
- There is an
- implied postcondition that the state of the promise is
- transferred into the future leaving the promise with no
- associated state. It should be spelled out.
-
- 
-
- <td width="466">
- Postcondition: *this has no associated
- state.
-
- <td width="225">
- 
-
- Create an issue. Move to review, attention: Howard. Proposed resolution is
- fine.<tr valign="top">
- <td width="29">
- UK 
- 341
-
- <td width="75">
- 30.5.6
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- promise::swap accepts its parameter by
- lvalue reference. This is inconsistent with other types
- that provide a swap member function, where those swap
- functions accept an rvalue reference
-
- <td width="466">
- Change promise::swap to take an rvalue
- reference.
-
- <td width="225">
- 
-
- Create an issue. Detlef will look into it. Probably ready as it.<tr valign="top">
- <td width="29">
- UK 
- 342
-
- <td width="75">
- 30.5.6
-
- <td width="31">
- 
-
- <td width="38">
- Te
-
- <td width="375">
- std::promise is
- missing a non-member overload of swap. This is inconsistent
- with other types that provide a swap member function
-
- 
-
- <td width="466">
- Add a non-member overload void
- swap(promise&& x,promise&& y){ x.swap(y); }
-
- <td width="225">
- 
-
- Create an issue. Move to review, attention: Howard. Detlef will also look
- into it.<tr valign="top">
- <td width="29">
- UK 
- 343
-
- <td width="75">
- 30.5.6
-
- <td width="31">
- 3
-
- <td width="38">
- Te
-
- <td width="375">
- The move constructor of a std::promise
- object does not need to allocate any memory, so the
- move-construct-with-allocator overload of the constructor
- is superfluous.
-
- <td width="466">
- Remove the
- constructor with the signature template <class
- Allocator> promise(allocator_arg_t, const Allocator&
- a, promise& rhs);
-
- 
-
- <td width="225">
- 
-
- Create an issue. Detlef will look into it. Will solicit feedback from Pablo.
- Note that "rhs" argument should also be an rvalue reference in any case.<tr valign="top">
- <td width="29">
- JP 81
-
- <td width="75">
- 30.5.8
-
- <td width="31">
- 
-
- <td width="38">
- ed
-
- <td width="375">
- 
- There are not requirements for F and a concept of Allocator
- dose not use.
-
- <td width="466">
- 
- Correct as follows.
-
- 
- 
-
- 
- template <class F>
-
- 
- explicit packaged_task(F f);
-
- 
- template <class F, class Allocator>
-
- 
- explicit packaged_task(allocator_arg_t, const
- Allocator& a, F f);
-
- 
- template <class F>
-
- 
- explicit packaged_task(F&& f);
-
- 
- template <class F, class Allocator>
-
- 
- explicit packaged_task(allocator_arg_t, const
- Allocator& a, F&& f);
-
- 
-  
-
- 
- should be
-
- 
-  
-
- 
- template <class F>
-
- 
- requires CopyConstructible<F> &&
- Callable<F, ArgTypes...>
-
- 
- && Convertible<Callable<F,
- ArgTypes...>::result_type, R>
-
- 
- explicit packaged_task(F f);
-
- 
-  
-
- 
- template <class F, Allocator Alloc>
-
- 
- requires CopyConstructible<F> &&
- Callable<F, ArgTypes...>
-
- 
- && Convertible<Callable<F,
- ArgTypes...>::result_type, R>
-
- 
- explicit packaged_task(allocator_arg_t, const
- Alloc& a, F f);
-
- 
-  
-
- 
- template <class F>
-
- 
- requires CopyConstructible<F> &&
- Callable<F, ArgTypes...>
-
- 
- && Convertible<Callable<F,
- ArgTypes...>::result_type, R>
-
- 
- explicit packaged_task(F&& f);
-
- 
-  
-
- 
- template <class F, Allocator Alloc>
-
- 
- requires CopyConstructible<F> &&
- Callable<F, ArgTypes...>
-
- 
- && Convertible<Callable<F,
- ArgTypes...>::result_type, R>
-
- explicit
- packaged_task(allocator_arg_t, const Alloc& a,
- F&& f);
-
- <td width="225">
- 
-
- Subset of US 93. Should be addressed under the issue corresponding to US 93.
- We do not consider this to be an editorial change.<tr valign="top">
- <td width="29">
- DE-23
-
- <td width="75">
- Annex B
-
- <td width="31">
- p2
-
- <td width="38">
- te
-
- <td width="375">
- DE-23 Recursive
- use of constexpr functions appears to be permitted. Since
- such functions may be required to be evaluated at
- compile-time, Annex B "implementation quantities" should
- specify a maximum depth of recursion.
-
- <td width="466">
- In Annex B, specify a recursion depth of 256 or a larger
- value.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- DE-24
-
- <td width="75">
- Annex B
-
- <td width="31">
- p2
-
- <td width="38">
- te
-
- <td width="375">
- DE-24 The
- number of placeholders for "bind" is implementation-defined
- in 20.7.12.1.4, but no minimum is suggested in Annex B. 
-
- <td width="466">
- Add a miminum of 10 placeholders to Annex B.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- DE-25
-
- <td width="75">
- Annex B
-
- <td width="31">
- p2
-
- <td width="38">
- te
-
- <td width="375">
- DE-25
- Specifying a minimum of 17 recursively nested template
- instantiations is too small for practical purposes. The
- limit is too high to effectively limit compiler resource
- usage, see
- http://ubiety.uwaterloo.ca/~tveldhui/papers/2003/turing.pdf
- . The conclusion is that the metric "number of recursively
- nested template instantiations" is inapposite.
-
- <td width="466">
- Remove the bullet "Recursively nested template
- instantiations [17]".
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- FR 38
-
- <td width="75">
- C.2 
- [diffs.library]
-
- <td width="31">
- 1
-
- <td width="38">
- ed
-
- <td width="375">
- 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 width="466">
- One need probably a reference
- to the document which introduce char16_t and
-
- char32_t in C (ISO/IEC TR 19769:2004?).
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- UK 
- 344
-
- <td width="75">
- Appendix D
-
- <td width="31">
- 
-
- <td width="38">
- Ge
-
- <td width="375">
- It is desirable to allow some mechanism to
- support phasing out of deprecated features in the future.
- Allowing compilers to implement a mode where deprecated
- features are not available is a good first step.
-
- <td width="466">
- Add to the definition of deprecated
- features permission for compilers to maintain a
- conditionally supported mode where deprecated features can
- be disabled, so long as they also default to a mode where
- all deprecated features are supported.
-
- <td width="225">
- 
-
- <tr valign="top">
- <td width="29">
- FR 39
-
- <td width="75">
- Index
-
- <td width="31">
- 
-
- <td width="38">
- ed
-
- <td width="375">
- Some definitions seem not
- indexed (such as /trivially copyable/ or
-
- /sequenced before/), indexing
- them would be useful (and marking specially the page -- say
- bold or italic -- which reference to the definition would
- increase the usefulness; having a separate index of all
- definitions is something which could also be considered).
-
- <td width="466">
- 
-
- <td width="225">
- 
-
- </table><hr>
\ No newline at end of file

Modified: sandbox/committee/LWG/LWG_0xCD1_status.html
==============================================================================
--- sandbox/committee/LWG/LWG_0xCD1_status.html (original)
+++ sandbox/committee/LWG/LWG_0xCD1_status.html 2009-03-04 14:25:42 EST (Wed, 04 Mar 2009)
@@ -21,7 +21,7 @@
<h1>Library Working Group 
Status of CD1 National Body Comments</h1>
Revised:
-04 Mar 2009 07:09:12 AM -0500
+04 Mar 2009 01:40:40 PM -0500

<table border="1" bordercolor="#000000" cellpadding="7"
 cellspacing="0" style="border-collapse: collapse">
@@ -100,7 +100,7 @@

 <td>
 General 
- Comment
+ Comment

 <td>
 Library
@@ -1743,8 +1743,9 @@
 166

 <td>
- 17.5.3.2.4.1, 
- 17.5.3.3
+ 17.5.3. 
+ 2.4.1, 
+ 17.5.3.3

 

@@ -1856,7 +1857,7 @@
 <td>
 

- Bill Plaugher to open issue. If the wording is too broad we need to add an
+ Bill Plauger to open issue. If the wording is too broad we need to add an
 exception to the standard C library.<tr valign="top">
 <td>
 UK 
@@ -2667,7 +2668,8 @@
 <td>
 

- <tr valign="top">
+ Straw polls: pointer safety: 9-1-10; threading: 14-2-9. Jens will open
+ multiple issues.<tr valign="top">
 <td>
 UK 
 186
@@ -2724,7 +2726,7 @@
 <td>
 

- <tr valign="top">
+ Lawrence Crowl will open an issue.<tr valign="top">
 <td>
 UK 
 188
@@ -2752,7 +2754,7 @@
 <td>
 

- agreed. Bill Plauger will open an issue.<tr valign="top">
+ Agreed. Bill Plauger will open an issue.<tr valign="top">
 <td>
 UK 
 189
@@ -2782,7 +2784,7 @@
 <td>
 

- agreed. Howard will open an issue.<tr valign="top">
+ Agreed. Howard will open an issue.<tr valign="top">
 <td>
 JP 27

@@ -3784,7 +3786,8 @@
 20.5

 [meta. 
- trans.other]<td>
+ trans. 
+ other]<td>
 Table 41

 <td>
@@ -3805,7 +3808,7 @@
 <td>
 

-  Agree. The need for aligned_union is compelling enough to reinstate.<tr valign="top">
+ Agree. The need for aligned_union is compelling enough to reinstate.<tr valign="top">
 <td>
 US 69

@@ -4034,7 +4037,8 @@

 <td>
 20.6.7 [meta. 
- trans.other]<td>
+ trans. 
+ other]<td>
 Table 51, last row, column 3

 <td>
@@ -4112,7 +4116,9 @@
 JP 38

 <td valign="top">
- 20.6.12.1.3 [func.bind. 
+ 20.6.12. 
+ 1.3 [func. 
+ bind. 
 bind]<td valign="top">
 

@@ -4178,7 +4184,8 @@
 DE-21

 <td valign="top">
- 20.6.12.1.3 [func.bind. 
+ 20.6.12. 
+ 1.3 [func.bind. 
 bind]<td valign="top">
 

@@ -4206,8 +4213,11 @@
 211

 <td valign="top">
- 20.6.12.2.3 [unique.ptr. 
- single.asgn]<td valign="top">
+ 20.6.12. 
+ 2.3 [unique. 
+ ptr. 
+ single. 
+ asgn]<td valign="top">
 11

 <td valign="top">
@@ -4270,7 +4280,8 @@
 DE-22

 <td valign="top">
- 20.6.16.2 [func.wrap. 
+ 20.6.16.2 [func. 
+ wrap. 
 func]<td valign="top">
 

@@ -5165,7 +5176,8 @@

 <td>
 20.8.12, 
- 20.8.13.2 [unique.ptr], [util. 
+ 20.8.13.2 [unique. 
+ ptr], [util. 
 smartptr. 
 shared]<td>
 
@@ -6706,7 +6718,8 @@
 JP 49

 <td>
- 22.1.3.2.2
+ 22.1.3. 
+ 2.2

 <td>
 
@@ -6735,7 +6748,8 @@
 JP 50

 <td>
- 22.1.3.2.2
+ 22.1.3. 
+ 2.2

 <td>
 
@@ -6836,7 +6850,8 @@
 FI 5

 <td>
- <tt>22.2.1.4.2</tt>
+ <tt>22.2. 
+ 1.4.2</tt>

 <td>
 #3
@@ -7402,7 +7417,8 @@
 <td>
 23

- <td>
+ [container. 
+ require-ments]<td>
 

 <td>
@@ -7439,7 +7455,7 @@
 <td>
 

- [container.requirements] Agree in principle. We suggest proposed wording:<tr valign="top">
+ Agree in principle. We suggest proposed wording:<tr valign="top">
 <td>
 JP 55

@@ -7478,7 +7494,9 @@
 <td>
 23.1.1

- <td>
+ [container. 
+ require-ments. 
+ general]<td>
 3

 <td>
@@ -7500,16 +7518,18 @@
 <td>
 

- [container.requirements.general] Agree. Proposed wording will be presented
+ Agree. Proposed wording will be presented
 in N2829 or D2840.<tr valign="top">
 <td>
 UK 
 224

 <td>
- 23.1.1
+ 23.1.1 

- <td>
+ [container. 
+ require-ments. 
+ general]<td>
 8

 <td>
@@ -7531,7 +7551,7 @@
 <td>
 

- [container.requirements.general] Agree except with moving array to clause
+ Agree except with moving array to clause
 20. Proposed wording will be presented in D2840.<tr valign="top">
 <td>
 UK 
@@ -7573,7 +7593,9 @@
 <td>
 23.1.1

- <td>
+ [container. 
+ require-ments. 
+ general]<td>
 10

 <td>
@@ -7597,7 +7619,7 @@
 <td>
 

- [container.requirements.general] Agree. The proposed resolution is
+ Agree. The proposed resolution is
 incomplete. Further work required.<tr valign="top">
 <td>
 UK 
@@ -7693,7 +7715,9 @@
 <td>
 23.1.2

- <td>
+ [container. 
+ require-ments. 
+ dataraces]<td>
 1

 <td>
@@ -7716,7 +7740,7 @@
 <td>
 

- [container.requirements.dataraces] After considerable discussion and
+ After considerable discussion and
 consideration, we do not feel this is a defect given the reference to [res.on.data.races].<tr valign="top">
 <td>
 JP 56
@@ -7762,9 +7786,8 @@
 231

 <td>
- 23.1.3
-
- <td>
+ 23.1.3 [sequence. 
+ reqmts]<td>
 9-11

 <td>
@@ -7785,15 +7808,15 @@
 <td>
 

- <tr valign="top">
+ Agree with issue and change to [sequence.reqmts]. The changes required to
+ [strings] will be part of the general concept support for that clause.<tr valign="top">
 <td>
 UK 
 232

 <td>
- 23.1.3
-
- <td>
+ 23.1.3  [sequence. 
+ reqmts]<td>
 Table 84

 <td>
@@ -7813,15 +7836,14 @@
 <td>
 

- <tr valign="top">
+ Agree. <code>operator[]</code> is defined elsewhere.<tr valign="top">
 <td>
 UK 
 233

 <td>
- 23.1.3
-
- <td>
+ 23.1.3  [sequence. 
+ reqmts]<td>
 Table 84

 <td>
@@ -7843,15 +7865,14 @@
 <td>
 

- <tr valign="top">
+ Agree.<tr valign="top">
 <td>
 UK 
 234

 <td>
- 23.1.3
-
- <td>
+ 23.1.3  [sequence. 
+ reqmts]<td>
 Table 84

 <td>
@@ -7873,7 +7894,7 @@
 <td>
 

- <tr valign="top">
+ Agree.<tr valign="top">
 <td>
 UK 
 235
@@ -7977,9 +7998,8 @@
 238

 <td>
- 23.1.4
-
- <td>
+ 23.1.4 [assoc-iative. 
+ reqmts]<td>
 6

 <td>
@@ -8009,15 +8029,15 @@
 <td>
 

- <tr valign="top">
+ Agree with issue. Agree with adding the note but not with changing the
+ normative text. We believe the note provides sufficient guidance.<tr valign="top">
 <td>
 UK 
 239

 <td>
- 23.1.4
-
- <td>
+ 23.1.4  [assoc-iative. 
+ reqmts]<td>
 85

 <td>
@@ -8043,15 +8063,17 @@
 <td>
 

- <tr valign="top">
+ We look forward to a paper on this topic. We recommend no action until a
+ paper is available. The paper would need to address exception safety.<tr valign="top">
 <td>
 UK 
 240

 <td>
- 23.1.6.1
-
- <td>
+ 23.1.6.1 
+ [container. 
+ concepts. 
+ free]<td>
 12

 <td>
@@ -8086,7 +8108,9 @@
 <td>
 

- <tr valign="top">
+ We look forward to a paper on this topic. We recommend no action until a
+ paper is available. We suspect that there are other similar issues in this
+ sub-clause (9, 10).<tr valign="top">
 <td>
 JP 57

@@ -8144,7 +8168,7 @@
 <td>
 

- <tr valign="top">
+ Duplicate of UK 224.<tr valign="top">
 <td>
 UK 
 242
@@ -8178,9 +8202,8 @@
 243

 <td>
- 23.2.1
-
- <td>
+ 23.2.1 
+ [array]<td>
 3

 <td>
@@ -8200,14 +8223,17 @@
 <td>
 

- <tr valign="top">
+ Agree. The proposed wording is forthcoming from Martin. We feel that these
+ overloads of swap are more important for array than other containers because
+ swap is not O(1) for array.<tr valign="top">
 <td>
 UK 
 244

 <td>
 23.2.1, 
- 23.2.6
+ 23.2.6 
+ [array], [vector]

 <td>
 1
@@ -8240,7 +8266,8 @@
 <td>
 

- <tr valign="top">
+ Agree with the issue but not the details of the proposed solution. Walter to
+ provide wording for the new concept.<tr valign="top">
 <td>
 UK 
 245
@@ -9586,8 +9613,10 @@
 279

 <td>
- 24.4.1.2.12, 
- 24.4.3.2.12
+ 24.4.1. 
+ 2.12, 
+ 24.4.3. 
+ 2.12

 <td>
 
@@ -9617,7 +9646,8 @@
 280

 <td>
- 24.4.1.2.4
+ 24.4.1. 
+ 2.4

 <td>
 
@@ -9647,7 +9677,8 @@
 281

 <td>
- 24.4.1.2.5
+ 24.4.1. 
+ 2.5

 <td>
 
@@ -9732,7 +9763,8 @@
 operator definition in p

 <td>
- 
+ NAD. This is compatible with C++03; and we lack a
+ consensus for change. 

 <tr valign="top">
 <td>
@@ -9788,7 +9820,7 @@
 Provide constraints

 <td>
- 
+ We agree. To be handled by Howard, Martin and PJ. 

 <tr valign="top">
 <td>
@@ -10007,7 +10039,8 @@

 <td>
 24.5.3 
- [istreambuf. 
+ [istream- 
+ buf. 
 iterator]

 <td>
@@ -10805,7 +10838,7 @@

 <td>
 27.6.1.2.2 
- [istream. 
+ [istream. 
 formatted. 
 arithmetic]

@@ -10839,7 +10872,7 @@

 <td>
 27.6.1.2.2 
- [istream. 
+ [istream. 
 formatted. 
 arithmetic]

@@ -12294,7 +12327,9 @@
 

 <td>
- Hans to make proposal. See LWG Issue 926. 
+ Hans to make proposal. See LWG Issue 926.
+ UK 313 Update and LWG 926: Accept proposed resolution, correcting
+ spelling. Move to review state. Hans to ask additional review from cpp-threads. 

 <tr valign="top">
 <td>
@@ -13869,7 +13904,8 @@

 <td>
 C.2 
- [diffs.library]
+ [diffs. 
+ library]

 <td>
 1
@@ -13896,7 +13932,9 @@
 <td>
 

- <tr valign="top">
+ Create issue. Document in question should be C99, not C90+ammendment1. The
+ rest of the section requires careful review for completeness. Example <cstdint>
+ 18.3.1 [csdtint.sym]. Assign to C liasons.<tr valign="top">
 <td>
 UK 
 344
@@ -13927,7 +13965,10 @@
 

 Deals with deprecation, needs to be discussed in general group. Attention:
- Bill Plaugher<tr valign="top">
+ Bill Plaugher
+
+ Update 2009-03-04: Mark as NAD. Compiler switches are outside the domain of
+ the standard.<tr valign="top">
 <td>
 FR 39

@@ -13956,4 +13997,4 @@
 <td>
 

- </table><hr>
\ No newline at end of file
+ Pass to the editor.</table><hr>
\ No newline at end of file

Modified: sandbox/committee/LWG/proposals/n2636.html
==============================================================================
--- sandbox/committee/LWG/proposals/n2636.html (original)
+++ sandbox/committee/LWG/proposals/n2636.html 2009-03-04 14:25:42 EST (Wed, 04 Mar 2009)
@@ -43,7 +43,7 @@

blockquote {padding: 10px; border: 1px #DDD dashed }

-a img {border: 0}
+a img {border: 0px none; }

div.google_header, div.google_footer {
 position: relative;
@@ -249,8 +249,10 @@
 â€” Remarks: additional semantic constraints on the function 
 
 â€” Error
- conditions: the default error conditions for error codes reported by the
- function. 
+ conditions: the error condition constants corresponding to error codes reported by the
+ function. 
+ Correspondence is established by the
+ system error support comparison operators ([syserr.compare]). 
 
 
 
@@ -289,16 +291,6 @@
 
 
 
- [Note: the class 
- <code id=o17040>error_condition</code> ([syserr.errcondition.overview]) object is reported via
- the <code id=o17042>default_error_condition</code> function ([syserr.errcode.observers])  of the class <code id=o17043>error_code</code>
- object representing the error. --end note.
- 
- 
- 
- 
- 
- 
 
 
</div>
@@ -637,4 +629,4 @@
 
 
 </body>
-</html>
+</html>
\ No newline at end of file

Modified: sandbox/committee/LWG/thread_safety.html
==============================================================================
--- sandbox/committee/LWG/thread_safety.html (original)
+++ sandbox/committee/LWG/thread_safety.html 2009-03-04 14:25:42 EST (Wed, 04 Mar 2009)
@@ -13,7 +13,7 @@
Doc. no.  
D2603=08-0113 
Date:       
-2008-04-27 
+2008-04-30 
Project:     Programming Language C++ 
Reply to:   Beman Dawes <bdawes at acm.org> 
               
@@ -190,13 +190,12 @@
 <blockquote>
 Functions <code>asctime</code>,
 <code>ctime</code>, <code>gmtime</code>,
- and <code>localtime</code> are not required to be thread-safe ([res.on.thread.safety]).
+ and <code>localtime</code> are not required to avoid data races ([res.on.thread.safety]).
 </blockquote>
 To 21.4 Null-terminated sequence utilities [c.strings], add:
 <blockquote>
 Functions <code>
- strerror</code> and <code>strtok</code> are not required to be
- thread-safe ([res.on.thread.safety]).
+ strerror</code> and <code>strtok</code> are not required to avoid data races ([res.on.thread.safety]).
 </blockquote>
 To 22.1.1 Class locale [locale], add a new paragraph at the end:
 <blockquote>
@@ -204,11 +203,11 @@
 entire program or one global locale object per thread is implementation
 defined. Implementations are encouraged but not required to provide one global
 locale object per thread. If there is a single global locale object for the
- entire program, it is not required to be thread-safe ([res.on.thread.safety]).
+ entire program, it is not required to avoid data races ([res.on.thread.safety]).
 </blockquote>
 At a location in 23 to be determined by the project editor, add a new paragraph:
 <blockquote>
- For purposes of determining thread-safety requirements ([res.on.thread.safety[),
+ For purposes of avoiding data races ([res.on.thread.safety[),
 implementations shall consider the following functions to be const:<code>
 begin</code>, <code>end</code>, <code>rbegin</code>, <code>rend</code>, <code>
 front</code>, <code>back</code>, <code>data</code>, <code>find</code>, <code>
@@ -232,10 +231,7 @@
 standard, except that the implementation may specify that particular library
 functions may call <code>rand</code>. 
 It is implementation defined whether or not the
- <code>rand</code> function is thread-safe ([res.on.thread.safety]).
- Implementations of <code>rand</code> are encouraged
- but not required to provide such thread-safety. Calls to <code>rand</code>
- from other library functions shall not result in data races.
+ <code>rand</code> function avoid data races ([res.on.thread.safety]).
</blockquote>
 <h2><a name="Revision-history">Revision history</a></h2>
 N2603 - Revision 2:
@@ -267,10 +263,14 @@
 N2298 - Initial version.
 <h2><a name="References">References</a></h2>
 
- <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2334.htm">
- N2334</a>, Concurrency memory model (revised again), Clark Nelson and Hans-J.
+ <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2429.htm">
+ N2429</a>, Concurrency memory model (final revision), Clark Nelson and Hans-J.
 Boehm
 
+ <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2480.html">
+ N2480</a>, A Less Formal Explanation of the Proposed C++ Concurrency Memory
+ Model, Hans-J. Boehm
+ 
 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2519.html">
 N2519</a>, Library thread-safety
 from a user's point of view, with wording, Jeffrey Yasskin

Next message: ockham_at_[hidden]: "[Boost-commit] svn:boost r51613 - in sandbox/SOC/2006/tree/trunk: boost/tree boost/tree/detail libs/tree/test"
Previous message: john_at_[hidden]: "[Boost-commit] svn:boost r51611 - trunk/libs/math/test"

Date view	Thread view	Subject view	Author view