| Doc. no. | N3208=10-0198 |
| Date: | 2010-11-12 |
| Project: | Programming Language C++ |
| Reply to: | Alisdair Meredith <lwgchair@gmail.com> |
The following Library Working Group issues were moved to "Ready" to applied directly to the C++0x working document in the 2010 Batavia meeting.
Section: 20.8.2 [func.require] Status: Immediate Submitter: Jens Maurer Opened: 2009-12-21 Last modified: 2010-11-08
View other active issues in [func.require].
View all other issues in [func.require].
View all issues with Immediate status.
Discussion:
The current wording in the standard makes it hard to discriminate the difference between a "call wrapper" as defined in 20.8.1 [func.def]/5+6:
5 A call wrapper type is a type that holds a callable object and supports a call operation that forwards to that object.
6 A call wrapper is an object of a call wrapper type.
and a "forwarding call wrapper" as defined in 20.8.2 [func.require]/4:
4 [..] A forwarding call wrapper is a call wrapper that can be called with an argument list. [Note: in a typical implementation forwarding call wrappers have an overloaded function call operator of the form
template<class... ArgTypes> R operator()(ArgTypes&&... args) cv-qual;— end note]
Reason for this lack of clear difference seems to be that the wording adaption to variadics and rvalues that were applied after it's original proposal in N1673:
[..] A forwarding call wrapper is a call wrapper that can be called with an argument list t1, t2, ..., tN where each ti is an lvalue. The effect of calling a forwarding call wrapper with one or more arguments that are rvalues is implementation defined. [Note: in a typical implementation forwarding call wrappers have overloaded function call operators of the form
template<class T1, class T2, ..., class TN> R operator()(T1& t1, T2& t2, ..., TN& tN) cv-qual;— end note]
combined with the fact that the word "forward" has two different meanings in this context. This issue attempts to clarify the difference better.
[ 2010-09-14 Daniel provides improved wording and verified that it is correct against N3126. Previous resolution is shown here: ]
4 [..] A forwarding call wrapper is a call wrapper that can be called with an arbitrary argument list and uses perfect forwarding to deliver the arguments to the wrapped callable object. [Note: in a typical implementation forwarding call wrappers have an overloaded function call operator of the form
template<class... ArgTypes> R operator()(ArgTypes&&... args) cv-qual;— end note]
Proposed resolution:
Change 20.8.2 [func.require]/4 as indicated:
[..] A forwarding call wrapper is a call wrapper that can be called with an arbitrary argument list and delivers the arguments as references to the wrapped callable object. This forwarding step shall ensure that rvalue arguments are delivered as rvalue-references and lvalue arguments are delivered as lvalue-references. [Note: in a typical implementation forwarding call wrappers have an overloaded function call operator of the form
template<class... UnBoundArgs> R operator()(UnBoundArgs&&... unbound_args) cv-qual;— end note ]
Section: 17.3.7 [defns.deadlock] Status: Immediate Submitter: BSI Opened: 2010-08-25 Last modified: 2010-11-12
View all issues with Immediate status.
Discussion:
Addresses GB-52
The definition of deadlock in 17.3.7 excludes cases involving a single thread making it incorrect.
[ Resolution proposed by ballot comment ]
The definition should be corrected.
[ 2010 Batavia Concurrency group provides a Proposed Resolution ]
Proposed resolution:
Change 17.3.7 [defns.deadlock] as indicated:deadlocktwoone or more threads are unable to continue execution because each is blocked waiting for one or more of the others to satisfy some condition.
Section: 17.6.3.9 [res.on.arguments] Status: Immediate Submitter: INCITS Opened: 2010-08-25 Last modified: 2010-11-08
View all other issues in [res.on.arguments].
View all issues with Immediate status.
Discussion:
Addresses US-82
17.6.3.9 [res.on.arguments] p.1. b.3: The second Note can benefit by adopting recent nomenclature.
[ Resolution proposed by the ballot comment: ]
Rephrase the Note in terms of xvalue.
[ Pre-Batavia: ]
Walter Brown provides wording.
[Batavia: Immediate]
Proposed resolution:
Amend the note in 17.6.3.9 [res.on.arguments] p1 bullet 3.
[ Note: If a program casts an lvalue to anrvaluexvalue while passing that lvalue to a library function (e.g. by calling the function with the argument move(x)), the program is effectively asking that function to treat that lvalue as a temporary. The implementation is free to optimize away aliasing checks which might be needed if the argument was anlvalue. —endnote]
Section: 18.8.5 [uncaught] Status: Immediate Submitter: BSI Opened: 2010-08-25 Last modified: 2010-11-12
View all issues with Immediate status.
Discussion:
Addresses GB-73
The thread safety std::uncaught_exception() and the result of the function when multiple threads throw exceptions at the same time are unspecified. To make the function safe to use in the presence of exceptions in multiple threads the specification needs to be updated.
[ Resolution proposed by ballot comment ]
Update this clause to support safe calls from multiple threads without placing synchronization requirements on the user.
[ 2010 Batavia Concurrency group provides a Proposed Resolution ]
Proposed resolution:
Change 18.8.5 [uncaught] p. 1 as follows:
Returns: true after the current thread has initialized initializing
an exception object (15.1) until a handler for the exception (including unexpected() or terminate())
is activated (15.3). [ Note: This includes stack unwinding (15.2). — end note ]
Section: 18.8.7 [except.nested] Status: Immediate Submitter: INCITS Opened: 2010-08-25 Last modified: 2010-11-10
View all other issues in [except.nested].
View all issues with Immediate status.
Discussion:
Addresses US-84
The throw_with_nested specification passes in its argument as T&& (perfect forwarding pattern), but then discusses requirements on T without taking into account that T may be an lvalue-reference type. It is also not clear in the spec that t is intended to be perfectly forwarded.
[ Resolution proposed by ballot comment ]
Patch [except.nested] p6-7 to match the intent with regards to requirements on T and the use of std::forward<T>(t).
[ 2010-10-24 Daniel adds: ]
Accepting n3144 would solve this issue.
[2010-11-10 Batavia: LWG accepts Howard's updated wording with corrected boo boos reported by Sebastian Gesemann and Pete Becker, which is approved for Immediate adoption this meeting.]
Proposed resolution:
Change 18.8.7 nested_exception [except.nested] as indicated:
[[noreturn]] template <class T> void throw_with_nested(T&& t);Let U be remove_reference<T>::type
6 Requires:
TU shall be CopyConstructible.7 Throws: If
TU is a non-union class type not derived from nested_exception, an exception of unspecified type that is publicly derived from bothTU and nested_exception and constructed from std::forward<T>(t), otherwise throws std::forward<T>(t).
Section: 26.4.7 [complex.value.ops] Status: Immediate Submitter: BSI Opened: 2010-08-25 Last modified: 2010-11-11
View all other issues in [complex.value.ops].
View all issues with Immediate status.
Discussion:
Addresses GB-120
The complex number functions added for compatibility with the C99 standard library are defined purely as a cross-reference, with no hint of what they should return. This is distinct from the style of documentation for the functions in the earlier standard. In the case of the inverse-trigonometric and hyperbolic functions, a reasonable guess of the functionality may be made from the name, this is not true of the cproj function, which apparently returns the projection on the Reimann Sphere. A single line description of each function, associated with the cross-reference, will greatly improve clarity.[2010-11-06 Beman provides proposed resolution wording.]
[ 2010 Batavia: The working group concurred with the issue's Proposed Resolution ]
Proposed resolution:
Change 26.4.7 complex value operations [complex.value.ops] as indicated:
template<class T> complex<T> proj(const complex<T>& x);
Returns: the projection of x onto the Riemann sphere.
Effects:Remarks: Behaves the same as the C function cproj, defined in 7.3.9.4.
Change 26.4.8 complex transcendentals [complex.transcendentals] as indicated:
template<class T> complex<T> acos(const complex<T>& x);
Returns: the complex arc cosine of x.
Effects:Remarks: Behaves the same as the C function cacos, defined in 7.3.5.1.
Change 26.4.8 complex transcendentals [complex.transcendentals] as indicated:
template<class T> complex<T> asin(const complex<T>& x);
Returns: the complex arc sine of x.
Effects:Remarks: Behaves the same as the C function casin, defined in 7.3.5.2.
Change 26.4.8 complex transcendentals [complex.transcendentals] as indicated:
template<class T> complex<T> atan(const complex<T>& x);
Returns: the complex arc tangent of x.
Effects:Remarks: Behaves the same as the C function catan, defined in 7.3.5.3.
Change 26.4.8 complex transcendentals [complex.transcendentals] as indicated:
template<class T> complex<T> acosh(const complex<T>& x);
Returns: the complex arc hyperbolic cosine of x.
Effects:Remarks: Behaves the same as the C function cacosh, defined in 7.3.6.1.
Change 26.4.8 complex transcendentals [complex.transcendentals] as indicated:
template<class T> complex<T> asinh(const complex<T>& x);
Returns: the complex arc hyperbolic sine of x.
Effects:Remarks: Behaves the same as the C function casinh, defined in 7.3.6.2.
Change 26.4.8 complex transcendentals [complex.transcendentals] as indicated:
template<class T> complex<T> atanh(const complex<T>& x);
Returns: the complex arc hyperbolic tangent of x.
Effects:Remarks: Behaves the same as the C function catanh, defined in 7.3.6.2.
Section: 26.5.3 [rand.eng] Status: Immediate Submitter: BSI Opened: 2010-08-25 Last modified: 2010-11-11
View all other issues in [rand.eng].
View all issues with Immediate status.
Discussion:
Addresses GB-121
All the random number engine types in this clause have a constructor taking an unsigned integer type, and a constructor template for seed sequences. This means that an attempt to create a random number engine seeded by an integer literal must remember to add the appropriate unsigned suffix to the literal, as a signed integer will attempt to use the seed sequence template, yielding undefined behaviour, as per 26.5.1.1p1a. It would be helpful if at least these anticipated cases produced a defined behaviour, either an erroneous program with diagnostic, or a conversion to unsigned int forwarding to the appropriate constructor.[ 2010-11-03 Daniel comments and provides a proposed resolution: ]
I suggest to apply a similar solution as recently suggested for 1234. It is basically a requirement for an implementation to constrain the template.
[ 2010-11-04 Howard suggests to use !is_convertible<Sseq, result_type>::value as minimum requirement instead of the originally proposed !is_scalar<Sseq>::value. This would allow for a user-defined type BigNum, that is convertible to result_type, to be used as argument for a seed instead of a seed sequence. The wording has been updated to reflect this suggestion. ]
[ 2010 Batavia: There were some initial concerns regarding the portability and reproducibility of results when seeded with a negative signed value, but these concerns were allayed after discussion. Thus, after reviewing the issue, the working group concurred with the issue's Proposed Resolution. ]
Proposed resolution:
Add the following paragraph at the end of 26.5.3 [rand.eng]:5 Each template specified in this section [rand.eng] requires one or more relationships, involving the value(s) of its non-type template parameter(s), to hold. A program instantiating any of these templates is ill-formed if any such required relationship fails to hold.? For every random number engine and for every random number engine adaptor X defined in this sub-clause [rand.eng] and in sub-clause [rand.adapt]:The extent to which an implementation determines that a type cannot be a seed sequence is unspecified, except that as a minimum a type shall not qualify as seed sequence, if it is implicitly convertible to X::result_type.
- If the constructor
is called with a type Sseq that does not qualify as a seed sequence, then this constructor shall not participate in overload resolution.template<class Sseq> explicit X(Sseq& q);- If the member function
is called with a type Sseq that does not qualify as a seed sequence, then this function shall not participate in overload resolution.template<class Sseq> void seed(Sseq& q);
Section: 26.5.3.2 [rand.eng.mers] Status: Immediate Submitter: INCITS Opened: 2010-08-25 Last modified: 2010-11-11
View all other issues in [rand.eng.mers].
View all issues with Immediate status.
Discussion:
Addresses US-124
The Mersenne twister algorithm is meaningless for word sizes less than two, as there are then insufficient bits available to be “twisted”.[ Resolution proposed by ballot comment: ]
Insert the following among the relations that are required to hold: 2u < w.
[ 2010 Batavia: The working group concurred with the issue's Proposed Resolution ]
Proposed resolution:
Change 26.5.3.2 [rand.eng.mers] p. 4 as indicated:4 The following relations shall hold: 0 < m, m <= n, 2u < w, r <= w, u <= w, s <= w, t <= w, l <= w, w <= numeric_limits<UIntType>::digits, a <= (1u<<w) - 1u, b <= (1u<<w) - 1u, c <= (1u<<w) - 1u, d <= (1u<<w) - 1u, and f <= (1u<<w) - 1u.
Section: 26.5.8.5.2 [rand.dist.samp.pconst] Status: Immediate Submitter: INCITS Opened: 2010-08-25 Last modified: 2010-11-12
View all other issues in [rand.dist.samp.pconst].
View all issues with Immediate status.
Discussion:
Addresses US-134
These two distributions have a member function called densities() which returns a vector<double>. The distribution is templated on RealType. The distribution also has another member called intervals() which returns a vector<RealType>. Why doesn't densities return vector<RealType> as well? If RealType is long double, the computed densities property isn't being computed to the precision the client desires. If RealType is float, the densities vector is taking up twice as much space as the client desires.[ Resolution proposed by ballot comment: ]
Change the piecewise constant and linear distributions to hold / return the densities in a vector<result_type>. If this is not done, at least correct 26.5.8.5.2 [rand.dist.samp.pconst] p. 13 which describes the return of densities as a vector<result_type>.
[ Batavia 2010: After reviewing this issue, the working group concurred with the first of the suggestions proposed by the NB comment: "Change the piecewise constant and linear distributions to hold / return the densities in a vector. " ]
Proposed resolution:
vector<doubleresult_type> densities() const;
vector<doubleresult_type> densities() const;
Section: 26.5.8.5.3 [rand.dist.samp.plinear] Status: Immediate Submitter: INCITS Opened: 2010-08-25 Last modified: 2010-11-11
View all issues with Immediate status.
Discussion:
Addresses US-135
This paragraph says: Let bk = xmin+k·δ for k = 0,...,n, and wk = fw(bk +δ) for k = 0,...,n. However I believe that fw(bk) would be far more desirable. I strongly suspect that this is nothing but a type-o.[ Resolution proposed by ballot comment: ]
Change p. 10 to read:
Let bk = xmin+k·δ for k = 0,...,n, and wk = fw(bk) for k = 0,...,n.
[ 2010-11-02 Daniel translates into a proposed resolution ]
[ 2010 Batavia: The working group concurred with the issue's Proposed Resolution ]
Proposed resolution:
Change 26.5.8.5.3 [rand.dist.samp.plinear] p. 10 as indicated:10 Effects: Constructs a piecewise_linear_distribution object with parameters taken or calculated from the following values: Let bk = xmin+k·δ for k = 0, . . . , n, and wk = fw(bk+δ) for k = 0, . . . , n.
Section: 26.4.9 [cmplx.over] Status: Immediate Submitter: P.J. Plauger Opened: 2010-10-14 Last modified: 2010-11-11
View all other issues in [cmplx.over].
View all issues with Immediate status.
Discussion:
In Pittsburgh, we accepted the resolution of library issue 1137, to add a sentence 3 to [cmplx.over]:
All the specified overloads shall have a return type which is the nested value_type of the effectively cast arguments."
This was already true for four of the six functions except conj and proj. It is not completely unreasonable to make proj return the real value only, but the IEC specification does call for an imaginary part of -0 in some circumstances. The people who care about these distinctions really care, and it is required by an international standard.
Making conj return just the real part breaks it horribly, however. It is well understood in mathematics that conj(re + i*im) is (re - i*im), and it is widely used. The accepted new definition makes conj useful only for pure real operations. This botch absolutely must be fixed.
[ 2010 Batavia: The working group concurred with the issue's Proposed Resolution ]
Proposed resolution:
Remove the recently added paragraph 3 from [cmplx.over]:
3 All the specified overloads shall have a return type which is the nested value_type of the effectively cast arguments.