Boost-Commit mailing page: [Boost-commit] svn:boost r51604

Date view	Thread view	Subject view	Author view

Subject: [Boost-commit] svn:boost r51604 - sandbox/committee/LWG
From: bdawes_at_[hidden]
Date: 2009-03-04 08:20:36

Next message: fmhess_at_[hidden]: "[Boost-commit] svn:boost r51605 - trunk/boost/signals2"
Previous message: daniel_james_at_[hidden]: "[Boost-commit] svn:boost r51603 - in website/public_html/live: common style/css_0"

Author: bemandawes
Date: 2009-03-04 08:20:35 EST (Wed, 04 Mar 2009)
New Revision: 51604
URL: http://svn.boost.org/trac/boost/changeset/51604

Log:
8AM Wednesday, including fixes from Daniel, Howard, and Alan
Text files modified:
sandbox/committee/LWG/LWG_0xCD1_status.html | 652 +++++++++++++++++++--------------------
1 files changed, 322 insertions(+), 330 deletions(-)

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 08:20:35 EST (Wed, 04 Mar 2009)
@@ -21,7 +21,7 @@
<h1>Library Working Group 
Status of CD1 National Body Comments</h1>
Revised:
-03 Mar 2009 05:41:54 PM -0500
+04 Mar 2009 07:09:12 AM -0500

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

- Alisdair to open issue. We prefer
- <std>only. </std>
-
- <tr valign="top">
+ Alisdair to open issue. We prefer <std> only.<tr valign="top">
 <td>
 UK 
 171
@@ -3698,7 +3695,8 @@
 20.2.12

 <td>
- IntegralLike
+ Integral 
+ Like

 <td>
 te/ed
@@ -3785,7 +3783,8 @@
 <td>
 20.5

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

 <td>
@@ -3806,10 +3805,7 @@
 <td>
 

- [meta.trans.other]
-
- 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">
+  Agree. The need for aligned_union is compelling enough to reinstate.<tr valign="top">
 <td>
 US 69

@@ -4004,9 +4000,7 @@
 US 70

 <td>
- 20.6
-
- <td>
+ 20.5 [meta]<td>
 

 <td>
@@ -4039,9 +4033,8 @@
 US 71

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

 <td>
@@ -4058,20 +4051,75 @@
 

 (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">
+ Forward to project editor. There are several ways to fix the grammar.<tr>
 <td>
- JP 38
+ DE-20
+
+ <td>
+ 20.6.12 [bind]
+
+ <td>
+ 
+
+ <td>
+ ed
+
+ <td>
+ DE-20 The section heading and the first sentence use the term
+ "template function", which is undefined.
+
+ <td>
+ Replace "template function"
+ by "function template".
+
+ 
+
+ <td>
+ 

+ Agree. Forward to the project editor.</tr>
+ <tr>
 <td>
- 20.6.12.1.3
+ US 72

 <td>
+ 20.6.12 [func.bind. 
+ bind]<td>
 

 <td>
- te
+ te
+
+ <td>
+ 
+ bind should support move-only functors and bound arguments.
+
+ 
+
+ <td>
+ 

 <td>
+ We look forward to a paper on this topic. We recommend
+ no action until a paper is available. We do think that bind would
+ require further overloads to support move semantics, if indeed move
+ semantics are possible. 
+
+ </tr>
+ <tr>
+ <td valign="top">
+ JP 38
+
+ <td valign="top">
+ 20.6.12.1.3 [func.bind. 
+ bind]<td valign="top">
+ 
+
+ <td valign="top">
+ te
+
+ <td valign="top">
 
 add the move requirement for bind's return type. 
@@ -4105,7 +4153,7 @@
 
 

- <td>
+ <td valign="top">
 Add
 the following requirements. 
 "it has a public move constructor
@@ -4114,7 +4162,7 @@
 Add
 the MoveConstructible.

- <td>
+ <td valign="top">
 

 We were not clear about what the submitter really intended. Requiring that
@@ -4124,6 +4172,183 @@
 [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>
+ <tr>
+ <td valign="top">
+ DE-21
+
+ <td valign="top">
+ 20.6.12.1.3 [func.bind. 
+ bind]<td valign="top">
+ 
+
+ <td valign="top">
+ te
+
+ <td valign="top">
+ 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 valign="top">
+ Add the missing specification in the same section, or add a
+ cross-reference indicating the section where the specification appears.
+
+ <td valign="top">
+ Agree. There are several differences (omissions) between
+ N2691 [func.bind.bind] and N2800 [func.bind.bind]. Ask the project
+ editor to review the changes. 
+
+ </tr>
+ <tr>
+ <td valign="top">
+ UK 
+ 211
+
+ <td valign="top">
+ 20.6.12.2.3 [unique.ptr. 
+ single.asgn]<td valign="top">
+ 11
+
+ <td valign="top">
+ Te
+
+ <td valign="top">
+ 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 valign="top">
+ Change signature here and in the synopsis to: unique_ptr&
+ operator=(nullptr_t); Strike the sentance an note before the Effects
+ clause.
+
+ <td valign="top">
+ Agree. 
+
+ </tr>
+ <tr>
+ <td valign="top">
+ UK 
+ 212
+
+ <td valign="top">
+ 20.6.13.7 [util. 
+ dynamic. 
+ safety]<td valign="top">
+ 
+
+ <td valign="top">
+ Te
+
+ <td valign="top">
+ 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 valign="top">
+ Move this specification to 18.5. Move the declarations
+ into the header <new>.
+
+ <td valign="top">
+ Agree in principle, but not with the proposed
+ resolution. We believe it belongs either a subsection of either 20
+ [utilities] or 20.7 [memory] as part of the general reorganization of
+ 20. The declaration should stay in
+ <memory>. </memory>
+ 
+
+ </tr>
+ <tr>
+ <td valign="top">
+ DE-22
+
+ <td valign="top">
+ 20.6.16.2 [func.wrap. 
+ func]<td valign="top">
+ 
+
+ <td valign="top">
+ te
+
+ <td valign="top">
+ 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 valign="top">
+ 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 valign="top">
+ Agree. std::reference_wrapper has the same structure,
+ and we suggest that std::function be presented in the same way as
+ std::reference_wrapper. 
+
+ </tr>
+ <tr>
+ <td valign="top">
+ US 73
+
+ <td valign="top">
+ 20.6.18 
+ [expr.prim. 
+ lambda], [func. 
+ reference 
+ closure]
+
+ <td valign="top">
+ 
+
+ <td valign="top">
+ te
+
+ <td valign="top">
+ 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 valign="top">
+ Remove 20.7.18 [func.referenceclosure].
+
+ 
+
+ Remove 5.1.1 paragraph 12.
+
+ <td valign="top">
+ This requires attention from CWG and/or EWG. 
+
+ </tr>
+
 <tr valign="top">
 <td>
 JP 39
@@ -4596,243 +4821,41 @@
 

 We look forward to a paper on this topic. We recommend no action until a
- paper is available.<tr valign="top">
- <td>
- DE-20
-
- <td>
- 20.7.12
-
- <td>
- 
-
- <td>
- ed
-
- <td>
- DE-20 The section heading and the first sentence use the
- term "template function", which is undefined.
-
- <td>
- Replace
- "template function" by "function template".
-
- 
-
- <td>
- 
-
- [bind] Agree. Forward to the project editor.<tr valign="top">
- <td>
- US 72
-
- <td>
- 20.7.12
-
- <td>
- 
-
- <td>
- te
-
+ paper is available.<tr>
 <td>
- 
- bind should support move-only functors and bound arguments.
-
- 
+ JP 44

 <td>
+ 20.7.13.6 [util. 
+ smartptr. 
+ shared. 
+ atomic]<td>
 

 <td>
- [func.bind.bind] We look forward to a paper on this
- topic. We recommend no action until a paper is available. We do think
- that bind would require further overloads to support move semantics, if
- indeed move semantics are possible. 
-
- <tr valign="top">
- <td>
- DE-21
-
- <td>
- 20.7.12.1.3
-
- <td>
- 
-
- <td>
 te

 <td>
- DE-21 The specification for bind claims twice that "the
- values and types for the bound arguments v1, v2, ..., vN
- are determined as specified below". No such specification
- appears to exist.
-
- <td>
- Add the missing specification in the same section, or
- add a cross-reference indicating the section where the
- specification appears.
-
- <td>
- [func.bind.bind] Agree. There are several differences
- (omissions) between N2691 [func.bind.bind] and N2800 [func.bind.bind].
- Ask the project editor to review the changes. 
-
- <tr valign="top">
- <td>
- UK 
- 211
-
- <td>
- 20.7.12.2.3
-
- <td>
- 11
-
- <td>
- Te
-
- <td>
- The nullptr_t
- type was introduced to resolve the null pointer literal
- problem. It should be used for the assignemnt operator, as
- with the constructor and elsewhere through the library.
-
- 
-
- <td>
- Change signature here and in the synopsis
- to: unique_ptr& operator=(nullptr_t); Strike the
- sentance an note before the Effects clause.
-
- <td>
- [unique.ptr.single.asgn] Agree. 
-
- <tr valign="top">
- <td>
- UK 
- 212
-
- <td>
- 20.7.13.7
-
- <td>
- 
-
- <td>
- Te
-
- <td>
 The
- pointer-safety API is nothing to do with smart pointers, so
- does not belong in 20.7.13. In fact it is a set of language
- support features are really belongs in clause 18, with the
- contents declared in a header that deals with
- language-support of memory management.
-
- 
-
- <td>
- Move this specification to 18.5. Move the
- declarations into the header <new>.
-
- <td>
- [util.dynamic.safety] Agree in principle, but not with
- the proposed resolution. We believe it belongs either a subsection of
- either 20 [utilities] or 20.7 [memory] as part of the general
- reorganization of 20. The declaration should stay in
- <memory>. </memory>
- 
-
- <tr valign="top">
- <td>
- DE-22
-
- <td>
- 20.7.16.2
-
- <td>
- 
-
- <td>
- te
-
- <td>
- DE-22 The conditions for deriving from
- std::unary_function and std::binary_function are unclear:
- The condition would also be satisfied if ArgTypes were
- std::vector<T1>, because it (arguably) "contains" T1.
-
- <td>
- Consider stating the conditions in normative prose
- instead of in comments in the class definition. Use
- "consists of" instead of "contains". Consider using "if and
- only if" instead of "iff".
-
- <td>
- [func.wrap.func] Agree. std::reference_wrapper has the
- same structure, and we suggest that std::function be presented in the
- same way as std::reference_wrapper. 
-
- <tr valign="top">
- <td>
- US 73
-
- <td>
- 20.7.18
-
- <td>
- 
+ 1st parameter p and 2nd parameter v is now
+ shared_ptr<T> *.

- <td>
- te
+ 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>
- 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>
-
- 
+ 
+ Change shared_ptr<T>& or add the "p shall not be
+ a null pionter" at the requires.

 <td>
- Remove 20.7.18
- [func.referenceclosure].
-
- 
-
- Remove 5.1.1 paragraph 12.
+ Agree. All of the
+ functions need a requirement that p (or v) is a pointer to a valid
+ object. 

- <td>
- [expr.prim.lambda], [func.referenceclosure] This
- requires attention from CWG and/or EWG. 
+ </tr>

 <tr valign="top">
 <td>
@@ -4908,15 +4931,46 @@
 <td>
 

- <tr valign="top">
+ <tr>
 <td>
- US 74.2
+ US 80

 <td>
- 20.8.2.2
+ 20.8.2.1 [time.traits. 
+ is_fp]<td>
+ Heading

 <td>
- (a) synopsis (b) after ¶ 14
+ ed
+
+ <td>
+ The section heading does not describe the contents.
+
+ <td>
+ Change the
+ heading “is_floating_point” to
+ “treat_as_floating_point”. Optionally
+ adjust the section’s label similarly.
+
+ 
+
+ <td>
+ 
+
+ Agree. The section name and the section label
+ ([time.traits.is_fp]) are wrong. Forward to project editor.</tr>
+
+ <tr valign="top">
+ <td>
+ US 74.2
+
+ <td>
+ 20.8.2.2 [allocator. 
+ concepts]<td>
+ (a) syn-opsis (b) after ¶ 14

 <td>
 te/ed
@@ -4931,7 +4985,7 @@
 <td>
 

- US 74 (2): [allocator.concepts] Agree. Forward to project editor.<tr valign="top">
+ Agree. Forward to project editor.<tr valign="top">
 <td>
 US 75

@@ -4964,7 +5018,9 @@
 <td>
 20.8.3

- <td>
+ [allocator. 
+ element. 
+ concepts]<td>
 

 <td>
@@ -5020,7 +5076,7 @@
 <td>
 

- [allocator.element.concepts] Agree. Forward to project editor.<tr valign="top">
+ Agree. Forward to project editor.<tr valign="top">
 <td>
 UK 
 215
@@ -5028,6 +5084,10 @@
 <td>
 20.8.3.3

+ [time. 
+ duration. 
+ arithmetic]
+
 <td>
 6,8

@@ -5047,7 +5107,7 @@
 <td>
 

- [time.duration.arithmetic] Agree. Forward to project editor.<tr valign="top">
+ Agree. Forward to project editor.<tr valign="top">
 <td>
 US 77

@@ -5105,9 +5165,9 @@

 <td>
 20.8.12, 
- 20.8.13.2
-
- <td>
+ 20.8.13.2 [unique.ptr], [util. 
+ smartptr. 
+ shared]<td>
 

 <td>
@@ -5130,19 +5190,17 @@
 

 <td>
- [unique.ptr], [util.smartptr.shared] We look forward to
+ We look forward to
 a paper on this topic. We recommend no action until a paper is
- available. We believe that the shared pointer must use the default
- deleter for the conversion to succeed. 
+ available. We believe that the shared pointer must use the default deleter for the conversion to succeed. 

 <tr valign="top">
 <td>
 US 79

 <td>
- 20.8.12.2.1
-
- <td>
+ 20.8.12.2.1 [unique.ptr. 
+ single.ctor]<td>
 

 <td>
@@ -5175,51 +5233,16 @@
 

 <td>
- [unique.ptr.single.ctor] Agree. The unique_ptr(pointer
+ Agree. The unique_ptr(pointer
 p) Requires clause should be the same as the unique_ptr() 
 Requires clause. Note that unique_ptr [unique.ptr] needs concepts. 

 <tr valign="top">
 <td>
- JP 44
-
- <td>
- 20.8.13.6
-
- <td>
- 
-
- <td>
- te
-
- <td>
- The
- 1st parameter p and 2nd parameter v is now
- shared_ptr<T> *.
-
- It
- should be shared_ptr<T>&, or if these are
- shared_ptr<T>* then add the "p shall not be a null
- pointer" at the requires.
-
- <td>
- 
- Change shared_ptr<T>& or add the "p shall not be
- a null pionter" at the requires.
-
- <td>
- [util.smartptr.shared.atomic] Agree. All of the
- functions need a requirement that p (or v) is a pointer to a valid
- object. 
-
- <tr valign="top">
- <td>
 JP 45

 <td>
- 20.9
-
- <td>
+ 20.9 [time]<td>
 

 <td>
@@ -5249,43 +5272,12 @@
 30.

 <td>
- [time] We agree that this section needs concepts. We
+ We agree that this section needs concepts. We
 look forward to a paper on this topic. We recommend no action until a
 paper is available. 

 <tr valign="top">
 <td>
- US 80
-
- <td>
- 20.9.2.1
-
- <td>
- Heading
-
- <td>
- ed
-
- <td>
- The section heading does not describe the contents.
-
- <td>
- Change the
- heading “is_floating_point” to
- “treat_as_floating_point”. Optionally
- adjust the section’s label similarly.
-
- 
-
- <td>
- 
-
- 20.8.2.1 [time.traits.is_fp] Agree. The section name and the section label
- ([time.traits.is_fp]) are wrong. Forward to project editor.<tr valign="top">
- <td>
 US 81

 <td>

Next message: fmhess_at_[hidden]: "[Boost-commit] svn:boost r51605 - trunk/boost/signals2"
Previous message: daniel_james_at_[hidden]: "[Boost-commit] svn:boost r51603 - in website/public_html/live: common style/css_0"

Date view	Thread view	Subject view	Author view