Revised 2011-02-28 at 12:02:47 UTC

Unresolved Issues


964. Various threading bugs #14

Section: 30.5.2 [thread.condition.condvarany] Status: Open Submitter: Pete Becker Opened: 2009-01-07 Last modified: 2011-02-21

View all other issues in [thread.condition.condvarany].

View all issues with Open status.

Discussion:

The requirements for the constructor for condition_variable has several error conditions, but the requirements for the constructor for condition_variable_any has none. Is this difference intentional?

[ Summit: ]

Move to open, pass to Howard. If this is intentional, a note may be helpful. If the error conditions are to be copied from condition_variable, this depends on LWG 965.

[ Post Summit Howard adds: ]

The original intention (N2447) was to let the OS return whatever errors it was going to return, and for those to be translated into exceptions, for both condition_variable and condition_variable_any. I have not received any complaints about specific error conditions from vendors on non-POSIX platforms, but such complaints would not surprise me if they surfaced.

[ 2009-10 Santa Cruz: ]

Leave open. Benjamin to provide wording.

[ 2010 Pittsburgh: ]

We don't have throw clauses for condition variables.

This issue may be dependent on LWG 1268.

Leave open. Detlef will coordinate with Benjamin.

Consider merging LWG 964, 966, and 1268 into a single paper.

Proposed resolution:


966. Various threading bugs #16

Section: 30.5.1 [thread.condition.condvar] Status: Open Submitter: Pete Becker Opened: 2009-01-07 Last modified: 2011-02-21

View all other issues in [thread.condition.condvar].

View all issues with Open status.

Discussion:

30.5.1 [thread.condition.condvar]: condition_variable::wait and condition_variable::wait_until both have a postcondition that lock is locked by the calling thread, and a throws clause that requires throwing an exception if this postcondition cannot be achieved. How can the implementation detect that this lock can never be obtained?

[ Summit: ]

Move to open. Requires wording. Agreed this is an issue, and the specification should not require detecting deadlocks.

[ 2009-08-01 Howard provides wording. ]

The proposed wording is inspired by the POSIX spec which says:

[EINVAL]
The value specified by cond or mutex is invalid.
[EPERM]
The mutex was not owned by the current thread at the time of the call.

I do not believe [EINVAL] is possible without memory corruption (which we don't specify). [EPERM] is possible if this thread doesn't own the mutex, which is listed as a precondition. "May" is used instead of "Shall" because not all OS's are POSIX.

[ 2009-10 Santa Cruz: ]

Leave open, Detlef to provide improved wording.

[ 2009-10-23 Detlef Provided wording. ]

Detlef's wording put in Proposed resolution. Original wording here:

Change 30.5.1 [thread.condition.condvar] p12, p19 and 30.5.2 [thread.condition.condvarany] p10, p16:

Throws: May throw std::system_error if a precondition is not met. when the effects or postcondition cannot be achieved.

[ 2009-10 Santa Cruz: ]

Leave open, Detlef to provide improved wording.

[ 2009-11-18 Anthony adds: ]

condition_variable::wait takes a unique_lock<mutex>. We know whether or not a unique_lock owns a lock, through use of its owns_lock() member.

I would like to propose the following resolution:

Modify the first sentence of 30.5.1 [thread.condition.condvar] p9:

void wait(unique_lock<mutex>& lock);

9 Precondition: lock is locked by the calling thread lock.owns_lock() is true, and either

...

Replace 30.5.1 [thread.condition.condvar] p11-13 with:

void wait(unique_lock<mutex>& lock);

...

11 Postcondition: lock is locked by the calling thread lock.owns_lock() is true.

12 Throws: std::system_error when the effects or postcondition cannot be achieved if the implementation detects that the preconditions are not met or the effects cannot be achieved. Any exception thrown by lock.lock() or lock.unlock().

13 Error Conditions: The error conditions are implementation defined.

  • equivalent error condition from lock.lock() or lock.unlock().

[ 2010 Pittsburgh: ]

There are heavy conflicts with adopted papers.

This issue is dependent on LWG 1268.

Leave open pending outstanding edits to the working draft. Detlef will provide wording.

Possibly related to 964.

Proposed resolution:

Replace 30.5.1 [thread.condition.condvar] p12, p19 and 30.5.2 [thread.condition.condvarany] p10, p16:

Throws: std::system_error when the effects or postcondition cannot be achieved.

Error conditions:

Throws: It is implementation-defined whether a std::system_error with implementation-defined error condition is thrown if the precondition is not met.


985. Allowing throwing move

Section: 23.2.1 [container.requirements.general] Status: Open Submitter: Rani Sharoni Opened: 2009-02-12 Last modified: 2011-02-21

View other active issues in [container.requirements.general].

View all other issues in [container.requirements.general].

View all issues with Open status.

Discussion:

Introduction

This proposal is meant to resolve potential regression of the N2800 draft, see next section, and to relax the requirements for containers of types with throwing move constructors.

The basic problem is that some containers operations, like push_back, have a strong exception safety guarantee (i.e. no side effects upon exception) that are not achievable when throwing move constructors are used since there is no way to guarantee revert after partial move. For such operations the implementation can at most provide the basic guarantee (i.e. valid but unpredictable) as it does with multi copying operations (e.g. range insert).

For example, vector<T>::push_back() (where T has a move constructor) might resize the vector and move the objects to the new underlying buffer. If move constructor throws it might not be possible to recover the throwing object or to move the old objects back to the original buffer.

The current draft is explicit by disallowing throwing move for some operations (e.g. vector<>::reserve) and not clear about other operations mentioned in 23.2.1 [container.requirements.general]/10 (e.g. single element insert): it guarantees strong exception safety without explicitly disallowing a throwing move constructor.

Regression

This section only refers to cases in which the contained object is by itself a standard container.

Move constructors of standard containers are allowed to throw and therefore existing operations are broken, compared with C++03, due to move optimization. (In fact existing implementations like Dinkumware are actually throwing).

For example, vector< list<int> >::reserve yields undefined behavior since list<int>'s move constructor is allowed to throw. On the other hand, the same operation has strong exception safety guarantee in C++03.

There are few options to solve this regression:

  1. Disallow throwing move and throwing default constructor
  2. Disallow throwing move but disallowing usage after move
  3. Special casing
  4. Disallow throwing move and making it optional

Option 1 is suggested by proposal N2815 but it might not be applicable for existing implementations for which containers default constructors are throwing.

Option 2 limits the usage significantly and it's error prone by allowing zombie objects that are nothing but destructible (e.g. no clear() is allowed after move). It also potentially complicates the implementation by introducing special state.

Option 3 is possible, for example, using default construction and swap instead of move for standard containers case. The implementation is also free to provide special hidden operation for non throwing move without forcing the user the cope with the limitation of option-2 when using the public move.

Option 4 impact the efficiency in all use cases due to rare throwing move.

The proposed wording will imply option 1 or 3 though option 2 is also achievable using more wording. I personally oppose to option 2 that has impact on usability.

Relaxation for user types

Disallowing throwing move constructors in general seems very restrictive since, for example, common implementation of move will be default construction + swap so move will throw if the default constructor will throw. This is currently the case with the Dinkumware implementation of node based containers (e.g. std::list) though this section doesn't refer to standard types.

For throwing move constructors it seem that the implementation should have no problems to provide the basic guarantee instead of the strong one. It's better to allow throwing move constructors with basic guarantee than to disallow it silently (compile and run), via undefined behavior.

There might still be cases in which the relaxation will break existing generic code that assumes the strong guarantee but it's broken either way given a throwing move constructor since this is not a preserving optimization.

[ Batavia (2009-05): ]

Bjarne comments (referring to his draft paper): "I believe that my suggestion simply solves that. Thus, we don't need a throwing move."

Move to Open and recommend it be deferred until after the next Committee Draft is issued.

[ 2009-10 Santa Cruz: ]

Should wait to get direction from Dave/Rani (N2983).

[ 2010-03-28 Daniel updated wording to sync with N3092. ]

The suggested change of 23.3.3.4 [deque.modifiers]/2 should be removed, because the current wording does say more general things:

2 Remarks: If an exception is thrown other than by the copy constructor, move constructor, assignment operator, or move assignment operator of T there are no effects. If an exception is thrown by the move constructor of a non-CopyConstructible T, the effects are unspecified.

The suggested change of 23.3.6.3 [vector.capacity]/2 should be removed, because the current wording does say more general things:

2 Effects: A directive that informs a vector of a planned change in size, so that it can manage the storage allocation accordingly. After reserve(), capacity() is greater or equal to the argument of reserve if reallocation happens; and equal to the previous value of capacity() otherwise. Reallocation happens at this point if and only if the current capacity is less than the argument of reserve(). If an exception is thrown other than by the move constructor of a non-CopyConstructible type, there are no effects.

Proposed resolution:

23.2.1 [container.requirements.general] paragraph 11 add footnote:

-11- Unless otherwise specified (see 23.1.4.1, 23.1.5.1, 23.2.2.3, and 23.2.6.4) all container types defined in this Clause meet the following additional requirements:

[Note: for compatibility with C++ 2003, when "no effect" is required, standard containers should not use the value_type's throwing move constructor when the contained object is by itself a standard container. -- end note]

23.2.5.1 [unord.req.except] change paragraph 2 to say:

-2- For unordered associative containers, if an exception is thrown by any operation other than the container's hash function from within an insert() function inserting a single element, the insert() function has no effect unless the exception is thrown by the contained object move constructor.

-4- For unordered associative containers, if an exception is thrown from within a rehash() function other than by the container's hash function or comparison function, the rehash() function has no effect unless the exception is thrown by the contained object move constructor.

23.3.3.4 [deque.modifiers] change paragraph 2 to say:

-2- Remarks: If an exception is thrown other than by the copy constructor, move constructor or assignment operator of T there are no effects. If an exception is thrown by push_back() or emplace_back() function, that function has no effects unless the exception is thrown by the move constructor of T.

23.3.6.3 [vector.capacity] paragraph 2 change to say:

-2- Effects: A directive that informs a vector of a planned change in size, so that it can manage the storage allocation accordingly. After reserve(), capacity() is greater or equal to the argument of reserve if reallocation happens; and equal to the previous value of capacity() otherwise. Reallocation happens at this point if and only if the current capacity is less than the argument of reserve(). If an exception is thrown, there are no effects unless the exception is thrown by the contained object move constructor.

23.3.6.3 [vector.capacity] paragraph 12 change to say:

-12- Requires: If value_type has a move constructor, that constructor shall not throw any exceptions. If an exception is thrown, there are no effects unless the exception is thrown by the contained object move constructor.

23.3.6.5 [vector.modifiers] change paragraph 1 to say:

-1- Requires: If value_type has a move constructor, that constructor shall not throw any exceptions. Remarks: If an exception is thrown by push_back() or emplace_back() function, that function has no effect unless the exception is thrown by the move constructor of T.


1169. num_get not fully compatible with strto*

Section: 22.4.2.1.2 [facet.num.get.virtuals] Status: Open Submitter: Cosmin Truta Opened: 2009-07-04 Last modified: 2011-02-21

View all other issues in [facet.num.get.virtuals].

View all issues with Open status.

Discussion:

As specified in the latest draft, N2914, num_get is still not fully compatible with the following C functions: strtoul, strtoull, strtof and strtod.

In C, when conversion of a string to an unsigned integer type falls outside the representable range, strtoul and strtoull return ULONG_MAX and ULLONG_MAX, respectively, regardless whether the input field represents a positive or a negative value. On the other hand, the result of num_get conversion of negative values to unsigned integer types is zero. This raises a compatibility issue.

Moreover, in C, when conversion of a string to a floating-point type falls outside the representable range, strtof, strtod and strtold return ±HUGE_VALF, ±HUGE_VAL and ±HUGE_VALL, respectively. On the other hand, the result of num_get conversion of such out-of-range floating-point values results in the most positive/negative representable value. Although many C library implementations do implement HUGE_VAL (etc.) as the highest representable (which is, usually, the infinity), this isn't required by the C standard. The C library specification makes no statement regarding the value of HUGE_VAL and friends, which potentially raises the same compatibility issue as in the above case of unsigned integers. In addition, neither C nor C++ define symbolic constants for the maximum representable floating-point values (they only do so only for the maximum representable finite floating-point values), which raises a usability issue (it would be hard for the programmer to check the result of num_get against overflow).

As such, we propose to adjust the specification of num_get to closely follow the behavior of all of its underlying C functions.

[ 2010 Rapperswil: ]

Some concern that this is changing the specification for an existing C++03 function, but it was pointed out that this was underspecified as resolved by issue 23. This is clean-up for that issue in turn. Some concern that we are trying to solve the same problem in both clause 22 and 27.

Bill: There's a change here as to whether val is stored to in an error case.

Pablo: Don't think this changes whether val is stored to or not, but changes the value that is stored.

Bill: Remembers having skirmishes with customers and testers as to whether val is stored to, and the resolution was not to store in error cases.

Howard: Believes since C++03 we made a change to always store in overflow.

Everyone took some time to review the issue.

Pablo: C++98 definitely did not store any value during an error condition.

Dietmar: Depends on the question of what is considered an error, and whether overflow is an error or not, which was the crux of LWG 23.

Pablo: Yes, but given the "zero, if the conversion function fails to convert the entire field", we are requiring every error condition to store.

Bill: When did this happen?

Alisdair: One of the last two or three meetings.

Dietmar: To store a value in case of failure is a very bad idea.

Move to Open, needs more study.

Proposed resolution:

Change 22.4.2.1.2 [facet.num.get.virtuals] as follows:

Stage 3: The sequence of chars accumulated in stage 2 (the field) is converted to a numeric value by the rules of one of the functions declared in the header <cstdlib>:

The numeric value to be stored can be one of:

The resultant numeric value is stored in val. If the conversion function fails to convert the entire field, or if the field represents a value outside the range of representable values, ios_base::failbit is assigned to err.


1175. unordered complexity

Section: 23.2.5 [unord.req] Status: Open Submitter: Pablo Halpern Opened: 2009-07-17 Last modified: 2011-02-28

View other active issues in [unord.req].

View all other issues in [unord.req].

View all issues with Open status.

Discussion:

When I look at the unordered_* constructors, I think the complexity is poorly described and does not follow the style of the rest of the standard.

The complexity for the default constructor is specified as constant. Actually, it is proportional to n, but there are no invocations of value_type constructors or other value_type operations.

For the iterator-based constructor the complexity should be:

Complexity: exactly n calls to construct value_type from InputIterator::value_type (where n = distance(f,l)). The number of calls to key_equal::operator() is proportional to n in the average case and n*n in the worst case.

[ 2010 Rapperswil: ]

Concern that the current wording may require O(1) where that cannot be delivered. We need to look at both the clause 23 requirements tables and the constructor description of each unordered container to be sure.

Howard suggests NAD Editorial as we updated the container requirement tables since this issue was written.

Daniel offers to look deeper, and hopefully produce wording addressing any outstanding concerns at the next meeting.

Move to Open.

[2011-02-26: Daniel provides wording]

I strongly suggest to clean-up the differences between requirement tables and individual specifications. In the usual way, the most specific specifications wins, which is in this case the wrong one. In regard to the concern expressed about missing DefaultConstructible requirements of the value type I disagree: The function argument n is no size-control parameter, but only some effective capacity parameter: No elements will be value-initialized by these constructors. The necessary requirement for the value type, EmplaceConstructible into *this, is already listed in Table 103 — Unordered associative container requirements. Another part of the proposed resolution is the fact that there is an inconsistency of the complexity counting when both a range and a bucket count is involved compared to constructions where only bucket counts are provided: E.g. the construction X a(n); has a complexity of n bucket allocations, but this part of the work is omitted for X a(i, j, n);, even though it is considerable larger (in the average case) for n ≫ distance(i, j).

Proposed resolution:

  1. Modify the following rows in Table 103 — Unordered associative container requirements to add the explicit bucket allocation overhead of some constructions. As editorial recommendation it is suggested not to shorten the sum 𝒪(n) + 𝒪(N) to 𝒪(n + N), because two different work units are involved.

    Table 103 — Unordered associative container requirements (in addition to container)
    Expression Return type Assertion⁄note pre-⁄post-condition Complexity
    X(i, j, n, hf, eq)
    X a(i, j, n, hf, eq)
    X
    Effects: Constructs an empty container with at least n
    buckets, using hf as the hash function and eq as the key
    equality predicate, and inserts elements from [i, j) into it.
    Average case 𝒪(n) + 𝒪(N) (N is distance(i, j)),
    worst case 𝒪(n) + 𝒪(N2)
    X(i, j, n, hf)
    X a(i, j, n, hf)
    X
    Effects: Constructs an empty container with at least n
    buckets, using hf as the hash function and key_equal() as the key
    equality predicate, and inserts elements from [i, j) into it.
    Average case 𝒪(n) + 𝒪(N) (N is distance(i, j)),
    worst case 𝒪(n) + 𝒪(N2)
    X(i, j, n)
    X a(i, j, n)
    X
    Effects: Constructs an empty container with at least n
    buckets, using hasher() as the hash function and key_equal() as the key
    equality predicate, and inserts elements from [i, j) into it.
    Average case 𝒪(n) + 𝒪(N) (N is distance(i, j)),
    worst case 𝒪(n) + 𝒪(N2)
  2. Modify 23.5.4.2 [unord.map.cnstr] p. 1-4 as indicated (The edits of p. 1 and p. 3 attempt to fix some editorial oversight.):

    explicit unordered_map(size_type n = see below,
                           const hasher& hf = hasher(),
                           const key_equal& eql = key_equal(),
                           const allocator_type& a = allocator_type());
    

    1 Effects: Constructs an empty unordered_map using the specified hash function, key equality function, and allocator, and using at least n buckets. If n is not provided, the number of buckets is implementation-definedimpldefdefault number of buckets in unordered_map. max_load_factor() returns 1.0.

    2 Complexity: Constant if n is not provided, otherwise linear in n to construct the buckets.

    template <class InputIterator>
    unordered_map(InputIterator f, InputIterator l,
                  size_type n = see below,
                  const hasher& hf = hasher(),
                  const key_equal& eql = key_equal(),
                  const allocator_type& a = allocator_type());
    

    3 Effects: Constructs an empty unordered_map using the specified hash function, key equality function, and allocator, and using at least n buckets. If n is not provided, the number of buckets is implementation-definedimpldefdefault number of buckets in unordered_map. Then inserts elements from the range [f, l). max_load_factor() returns 1.0.

    4 Complexity: Average case linear, worst case quadraticConstant if n is not provided, else linear in n to construct the buckets. In the average case linear in N and in the worst case quadratic in N to insert the elements, where N is equal to distance(f, l).

  3. Modify 23.5.5.2 [unord.multimap.cnstr] p. 1-4 as indicated (The edits of p. 1 and p. 3 attempt to fix some editorial oversight.):

    explicit unordered_multimap(size_type n = see below,
                                const hasher& hf = hasher(),
                                const key_equal& eql = key_equal(),
                                const allocator_type& a = allocator_type());
    

    1 Effects: Constructs an empty unordered_multimap using the specified hash function, key equality function, and allocator, and using at least n buckets. If n is not provided, the number of buckets is implementation-definedimpldefdefault number of buckets in unordered_multimap. max_load_factor() returns 1.0.

    2 Complexity: Constant if n is not provided, otherwise linear in n to construct the buckets.

    template <class InputIterator>
    unordered_multimap(InputIterator f, InputIterator l,
                       size_type n = see below,
                       const hasher& hf = hasher(),
                       const key_equal& eql = key_equal(),
                       const allocator_type& a = allocator_type());
    

    3 Effects: Constructs an empty unordered_multimap using the specified hash function, key equality function, and allocator, and using at least n buckets. If n is not provided, the number of buckets is implementation-definedimpldefdefault number of buckets in unordered_multimap. Then inserts elements from the range [f, l). max_load_factor() returns 1.0.

    4 Complexity: Average case linear, worst case quadraticConstant if n is not provided, else linear in n to construct the buckets. In the average case linear in N and in the worst case quadratic in N to insert the elements, where N is equal to distance(f, l).

  4. Modify 23.5.6.2 [unord.set.cnstr] p. 1-4 as indicated (The edits of p. 1 and p. 3 attempt to fix some editorial oversight.):

    explicit unordered_set(size_type n = see below,
                           const hasher& hf = hasher(),
                           const key_equal& eql = key_equal(),
                           const allocator_type& a = allocator_type());
    

    1 Effects: Constructs an empty unordered_set using the specified hash function, key equality function, and allocator, and using at least n buckets. If n is not provided, the number of buckets is implementation-definedimpldefdefault number of buckets in unordered_set. max_load_factor() returns 1.0.

    2 Complexity: Constant if n is not provided, otherwise linear in n to construct the buckets.

    template <class InputIterator>
    unordered_set(InputIterator f, InputIterator l,
                  size_type n = see below,
                  const hasher& hf = hasher(),
                  const key_equal& eql = key_equal(),
                  const allocator_type& a = allocator_type());
    

    3 Effects: Constructs an empty unordered_set using the specified hash function, key equality function, and allocator, and using at least n buckets. If n is not provided, the number of buckets is implementation-definedimpldefdefault number of buckets in unordered_set. Then inserts elements from the range [f, l). max_load_factor() returns 1.0.

    4 Complexity: Average case linear, worst case quadraticConstant if n is not provided, else linear in n to construct the buckets. In the average case linear in N and in the worst case quadratic in N to insert the elements, where N is equal to distance(f, l).

  5. Modify 23.5.7.2 [unord.multiset.cnstr] p. 1-4 as indicated (The edits of p. 1 and p. 3 attempt to fix some editorial oversight.):

    explicit unordered_multiset(size_type n = see below,
                                const hasher& hf = hasher(),
                                const key_equal& eql = key_equal(),
                                const allocator_type& a = allocator_type());
    

    1 Effects: Constructs an empty unordered_multiset using the specified hash function, key equality function, and allocator, and using at least n buckets. If n is not provided, the number of buckets is implementation-definedimpldefdefault number of buckets in unordered_multiset. max_load_factor() returns 1.0.

    2 Complexity: Constant if n is not provided, otherwise linear in n to construct the buckets.

    template <class InputIterator>
    unordered_multiset(InputIterator f, InputIterator l,
                       size_type n = see below,
                       const hasher& hf = hasher(),
                       const key_equal& eql = key_equal(),
                       const allocator_type& a = allocator_type());
    

    3 Effects: Constructs an empty unordered_multiset using the specified hash function, key equality function, and allocator, and using at least n buckets. If n is not provided, the number of buckets is implementation-definedimpldefdefault number of buckets in unordered_multiset. Then inserts elements from the range [f, l). max_load_factor() returns 1.0.

    4 Complexity: Average case linear, worst case quadraticConstant if n is not provided, else linear in n to construct the buckets. In the average case linear in N and in the worst case quadratic in N to insert the elements, where N is equal to distance(f, l).


1213. Meaning of valid and singular iterator underspecified

Section: 24.2 [iterator.requirements] Status: Deferred Submitter: Daniel Krügler Opened: 2009-09-19 Last modified: 2011-02-21

View all other issues in [iterator.requirements].

View all issues with Deferred status.

Discussion:

The terms valid iterator and singular aren't properly defined. The fuzziness of those terms became even worse after the resolution of 208 (including further updates by 278). In 24.2 [iterator.requirements] as of N2723 the standard says now:

5 - These values are called past-the-end values. Values of an iterator i for which the expression *i is defined are called dereferenceable. The library never assumes that past-the-end values are dereferenceable. Iterators can also have singular values that are not associated with any container. [...] Results of most expressions are undefined for singular values; the only exceptions are destroying an iterator that holds a singular value and the assignment of a non-singular value to an iterator that holds a singular value. [...] Dereferenceable values are always non-singular.

10 - An invalid iterator is an iterator that may be singular.

First, issue 208 intentionally removed the earlier constraint that past-the-end values are always non-singular. The reason for this was to support null pointers as past-the-end iterators of e.g. empty sequences. But there seem to exist different views on what a singular (iterator) value is. E.g. according to the SGI definition a null pointer is not a singular value:

Dereferenceable iterators are always nonsingular, but the converse is not true. For example, a null pointer is nonsingular (there are well defined operations involving null pointers) even thought it is not dereferenceable.

and proceeds:

An iterator is valid if it is dereferenceable or past-the-end.

Even if the standard prefers a different meaning of singular here, the change was incomplete, because by restricting feasible expressions of singular iterators to destruction and assignment isn't sufficient for a past-the-end iterator: Of-course it must still be equality-comparable and in general be a readable value.

Second, the standard doesn't clearly say whether a past-the-end value is a valid iterator or not. E.g. 20.6.12 [specialized.algorithms]/1 says:

In all of the following algorithms, the formal template parameter ForwardIterator is required to satisfy the requirements of a forward iterator (24.1.3) [..], and is required to have the property that no exceptions are thrown from [..], or dereference of valid iterators.

The standard should make better clear what "singular pointer" and "valid iterator" means. The fact that the meaning of a valid value has a core language meaning doesn't imply that for an iterator concept the term "valid iterator" has the same meaning.

Let me add a final example: In X [allocator.concepts.members] of N2914 we find:

pointer X::allocate(size_type n);

11 Returns: a pointer to the allocated memory. [Note: if n == 0, the return value is unspecified. —end note]

[..]

void X::deallocate(pointer p, size_type n);

Preconditions: p shall be a non-singular pointer value obtained from a call to allocate() on this allocator or one that compares equal to it.

If singular pointer value would include null pointers this make the preconditions unclear if the pointer value is a result of allocate(0): Since the return value is unspecified, it could be a null pointer. Does that mean that programmers need to check the pointer value for a null value before calling deallocate?

[ 2010-11-09 Daniel comments: ]

A later paper is in preparation.

[ 2010 Batavia: ]

Doesn't need to be resolved for Ox

Proposed resolution:

Consider to await the paper.


1214. Insufficient/inconsistent key immutability requirements for associative containers

Section: 23.2.4 [associative.reqmts] Status: Deferred Submitter: Daniel Krügler Opened: 2009-09-20 Last modified: 2011-02-21

View other active issues in [associative.reqmts].

View all other issues in [associative.reqmts].

View all issues with Deferred status.

Discussion:

Scott Meyers' mentions on a recent posting on c.s.c++ some arguments that point to an incomplete resolution of 103 and to an inconsistency of requirements on keys in ordered and unordered associative containers:

1) 103 introduced the term immutable without defining it in a unique manner in 23.2.4 [associative.reqmts]/5:

[..] Keys in an associative container are immutable.

According to conventional dictionaries immutable is an unconditional way of saying that something cannot be changed. So without any further explicit allowance a user always runs into undefined behavior if (s)he attempts to modify such a key. IMO this was not the intend of the committee to resolve 103 in that way because the comments suggest an interpretation that should give any user the freedom to modify the key in an explicit way provided it would not affect the sort order in that container.

2) Another observation was that surprisingly no similar 'safety guards' exists against unintentional key changes for the unordered associative containers, specifically there is no such requirement as in 23.2.4 [associative.reqmts]/6 that "both iterator and const_iterator are constant iterators". But the need for such protection against unintentional changes as well as the constraints in which manner any explicit changes may be performed are both missing and necessary, because such changes could potentially change the equivalence of keys that is measured by the hasher and key_equal.

I suggest to fix the unconditional wording involved with "immutable keys" by at least adding a hint for the reader that users may perform such changes in an explicit manner and to perform similar wording changes as 103 did for the ordered associative containers also for the unordered containers.

[ 2010-03-27 Daniel provides wording. ]

This update attempts to provide normative wording that harmonizes the key and function object constraints of associative and unordered containers.

[ 2010 Batavia: ]

We're uncomfortable with the first agenda item, and we can live with the second agenda item being applied before or after Madrid.

Proposed resolution:

  1. Change 23.2.4 [associative.reqmts]/2 as indicated: [This ensures that associative containers make better clear what this "arbitrary" type is, as the unordered containers do in 23.2.5 [unord.req]/3]

    2 Each associative container is parameterized on Key and an ordering relation Compare that induces a strict weak ordering (25.4) on elements of Key. In addition, map and multimap associate an arbitrary mapped typetype T with the Key. The object of type Compare is called the comparison object of a container.

  2. Change 23.2.4 [associative.reqmts]/5 as indicated: [This removes the too strong requirement that keys must not be changed at all and brings this line in sync with 23.2.5 [unord.req]/7. We take care about the real constraints by the remaining suggested changes. The rationale provided by LWG 103 didn't really argue why that addition is necessary, and I believe the remaining additions make it clear that any user changes have strong restrictions]:

    5 For set and multiset the value type is the same as the key type. For map and multimap it is equal to pair<const Key, T>. Keys in an associative container are immutable.

  3. Change 23.2.5 [unord.req]/3+4 as indicated: [The current sentence of p.4 has doesn't say something really new and this whole subclause misses to define the concepts of the container-specific hasher object and predicate object. We introduce the term key equality predicate which is already used in the requirements table. This change does not really correct part of this issue, but is recommended to better clarify the nomenclature and the difference between the function objects and the function object types, which is important, because both can potentially be stateful.]

    3 Each unordered associative container is parameterized by Key, by a function object type Hash that meets the Hash requirements (20.2.4) and acts as a hash function for argument values of type Key, and by a binary predicate Pred that induces an equivalence relation on values of type Key. Additionally, unordered_map and unordered_multimap associate an arbitrary mapped type T with the Key.

    4 The container's object of type Hash - denoted by hash - is called the hash function of the container. The container's object of type Pred - denoted by pred - is called the key equality predicate of the container.A hash function is a function object that takes a single argument of type Key and returns a value of type std::size_t.

  4. Change 23.2.5 [unord.req]/5 as indicated: [This adds a similar safe-guard as the last sentence of 23.2.4 [associative.reqmts]/3]

    5 Two values k1 and k2 of type Key are considered equivalent if the container's key equality predicatekey_equal function object returns true when passed those values. If k1 and k2 are equivalent, the container's hash function shall return the same value for both. [Note: thus, when an unordered associative container is instantiated with a non-default Pred parameter it usually needs a non-default Hash parameter as well. — end note] For any two keys k1 and k2 in the same container, calling pred(k1, k2) shall always return the same value. For any key k in a container, calling hash(k) shall always return the same value.

  5. After 23.2.5 [unord.req]/7 add the following new paragraph: [This ensures the same level of compile-time protection that we already require for associative containers. It is necessary for similar reasons, because any change in the stored key which would change it's equality relation to others or would change it's hash value such that it would no longer fall in the same bucket, would break the container invariants]

    7 For unordered_set and unordered_multiset the value type is the same as the key type. For unordered_map and unordered_multimap it is std::pair<const Key, T>.

    For unordered containers where the value type is the same as the key type, both iterator and const_iterator are constant iterators. It is unspecified whether or not iterator and const_iterator are the same type. [Note: iterator 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]


1252. wbuffer_convert::state_type inconsistency

Section: 22.3.3.2.3 [conversions.buffer] Status: Open Submitter: Bo Persson Opened: 2009-10-21 Last modified: 2011-02-21

View all issues with Open status.

Discussion:

The synopisis for wbuffer_convert 22.3.3.2.3 [conversions.buffer]/2 contains

typedef typename Tr::state_type   state_type; 

making state_type a synonym for (possibly) some char_traits<x>::state_type.

However, in paragraph 9 of the same section, we have

typedef typename Codecvt::state_type state_type;

The type shall be a synonym for Codecvt::state_type.

From what I can see, it might be hard to implement wbuffer_convert if the types were not both std::mbstate_t, but I cannot find a requirement that they must be the same type.

[ Batavia 2010: ]

Howard to draft wording, move to Review. Run it by Bill. Need to move this in Madrid.

Proposed resolution:


1297. unique_ptr's relational operator functions should induce a total order

Section: 20.7.1.4 [unique.ptr.special] Status: Open Submitter: Daniel Krügler Opened: 2009-12-23 Last modified: 2011-02-21

View all issues with Open status.

Discussion:

The comparison functions of unique_ptr currently directly delegate to the underlying comparison functions of unique_ptr<T, D>::pointer. This is disadvantageous, because this would not guarantee to induce a total ordering for native pointers and it is hard to define a total order for mixed types anyway.

The currently suggested resolution for shared_ptr comparison as of 1262 uses a normalization strategy: They perform the comparison on the composite pointer type (5.9 [expr.rel]). This is not exactly possible for unique_ptr in the presence of user-defined pointer-like types but the existing definition of std::duration comparison as of 20.11.5.6 [time.duration.comparisons] via common_type of both argument types demonstrates a solution of this problem. The approach can be seen as the general way to define a composite pointer type and this is the approach which is used for here suggested wording change.

For consistency reasons I would have preferred the same normalization strategy for == and !=, but Howard convinced me not to do so (now).

[ 2010-11-03 Daniel comments and adjustes the currently proposed wording changes: ]

Issue 1401 is remotely related. Bullet A of its proposed resolution provides an alternative solution for issue discussed here and addresses NB comment GB-99. Additionally I updated the below suggested wording in regard to the following: It is an unncessary requirement that the below defined effective composite pointer-like type CT satisfies the LessThanComparable requirements. All what is needed is, that the function object type less<CT> induces a strict weak ordering on the pointer values.

Proposed resolution:

Change 20.7.1.4 [unique.ptr.special]/4-7 as indicated: [The implicit requirements and remarks imposed on the last three operators are the same as for the first one due to the normative "equivalent to" usage within a Requires element, see 17.5.1.4 [structure.specifications]/4. The effects of this change are that all real pointers wrapped in a unique_ptr will order like shared_ptr does.]

template <class T1, class D1, class T2, class D2>
  bool operator<(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);

? Requires: Let CT be common_type<unique_ptr<T1, D1>::pointer, unique_ptr<T2, D2>::pointer>::type. Then the specialization less<CT> shall be a function object type ([function.objects]) that induces a strict weak ordering ([alg.sorting]) on the pointer values.

4 Returns: less<CT>()(x.get(), y.get())x.get() < y.get().

? Remarks: If unique_ptr<T1, D1>::pointer is not implicitly convertible to CT or unique_ptr<T2, D2>::pointer is not implicitly convertible to CT, the program is ill-formed.

template <class T1, class D1, class T2, class D2>
  bool operator<=(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);

5 Effects: Equivalent to return !(y < x) Returns: x.get() <= y.get().

template <class T1, class D1, class T2, class D2>
  bool operator>(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);

6 Effects: Equivalent to return (y < x) Returns: x.get() > y.get().

template <class T1, class D1, class T2, class D2>
  bool operator>=(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);

7 Effects: Equivalent to return !(x < y) Returns: x.get() >= y.get().


1318. N2982 removes previous allocator capabilities

Section: 20.6.8.1 [allocator.traits.types] Status: Open Submitter: Pete Becker Opened: 2010-02-11 Last modified: 2011-02-28

View all issues with Open status.

Duplicate of: 1375

Discussion:

Addresses US-87

N2982 says that containers should have a nested typedef that defines their reference_type as value_type&; the previous standard deferred to the allocator to define its reference_type, and containers simply passed the allocator's typedef on. This change is a mistake. Allocators should define both a pointer type and a reference type. That's essential for their original purpose, which was to make different memory models transparent. If an allocator defines a pointer type that isn't compatible with a normal pointer it also has to define a corresponding reference type. For example (and please forgive a Windows-ism), if an allocator's pointer is T __far*, then it's reference has to be T __far&. Otherwise everything crashes (under the hood, references are pointers and have to have the same memory access mechanics). Extensions such as this for more general memory models were explicitly encouraged by C++03, and the allocator's pointer and reference typedefs were the hooks for such extensions. Removing the allocator's reference and const_reference typedefs makes those extensions unimplementable and breaks existing implementations that rely on those hooks.

[ 2010-02-25 Alisdair adds: ]

vector<bool>::reference is a nested class, and not a typedef. It should be removed from the list of containers when this change is made.

In general, I am uncomfortable placing this reference requirement on each container, as I would prefer to require:

is_same<Container::reference, Container::iterator::reference>

This distinction is important, if we intend to support proxy iterators. The iterator paper in the pre-Pittsburgh mailing (N3046) does not make this proposal, but organises clause 24 in such a way this will be much easier to specify.

The changes to clause 20 remain important for all the reasons Pete highlights.

[ 2010 Batavia ]

Removed vector from list of templates that should be adjusted as of meeting outcome.

[ 2010 post-Batavia ]

Replaced vector<bool> reference by vector reference because of misinterpreting meeting typo. Additional corrected numbering in P/R to N3225 wording.

[ 2010-12-06 Daniel reopens ]

Unfortunately, the current P/R is defective for several reasons:

  1. Table 43 — Descriptive variable definitions still contains three references to T&, namely in:
    t a value of type const T&
    r a value of type T& obtained by the expression *p
    s a value of type const T& obtained by the expression *q or by conversion from a value r
    Especially the second and third items are misses in the 1318 P/R, e.g. in N2723 or in C++03 these were referring to X::reference and X::const_reference, resp. None of them is referenced anywhere in the allocator requirements table: r and s where historically needed to define the expressions a.address(r) and a.address(s) which are gone now, and t was needed to define the expression a.construct(p, t) which has been replaced by a.construct(p,args).

    The easiest fix seems to be to remove all three rows from Table 43.

  2. Further-on, the current P/R suggests to replace the the current definitions of the adaptor classes
    stack
    priority_queue
    queue
    
    similar to the other container types, i.e. to define reference and const_reference now as
    typedef typename allocator_traits<Allocator>::reference reference;
    typedef typename allocator_traits<Allocator>::const_reference const_reference;
    
    This would not only be an ill-formed definition (because there is no name Allocator in scope), but it would also introduce a breakage compared to C++03, where these definitions where already referring to the definition of the wrapped containers. So, the adaptor class templates should be removed from the current list.
  3. Then the current P/R wording leads to one further unexpected and unwanted change due to the general formular used: match_result::reference is currently defined as
    typedef const_reference reference;
    
    because it is an immutable container (And we had this definition already in N2723). The application of the rule would change this silently.
  4. Finally the suggested wording for the unordered_ containers is incomplete. The reason is a current inconsistency between these containers and the rest: While normally the definition of the pointer types is
    typedef typename allocator_traits<Allocator>::pointer pointer;
    typedef typename allocator_traits<Allocator>::const_pointer const_pointer;
    
    for the unordered containers they are
    typedef typename allocator_type::pointer pointer;
    typedef typename allocator_type::const_pointer const_pointer;
    
    These definitions are not equivalent, because allocators are no longer required to define typedefs pointer and const_pointer, the allocator_traits were invented as a further indirection to cope with that. I.e. for the unordered containers we need to bring both the definition of references and pointers in sync.

[ 2011-02-23 Daniel updates the proposed wording with support from Pablo ]

The update attempts to fix the backward-compatibility problem that we have introduced by ignoring the C++03 member function overloads address of allocator types in C++0x completely. The resolution attempts to fix that by adding these functions as optional members of allocators that are considered first before falling back to pointer_traits::pointer_to. This still allows us to remove the unused symbol t from the table, but we adapt the symbols r and s to purely refer to the typenames reference and const_reference.

Proposed resolution:

  1. Edit the following three rows from Table 43:

    Table 43 — Descriptive variable definitions
    Variable Definition
    t a value of type const T&
     ...  ...
    r a value of type T&XX::reference obtained by the expression *p.
    s a value of type const T&XX::const_reference obtained by the expression *q or by conversion from a value r.
  2. Add the following rows to Table 44, Allocator requirements:

    Table 44 — Allocator requirements
    Expression Return type Assertion/note
    pre-/post-condition
    Default
     ...  ...  ...  ...
    X::reference T&
    X::const_reference X::reference is convertible to
    X::const_reference
    const T&
    X::value_type Identical to T    
  3. Change the following two rows in Table 44:

    Table 44 — Allocator requirements
    Expression Return type Assertion/note
    pre-/post-condition
    Default
    *p T&X::reference
    *q const T&X::const_reference *q refers to the same object as *p
     ...  ...  ...  ...
    static_cast<X::pointer>(w) X::pointer static_cast<X::pointer>(w)
    == p
     
    static_cast<X::const_pointer>(z) X::const_pointer static_cast<X::const_pointer>(z)
    == q
     
    a.address(r) X::pointer a.address(r) == p pointer_traits<X::pointer>::pointer_to(r)
    a.address(s) X::const_pointer a.address(s) == q pointer_traits<X::const_pointer>::pointer_to(s)
  4. Add the following typedef declarations to allocator_traits 20.6.8 [allocator.traits]:

    template <class Alloc> struct allocator_traits {
      ...
      typedef see below void_pointer;
      typedef see below const_void_pointer;
    
      typedef see below reference;
      typedef see below const_reference;
      ...
      static pointer address(Alloc& a, reference r) noexcept;
      static const_pointer address(Alloc& a, const_reference r) noexcept;
    
      static pointer allocate(Alloc& a, size_type n);
      static pointer allocate(Alloc& a, size_type n, const_void_pointer hint);
      ...
    
  5. Add the following descriptions to 20.6.8.1 [allocator.traits.types] after p. 4:

    typedef see below const_void_pointer;

    4 Type: Alloc::const_void_pointer if such a type exists; otherwise, pointer_traits<pointer>::rebind<const void>.

    typedef see below reference;

    ? Type: Alloc::reference if such a type exists; otherwise, value_type&.

    typedef see below const reference;

    ? Type: Alloc::const_reference if such a type exists; otherwise, const value_type&.

  6. Add the following descriptions at the beginning of 20.6.8.2 [allocator.traits.members]:

    static pointer address(Alloc& a, reference r) noexcept;

    ? Returns: a.address(r) if that expression is well-formed; otherwise, pointer_traits<pointer>::pointer_to(r).

    static const_pointer address(Alloc& a, const_reference r) noexcept;

    ? Returns: a.address(r) if that expression is well-formed; otherwise, pointer_traits<const_pointer>::pointer_to(r).

    static pointer allocate(Alloc& a, size_type n);

    1 Returns: a.allocate(n).

  7. Add the following typdef and member function declarations to scoped_allocator_adaptor 20.12 [allocator.adaptor]:

    template <class OuterAlloc, class... InnerAllocs>
    class scoped_allocator_adaptor : public OuterAlloc {
      ...
      typedef typename OuterTraits::reference reference;
      typedef typename OuterTraits::const_reference const_reference;
      ...
      pointer address(reference r) noexcept;
      const_pointer address(const_reference r) noexcept;
    
      pointer allocate(size_type n);
      ...
    
  8. Add the following prototype descriptions to 20.12.4 [allocator.adaptor.members]:

    const outer_allocator_type& outer_allocator() const noexcept;

    4 Returns: static_cast<const Outer&>(*this).

    pointer address(reference r) noexcept;

    ? Returns: allocator_traits<OuterAlloc>::address(outer_allocator(), r).

    const_pointer address(const_reference r) noexcept;

    ? Returns: allocator_traits<OuterAlloc>::address(outer_allocator(), r).

    pointer allocate(size_type n);

    5 Returns: allocator_traits<OuterAlloc>::allocate(outer_allocator(), n).

  9. Change the nested typedefs reference and const_reference to:

    typedef typename allocator_traits<Allocator>::reference reference;
    typedef typename allocator_traits<Allocator>::const_reference const_reference;
    

    for each of the following class templates:

    basic_string 21.4 [basic.string]
    deque 23.3.3 [deque]
    forward_list 23.3.4 [forwardlist]
    list 23.3.5 [list]
    vector 23.3.6 [vector]
    map 23.4.4 [map]
    multimap 23.4.5 [multimap]
    set 23.4.6 [set]
    multiset 23.4.7 [multiset]

  10. Change the nested typedefs reference and const_reference to:

    typedef typename allocator_traits<Allocator>::reference reference;
    typedef typename allocator_traits<Allocator>::const_reference const_reference;
    

    and change the nested typedefs pointer and const_pointer to:

    typedef typename allocator_traits<Allocator>::pointer pointer;
    typedef typename allocator_traits<Allocator>::const_pointer const_pointer;
    

    for each of the following class templates:

    unordered_map 23.5.4 [unord.map]
    unordered_multimap 23.5.5 [unord.multimap]
    unordered_set 23.5.6 [unord.set]
    unordered_multiset 23.5.7 [unord.multiset]

  11. Edit the class template synopsis of match_results in 28.10 [re.results] as indicated:

    template <class BidirectionalIterator,
    class Allocator = allocator<sub_match<BidirectionalIterator> >
    class match_results {
    public:
      typedef sub_match<BidirectionalIterator> value_type;
      typedef const value_type&typename allocator_traits<Allocator>::const_reference const_reference;
      typedef const_reference reference;
      ...
    };
    

1330. Move container requirements into requirements tables

Section: 23.2 [container.requirements] Status: Deferred Submitter: Nicolai Josuttis Opened: 2010-03-10 Last modified: 2010-11-15

View all other issues in [container.requirements].

View all issues with Deferred status.

Discussion:

Abstract:

In general, it seems that in a couple of places container behavior is not described in requirement tables although it is a general behavior.

History:

Issue 676 added move semantics to unordered containers. For the added insert functions the Editor requested to put their semantic description into a requirements table rather than describing them for each container individually. The text however was taken from the associative containers, where we also have the semantics for each container described. Also, 1034 is to some extend requesting a clarification of the requirement tables and it turned out that in other places we have the same problem (e.g. we have no general requirement for type pointer and const_pointer although each container has them with issue 1306).

From my personal list of functions in requirement tables and containers, the following types/functions are missing in requirement tables:

As a special case, we lack the following requirements for all sequence containers BUT array (so special wording or a new container category is required):

Note that we also might have to add additional requirements on other places for sequence containers because having an allocator requires additional statements for the treatment of the allocators. E.g. swap for containers with allocators is not specified in any requirement table.

And finally, if we have the requirements in the requirements tables, we can remove the corresponding descriptions for the individual container. However, note that sequence container requirements have NO complexity column, so that we still need container specific descriptions for the functions listed there.

[ 2010 Batavia ]

While there is consensus that further cleaning up the container requirement tables would be a good thing, there is no feeling that this must be done in time for 0x. The issue remains open, but Deferred.

Proposed resolution:


1345. [FCD] Library classes should have noexcept move operations

Section: 17 [library] Status: Open Submitter: BSI Opened: 2010-08-25 Last modified: 2011-02-21

View other active issues in [library].

View all other issues in [library].

View all issues with Open status.

Discussion:

Addresses GB-61

All library types should have non-throwing move constructors and move-assignment operators unless wrapping a type with a potentially throwing move operation. When such a type is a class-template, these operations should have a conditional noexcept specification.

There are many other places where a noexcept specification may be considered, but the move operations are a special case that must be called out, to effectively support the move_if_noexcept function template.

[ Resolution proposed by ballot comment: ]

Review every class and class template in the library. If noexcept move constructor/assignment operators can be implicitly declared, then they should be implicitly declared, or explicitly defaulted. Otherwise, a move constructor/move assignment operator with a noexcept exception specification should be provided.

[ 2010-10-31 Daniel comments: ]

The proposed resolution of n3157 would satisfy this request.

Proposed resolution:

See n3157


1348. [FCD] Exception safety of unspecified types

Section: 17 [library] Status: Open Submitter: BSI Opened: 2010-08-25 Last modified: 2010-10-25

View other active issues in [library].

View all other issues in [library].

View all issues with Open status.

Discussion:

Addresses GB-64

There are a number of unspecified types used throughout the library, such as the container iterators. Many of these unspecified types have restrictions or expectations on their behaviour in terms of exceptions. Are they permitted or required to use exception specifications, more specifically the new noexcept specification? For example, if vector<T>::iterator is implemented as a native pointer, all its operations will have an (effective) noexcept specification. If the implementation uses a class type to implement this iterator, is it permitted or required to support that same guarantee?

[ Resolution proposed by ballot comment ]

Clearly state the requirements for exception specifications on all unspecified library types. For example, all container iterator operations should be conditionally noexcept, with the condition matching the same operation applied to the allocator's pointer_type, a certain subset of which are already required not to throw.

Proposed resolution:


1349. [FCD] swap should not throw

Section: 17 [library] Status: Open Submitter: BSI Opened: 2010-08-25 Last modified: 2010-10-25

View other active issues in [library].

View all other issues in [library].

View all issues with Open status.

Discussion:

Addresses GB-65

Nothrowing swap operations are key to many C++ idioms, notably the common copy/swap idiom to provide the strong exception safety guarantee.

[ Resolution proposed by ballot comment ]

Where possible, all library types should provide a swap operation with an exception specification guaranteeing no exception shall propagate. Where noexcept(true) cannot be guaranteed to not terminate the program, and the swap in questions is a template, an exception specification with the appropriate conditional expression could be specified.

Proposed resolution:


1353. [FCD] Clarify the state of a moved-from object

Section: 17 [library] Status: Open Submitter: Switzerland Opened: 2010-08-25 Last modified: 2011-02-28

View other active issues in [library].

View all other issues in [library].

View all issues with Open status.

Discussion:

Addresses CH-18

The general approach on moving is that a library object after moving out is in a "valid but unspecified state". But this is stated at the single object specifications, which is error prone (especially if the move operations are implicit) and unnecessary duplication.

[ Resolution propsed by ballot comment ]

Consider putting a general statement to the same effect into clause 17.

[2010-11-05 Beman provides exact wording. The wording was inspired by Dave Abrahams' message c++std-lib-28958, and refined with help from Alisdair, Daniel, and Howard. ]

[2011-02-25 P/R wording superseded by N3241. ]

Proposed resolution:

Resolved by N3241


1358. [FCD] Add <chrono> and <ratio> to freestanding implementations

Section: 17.6.1.3 [compliance] Status: Open Submitter: BSI Opened: 2010-08-25 Last modified: 2011-02-28

View all other issues in [compliance].

View all issues with Open status.

Discussion:

Addresses GB-55

The <thread> header uses duration types, found in the <chrono> header, and which rely on the ratio types declared in the <ratio> header.

[ Extracts from lengthy Rapperswil discussion: ]

There is a concern that this issue is a misunderstanding of the actual requirements of a free-standing implementation to support the <thread> header. In general, a free-standanding implementation will provide an empty header, specifically so that a user can test for the absence of the _ _ STDCPP_THREADS _ _ macro. This idiom as used as there is no portable way to test for the lack of a header.

At this point, it was suggested the NB comment is trying to solve the wrong problem, and that _ _ STDCPP_THREADS _ _ should be a pre-defined macro in clause 16 that can be tested before including <thread>. That would remove the need to add additional headers to the free-standanding requirements.

It is worth noting that Japan requested <ratio> as a free-standing header in their CD1 comments. No-one seemed keen to require clocks of a free-standing implementation though.

Detlef volunteers to look at a way to redraft 17.6.1.3 p3.

[ Original resolution proposed by NB comment: ]

Add the <chrono> and <ratio> headers to the freestanding requirements.

It might be necessary to address scaled-down expectations of clock support in a freestanding environment, much like <thread>.

[2011-02-25: Alberto drafts wording]

Proposed resolution:

  1. Add a new entry in Table 14 — C++ library headers:

    Table 14 — C++ library headers
    <iterator>
    <library_support>
    <limits>
  2. Remove the last row 30.3 [thread.threads] <threads> from Table 16 — C++ headers for freestanding implementations and insert a new one instead (To the editor: For the actual target Clause please see the comment in bullet 5 of this proposed resolution):

    Table 16 — C++ headers for freestanding implementations
    Subclause Header(s)
    30.3 [thread.threads] Threads <thread>
    ?? Library support <library_support>
  3. Modify paragraph 17.6.1.3 [compliance] p. 3:

    3 The supplied version of the header <cstdlib> shall declare at least the functions abort, atexit, at_quick_exit, exit, and quick_exit (18.5). The supplied version of the header <thread> shall meet the same requirements as for a hosted implementation or including it shall have no effect. The other headers listed in this table shall meet the same requirements as for a hosted implementation. A program can detect the presence of standard headers not listed in Table 16 using the facilities provided by the <library_support> header.

  4. Remove the following line from the header <thread> synopsis in 30.3 [thread.threads] p. 1:

    namespace std {
      #define __STDCPP_THREADS__ __cplusplus
    
      class thread;
      [...]
    }
    
  5. Add a new section in Clause 18 or 20 (or any other suitable place at the editor's discretion):

    ?? Library support [library.support]

    The header <library_support> defines an implementation-defined set of macros to allow a program detect the presence of standard headers in freestanding implementations. [Note: Hosted implementations shall provide all standard headers, thus shall provide all macros. — end note]

    For each standard header listed in Tables 14 (C++ library headers) and 15 (C++ headers for C library facilities) that is provided by the implementation, <library_support> shall define a macro with name _ _HAS_XXX_HEADER_ _ where XXX is replaced by the uppercase version of the name of the header. Each such macro shall expand to the value _ _cplusplus. [Example:

    #include <library_support>
    
    #ifdef _ _HAS_THREADS_HEADER_ _
      #include <threads>
      // code that exploit the presence of threads
    #else
      // fallback code that doesn't rely on threads
    #endif
    

    end example]

    No other standard header shall define macros with a name beginning with _ _HAS_ and ending with _HEADER_ _.


1364. [FCD] It is not clear how exception_ptr is synchronized

Section: 18.8.5 [propagation] Status: Open Submitter: Switzerland Opened: 2010-08-25 Last modified: 2010-10-24

View other active issues in [propagation].

View all other issues in [propagation].

View all issues with Open status.

Discussion:

Addresses CH-19

It is not clear how exception_ptr is synchronized.

[ Resolution proposed by ballot comment ]

Make clear that accessing in different threads multiple exception_ptr objects that all refer to the same exception introduce a race.

Proposed resolution:


1369. [FCD] rethrow_exception may introduce data races

Section: 18.8.5 [propagation] Status: Open Submitter: BSI Opened: 2010-08-25 Last modified: 2011-02-21

View other active issues in [propagation].

View all other issues in [propagation].

View all issues with Open status.

Discussion:

Addresses GB-74

One idea for the exception_ptr type was that a reference-counted implementation could simply 'reactivate' the same exception object in the context of a call to rethrow_exception. Such an implementation would allow the same exception object to be active in multiple threads (such as when multiple threads join on a shared_future) and introduce potential data races in any exception handler that catches exceptions by reference - notably existing library code written before this capability was added. rethrow_exception should always make a copy of the target exception object.

Proposed resolution:

Add the following to 18.8.5, [propogation]

Throws: a copy of the exception object to which p refers.


1374. [FCD] Clarify moved-from objects are "toxic"

Section: 17.6.3.1 [utility.arg.requirements] Status: Open Submitter: INCITS Opened: 2010-08-25 Last modified: 2011-02-28

View all other issues in [utility.arg.requirements].

View all issues with Open status.

Discussion:

Addresses US-85

20.2.1 Table 34 "MoveConstructible requirements" says "Note: rv remains a valid object. Its state is unspecified". Some components give stronger guarantees. For example, moved-from shared_ptrs are guaranteed empty (20.9.11.2.1/25). In general, what the standard really should say (preferably as a global blanket statement) is that moved-from objects can be destroyed and can be the destination of an assignment. Anything else is radioactive. For example, containers can be "emptier than empty". This needs to be explicit and required generally.

Note: The last time that one of us mentioned "emptier than empty" (i.e. containers missing sentinel nodes, etc.) the objection was that containers can store sentinel nodes inside themselves in order to avoid dynamically allocating them. This is unacceptable because

(a) it forces existing implementations (i.e. Dinkumware's, Microsoft's, IBM's, etc.) to change for no good reason (i.e. permitting more operations on moved-from objects), and

(b) it invalidates end-iterators when swapping containers. (The Working Paper currently permits end-iterator invalidation, which we consider to be wrong, but that's a separate argument. In any event, mandating end-iterator invalidation is very different from permitting it.)

[ Resolution proposed in ballot comment ]

State as a general requirement that moved-from objects can be destroyed and can be the destination of an assignment. Any other use is undefined behavior.

Proposed resolution:

Resolved by N3241


1396. [FCD] regex should support allocators

Section: 28.8 [re.regex] Status: Open Submitter: INCITS Opened: 2010-08-25 Last modified: 2011-02-21

View other active issues in [re.regex].

View all other issues in [re.regex].

View all issues with Open status.

Duplicate of: 1451

Discussion:

Addresses US-104, US-141

std::basic_regex should have an allocator for all the reasons that a std::string does. For example, I can use boost::interprocess to put a string or vector in shared memory, but not a regex.

[ Resolution proposed by ballot comment ]

Add allocators to regexes

[ 2010-10-24 Daniel adds: ]

Accepting n3171 would solve this issue.

Proposed resolution:

See n3171.


1421. [FCD] Accidental move-only library types due to new core language rules

Section: 23.6 [container.adaptors] Status: Open Submitter: DIN Opened: 2010-08-25 Last modified: 2011-02-21

View all other issues in [container.adaptors].

View all issues with Open status.

Duplicate of: 1350

Discussion:

Addresses DE-22, CH-15

With the final acceptance of move operations as special members and introduction of corresponding suppression rules of implicitly generated copy operations the some library types that were copyable in C++03 are no longer copyable (only movable) in C++03, among them queue, priority_queue, and stack.

[ 2010-10-26: Daniel comments: ]

Accepting n3112 should fix this.

[2011-02-17: Lawrence comments:]

The only open issue in CH 15 with respect to the concurrency group was the treatment of atomic_future. Since we removed atomic_future in Batavia, I think all that remains is to remove the open issue from N3112 and adopt it.

Proposed resolution:

See n3112


1448. [FCD] Concerns about basic_stringbuf::str(basic_string) postconditions

Section: 27.8.2.3 [stringbuf.members] Status: Open Submitter: BSI Opened: 2010-08-25 Last modified: 2011-02-21

View all issues with Open status.

Discussion:

Addresses GB-124

N3092 27.8.2.3 [stringbuf.members] contains this text specifying the postconditions of basic_stringbuf::str(basic_string):

Postconditions: If mode & ios_base::out is true, pbase() points to the first underlying character and epptr() >= pbase() + s.size() holds; in addition, if mode & ios_base::in is true, pptr() == pbase() + s.data() holds, otherwise pptr() == pbase() is true. [...]

Firstly, there's a simple mistake: It should be pbase() + s.length(), not pbase() + s.data().

Secondly, it doesn't match existing implementations. As far as I can tell, GCC 4.5 does not test for mode & ios_base::in in the second part of that sentence, but for mode & (ios_base::app | ios_base_ate), and Visual C++ 9 for mode & ios_base::app. Besides, the wording of the C++0x draft doesn't make any sense to me. I suggest changing the second part of the sentence to one of the following:

Replace ios_base::in with (ios_base::ate | ios_base::app), but this would require Visual C++ to change (replacing only with ios_base::ate would require GCC to change, and would make ios_base::app completely useless with stringstreams):

in addition, if mode & (ios_base::ate | ios_base::app) is true, pptr() == pbase() + s.length() holds, otherwise pptr() == pbase() is true.

Leave pptr() unspecified if mode & ios_base::app, but not mode & ios_base::ate (implementations already differ in this case, and it is always possible to use ios_base::ate to get the effect of appending, so it is not necessary to require any implementation to change):

in addition, if mode & ios_base::ate is true, pptr() == pbase() + s.length() holds, if neither mode & ios_base::ate nor mode & ios_base::app is true, pptr() == pbase() holds, otherwise pptr() >= pbase() && pptr() <= pbase() + s.length() (which of the values in this range is unspecified).

Slightly stricter:

in addition, if mode & ios_base::ate is true, pptr() == pbase() + s.length() holds, if neither mode & ios_base::ate nor mode & ios_base::app is true, pptr() == pbase() holds, otherwise pptr() == pbase() || pptr() == pbase() + s.length() (which of these two values is unspecified). A small table might help to better explain the three cases. BTW, at the end of the postconditions is this text: "egptr() == eback() + s.size() hold". Is there a perference for basic_string::length or basic_string::size? It doesn't really matter, but it looks a bit inconsistent.

Proposed resolution:


1450. [FCD] Contradiction in regex_constants

Section: 28.5.2 [re.matchflag] Status: Deferred Submitter: BSI Opened: 2010-08-25 Last modified: 2011-02-21

View all issues with Deferred status.

Discussion:

Addresses GB-127

The Bitmask Type requirements in 17.5.2.1.3 [bitmask.types] p.3 say that all elements on a bitmask type have distinct values, but 28.5.2 [re.matchflag] defines regex_constants::match_default and regex_constants::format_default as elements of the bitmask type regex_constants::match_flag_type, both with value 0. This is a contradiction.

[ Resolution proposed by ballot comment: ]

One of the bitmask elements should be removed from the declaration and should be defined separately, in the same manner as ios_base::adjustfield, ios_base::basefield and ios_base::floatfield are defined by 27.5.3.1.2 [ios::fmtflags] p.2 and Table 120. These are constants of a bitmask type, but are not distinct elements, they have more than one value set in the bitmask. regex_constants::format_default should be specified as a constant with the same value as regex_constants::match_default.

[ 2010-10-31 Daniel comments: ]

Strictly speaking, a bitmask type cannot have any element of value 0 at all, because any such value would contradict the requirement expressed in 17.5.2.1.3 [bitmask.types] p. 3:

for any pair Ci and Cj, Ci & Ci is nonzero

So, actually both regex_constants::match_default and regex_constants::format_default are only constants of the type regex_constants::match_flag_type, and no bitmask elements.

[ 2010-11-03 Daniel comments and provides a proposed resolution: ]

The proposed resolution is written against N3126 and considered as a further improvement of the fixes suggested by n3110.

Proposed resolution:

Add the following sentence to 28.5.2 [re.matchflag] paragraph 1:

1 The type regex_constants::match_flag_type is an implementation-defined bitmask type (17.5.2.1.3). Matching a regular expression against a sequence of characters [first,last) proceeds according to the rules of the grammar specified for the regular expression object, modified according to the effects listed in Table 136 for any bitmask elements set. Type regex_constants::match_flag_type also defines the constants regex_constants::match_default and regex_constants::format_default.


1452. [FCD] "target sequence" is not defined

Section: 28.10.4 [re.results.acc] Status: Open Submitter: BSI Opened: 2010-08-25 Last modified: 2011-02-21

View all other issues in [re.results.acc].

View all issues with Open status.

Discussion:

Addresses GB-125

The term "target sequence" is not defined (28.10.4 [re.results.acc] p. 2).

[ Resolution proposed by ballot comment: ]

Replace "target sequence" with "string being searched/matched"

[ 2010-11-01 Daniel comments: ]

The proposed resolution looks incomplete to me, there are more normative usages of the term target sequence in clause 28, e.g. 28.12.2 [re.tokiter] p. 7.

Proposed resolution:

Wording changes are against N3126. They are intended not to conflict with the wording changes suggested by n3158.

Change 28.10.4 [re.results.acc] p. 2 as indicated:

difference_type position(size_type sub = 0) const;

2 Returns: The distance from the start of the target sequencestring being matched to (*this)[sub].first.


1459. [FCD] Overlapping evaluations are allowed

Section: 29.3 [atomics.order] Status: Open Submitter: Canada Opened: 2010-08-25 Last modified: 2011-02-21

View other active issues in [atomics.order].

View all other issues in [atomics.order].

View all issues with Open status.

Duplicate of: 1458

Discussion:

Addresses CA-21, GB-131

29.4 [atomics.lockfree] p.8 states:

An atomic store shall only store a value that has been computed from constants and program input values by a finite sequence of program evaluations, such that each evaluation observes the values of variables as computed by the last prior assignment in the sequence.

... but 1.9 [intro.execution] p.13 states:

If A is not sequenced before B and B is not sequenced before A, then A and B are unsequenced. [ Note: The execution of unsequenced evaluations can overlap. — end note ]

Overlapping executions can make it impossible to construct the sequence described in 29.4 [atomics.lockfree] p.8. We are not sure of the intention here and do not offer a suggestion for change, but note that 29.4 [atomics.lockfree] p.8 is the condition that prevents out-of-thin-air reads.

For an example, suppose we have a function invocation f(e1,e2). The evaluations of e1 and e2 can overlap. Suppose that the evaluation of e1 writes y and reads x whereas the evaluation of e2 reads y and writes x, with reads-from edges as below (all this is within a single thread).

 e1           e2
Wrlx y--   --Wrlx x
      rf\ /rf
         X
        / \
Rrlx x<-   ->Rrlx y

This seems like it should be allowed, but there seems to be no way to produce a sequence of evaluations with the property above.

In more detail, here the two evaluations, e1 and e2, are being executed as the arguments of a function and are consequently not sequenced-before each other. In practice we'd expect that they could overlap (as allowed by 1.9 [intro.execution] p.13), with the two writes taking effect before the two reads. However, if we have to construct a linear order of evaluations, as in 29.4 [atomics.lockfree] p.8, then the execution above is not permited. Is that really intended?

[ Resolution proposed by ballot comment ]

Please clarify.

Proposed resolution:


1460. [FCD] Missing lock-free property for type bool should be added

Section: 29.4 [atomics.lockfree] Status: Open Submitter: INCITS Opened: 2010-08-25 Last modified: 2011-02-21

View all other issues in [atomics.lockfree].

View all issues with Open status.

Discussion:

Addresses US-154

There is no ATOMIC_BOOL_LOCK_FREE macro.

Proposed resolution:

Add ATOMIC_BOOL_LOCK_FREE to 29.4 [atomics.lockfree] and to 29.2 [atomics.syn]:

[..]
#define ATOMIC_BOOL_LOCK_FREE unspecified
#define ATOMIC_CHAR_LOCK_FREE unspecified
#define ATOMIC_CHAR16_T_LOCK_FREE unspecified
#define ATOMIC_CHAR32_T_LOCK_FREE unspecified
[..]

1461. [FCD] Rename all ATOMIC_* macros as STD_ATOMIC_*

Section: 29 [atomics] Status: Open Submitter: Canada Opened: 2010-08-25 Last modified: 2011-02-21

View other active issues in [atomics].

View all other issues in [atomics].

View all issues with Open status.

Discussion:

Addresses CA-1

All ATOMIC_... macros should be prefixed with STD_ as in STD_ATOMIC_... to indicate they are STD macros as other standard macros. The rationale that they all seem too long seems weak.

Proposed resolution:

  1. Change sub-clause 29.2 [atomics.syn] as indicated:

    [..]
    // 29.4, lock-free property
    #define STD_ATOMIC_CHAR_LOCK_FREE unspecified
    #define STD_ATOMIC_CHAR16_T_LOCK_FREE unspecified
    #define STD_ATOMIC_CHAR32_T_LOCK_FREE unspecified
    #define STD_ATOMIC_WCHAR_T_LOCK_FREE unspecified
    #define STD_ATOMIC_SHORT_LOCK_FREE unspecified
    #define STD_ATOMIC_INT_LOCK_FREE unspecified
    #define STD_ATOMIC_LONG_LOCK_FREE unspecified
    #define STD_ATOMIC_LLONG_LOCK_FREE unspecified
    #define STD_ATOMIC_ADDRESS_LOCK_FREE unspecified
    
    // 29.6, operations on atomic types
    #define STD_ATOMIC_VAR_INIT(value) see below
    [..]
    
  2. Change 29.4 [atomics.lockfree] p. 1 as indicated:

    #define STD_ATOMIC_CHAR_LOCK_FREE implementation-defined
    #define STD_ATOMIC_CHAR16_T_LOCK_FREE implementation-defined
    #define STD_ATOMIC_CHAR32_T_LOCK_FREE implementation-defined
    #define STD_ATOMIC_WCHAR_T_LOCK_FREE implementation-defined
    #define STD_ATOMIC_SHORT_LOCK_FREE implementation-defined
    #define STD_ATOMIC_INT_LOCK_FREE implementation-defined
    #define STD_ATOMIC_LONG_LOCK_FREE implementation-defined
    #define STD_ATOMIC_LLONG_LOCK_FREE implementation-defined
    #define STD_ATOMIC_ADDRESS_LOCK_FREE implementation-defined
    

    1 The STD_ATOMIC_..._LOCK_FREE macros indicate the lock-free property of the corresponding atomic types, [..]

  3. Change 29.6 [atomics.types.operations] p. 5 as indicated:

    #define STD_ATOMIC_VAR_INIT(value) see below
    

    5 Remarks: A macro that expands to a token sequence suitable for initializing an atomic variable of a type that is initializion-compatible with value. Concurrent access to the variable being initialized, even via an atomic operation, constitutes a data race. [ Example:

    atomic_int v = STD_ATOMIC_VAR_INIT(5);
    

    end example ]

  4. Change 29.7 [atomics.flag] p. 1+4 as indicated:

    namespace std {
      [..]
      #define STD_ATOMIC_FLAG_INIT see below
    }
    

    [..] 4 The macro STD_ATOMIC_FLAG_INIT shall be defined in such a way that it can be used to initialize an object of type atomic_flag to the clear state. For a static-duration object, that initialization shall be static. It is unspecified whether an unitialized atomic_flag object has an initial state of set or clear. [ Example:

    atomic_flag guard = STD_ATOMIC_FLAG_INIT;
    

    end example ]


1478. [FCD] Clarify race conditions in atomics initialization

Section: 29.6 [atomics.types.operations] Status: Open Submitter: BSI Opened: 2010-08-25 Last modified: 2011-02-28

View all other issues in [atomics.types.operations].

View all issues with Open status.

Discussion:

Addresses GB-136

GB requests normative clarification in 29.6 [atomics.types.operations] p.4 that concurrent access constitutes a race, as already done on p.6 and p.7.

[ Resolution proposed in ballot comment: ]

Initialisation of atomics:

We believe the intent is that for any atomics there is a distinguished initialisation write, but that this need not happens-before all the other operations on that atomic - specifically so that the initialisation write might be non-atomic and hence give rise to a data race, and hence undefined behaviour, in examples such as this (from Hans):

atomic<atomic<int> *> p
f()                      |
{ atomic<int>x;          | W_na x
  p.store(&x,mo_rlx);    | W_rlx p=&x
}                        |

(where na is nonatomic and rlx is relaxed). We suspect also that no other mixed atomic/nonatomic access to the same location is intended to be permitted. Either way, a note would probably help.

[2011-02-26: Hans comments and drafts wording]

I think the important point here is to clarify that races on atomics are possible, and can be introduced as a result of non-atomic initialization operations. There are other parts of this that remain unclear to me, such as whether there are other ways to introduce data races on atomics, or whether the races with initialization also introduce undefined behavior by the 3.8 lifetime rules. But I don't think that it is necessary to resolve those issues before releasing the standard. That's particularly true since we've introduced atomic_init, which allows easier ways to construct initialization races.

Proposed resolution:

  1. Update 29.6.5 [atomics.types.operations.req] p. 5 as follows:

    constexpr A::A(C desired);
    

    5 Effects: Initializes the object with the value desired. [ Note: Construction is not atomic. — end note ] Initialization is not an atomic operation (1.10) [intro.multithread]. [Note: It is possible to have an access to an atomic object A race with its construction, for example by communicating the address of the just-constructed object A to another thread via memory_order_relaxed atomic operations on a suitable atomic pointer variable, and then immediately accessing A in the receiving thread. This results in undefined behavior. — end note]

  2. In response to the editor comment to 29.6.5 [atomics.types.operations.req] p. 8: The first Effects element is the correct and intended one:

    void atomic_init(volatile A *object, C desired);
    void atomic_init(A *object, C desired);
    

    8 Effects: Non-atomically initializes *object with value desired. This function shall only be applied to objects that have been default constructed, and then only once. [ Note: these semantics ensure compatibility with C. — end note ] [ Note: Concurrent access from another thread, even via an atomic operation, constitutes a data race. — end note ] [Editor's note: The preceding text is from the WD as amended by N3196. N3193 makes different changes, marked up in the paper as follows:] Effects: Dynamically initializes an atomic variable. Non-atomically That is, non-atomically assigns the value desired to *object. [ Note: this operation may need to initialize locks. — end note ] Concurrent access from another thread, even via an atomic operation, constitutes a data race.


1487. [FCD] Clock related operations exception specifications conflict

Section: 30.3.2 [thread.thread.this] Status: Open Submitter: Switzerland Opened: 2010-08-25 Last modified: 2011-02-28

View other active issues in [thread.thread.this].

View all other issues in [thread.thread.this].

View all issues with Open status.

Discussion:

Addresses CH-25

Clock related operations are currently not required not to throw. So "Throws: Nothing." is not always true.

[ Resolution proposed by ballot comment: ]

Either require clock related operations not to throw (in 20.10) or change the Throws clauses in 30.3.2. Also possibly add a note that abs_time in the past or negative rel_time is allowed.

[2011-02-10: Howard Hinnant provides a resolution proposal]

[Previous proposed resolution:]

  1. Change the Operational semantics of C1::now() in 20.11.3 [time.clock.req], Table 59 — Clock requirements as follows:

    Table 59 — Clock requirements
    Expression Return type Operational semantics
    C1::now() C1::time_point Returns a time_point object
    representing the current point in time.
    Shall not throw an exception.

[2011-02-19: Daniel comments and suggests an alternative wording]

Imposing the no-throw requirement on C1::now() of any clock time is an overly radical step: It has the indirect consequences that representation types for C1::rep can never by types with dynamic memory managment, e.g. my big_int, which are currently fully supported by the time utilities. Further-on this strong constraint does not even solve the problem described in the issue, because we are still left with the fact that any of the arithmetic operations of C1::rep, C1::duration, and C1::time_point may throw exceptions.

The alternative proposal uses the following strategy: The general Clock requirements remain untouched, but we require that any functions of the library-provided clocks from sub-clause 20.11.7 [time.clock] and their associated types shall not throw exceptions. Second, we replace existing noexcept specifications of functions from Clause 30 that depend on durations, clocks, or time points by wording that clarifies that these functions can only throw, if the operations of user-provided durations, clocks, or time points used as arguments to these functions throw exceptions.

Proposed resolution:

  1. Add the following new requirement set at the end of sub-clause 20.11.3 [time.clock.req]: [Comment: This requirement set is intentionally incomplete. The reason for this incompleteness is the based on the fact, that if we would make it right for C++0x, we would end up defining something like a complete ArithmeticLike concept for TC::rep, TC::duration, and TC::time_point. But this looks out-of scope for C++0x to me. The effect is that we essentially do not exactly say, which arithmetic or comparison operations can be used in the time-dependent functions from Clause 30, even though I expect that all declared functions of duration and time_point are well-formed and well-defined. — end comment]

    3 [ Note: the relative difference in durations between those reported by a given clock and the SI definition is a measure of the quality of implementation. — end note ]

    ? A type TC meets the TrivialClock requirements if:

    • TC satisfies the Clock requirements (20.11.3 [time.clock.req]),

    • the types TC::rep, TC::duration, and TC::time_point satisfy the requirements of EqualityComparable ( [equalitycomparable]), LessThanComparable ( [lessthancomparable]), DefaultConstructible ( [defaultconstructible]), CopyConstructible ( [copyconstructible]), CopyAssignable ( [copyassignable]), Destructible ( [destructible]), and of numeric types ([numeric.requirements]) [Note: This means in particular, that operations of these types will not throw exceptions — end note ],

    • lvalues of the types TC::rep, TC::duration, and TC::time_point are swappable (17.6.3.2 [swappable.requirements]),

    • the function TC::now() does not throw exceptions, and

    • the type TC::time_point::clock does meet the TrivialClock requirements, recursively.

  2. Modify 20.11.7 [time.clock] p. 1 as follows:

    1 - The types defined in this subclause shall satisfy the TrivialClock requirements (20.11.1).

  3. Modify 20.11.7.1 [time.clock.system] p. 1, class system_clock synopsis, as follows:

    class system_clock {
    public:
      typedef see below rep;
      typedef ratio<unspecified , unspecified > period;
      typedef chrono::duration<rep, period> duration;
      typedef chrono::time_point<system_clock> time_point;
      static const bool is_monotonic is_steady = unspecified;
      static time_point now() noexcept;
      // Map to C API
      static time_t to_time_t (const time_point& t) noexcept;
      static time_point from_time_t(time_t t) noexcept;
    };
    
  4. Modify the prototype declarations in 20.11.7.1 [time.clock.system] p. 3 + p. 4 as indicated (This edit also fixes the miss of the static specifier in these prototype declarations):

    static time_t to_time_t(const time_point& t) noexcept;
    

    3 - [...]

    static time_point from_time_t(time_t t) noexcept;
    

    4 - [...]

  5. Modify 20.11.7.2 [time.clock.steady] p. 1, class steady_clock synopsis, as follows:

    class steady_clock {
    public:
      typedef unspecified rep;
      typedef ratio<unspecified , unspecified > period;
      typedef chrono::duration<rep, period> duration;
      typedef chrono::time_point<unspecified, duration> time_point;
      static const bool is_monotonic is_steady = true;
    
      static time_point now() noexcept;
    };
    
  6. Modify 20.11.7.3 [time.clock.hires] p. 1, class high_resolution_clock synopsis, as follows:

    class high_resolution_clock {
    public:
      typedef unspecified rep;
      typedef ratio<unspecified , unspecified > period;
      typedef chrono::duration<rep, period> duration;
      typedef chrono::time_point<unspecified, duration> time_point;
      static const bool is_monotonic is_steady = unspecified;
    
      static time_point now() noexcept;
    };
    
  7. Add a new paragraph at the end of 30.2.4 [thread.req.timing]:

    6 The resolution of timing provided by an implementation depends on both operating system and hardware. The finest resolution provided by an implementation is called the native resolution.

    ? Implementation-provided clocks that are used for these functions shall meet the TrivialClock requirements (20.11.3 [time.clock.req]).

  8. Edit the synopsis of 30.3.2 [thread.thread.this] before p. 1:

    template <class Clock, class Duration>
    void sleep_until(const chrono::time_point<Clock, Duration>& abs_time) noexcept;
    template <class Rep, class Period>
    void sleep_for(const chrono::duration<Rep, Period>& rel_time) noexcept;
    
  9. Modify the prototype specifications in 30.3.2 [thread.thread.this] before p. 4 and p. 6 and re-add a Throws element following the Synchronization elements at p. 5 and p. 7:

    template <class Clock, class Duration>
    void sleep_until(const chrono::time_point<Clock, Duration>& abs_time) noexcept;
    

    4 - [...]

    5 - Synchronization: None.

    ? - Throws: Nothing unless an exception is thrown by Clock::now() or by an operation of abs_time. [Note: Instantiations of time point types and clocks supplied by the implementation as specified in 20.11.7 [time.clock] do not throw exceptions. — end note]

    template <class Rep, class Period>
    void sleep_for(const chrono::duration<Rep, Period>& rel_time) noexcept;
    

    6 [...]

    7 Synchronization: None.

    ? Throws: Nothing unless an exception is thrown by an operation of rel_time. [Note: Instantiations of duration types supplied by the implementation as specified in 20.11.7 [time.clock] do not throw exceptions. — end note]

  10. Modify the Throws elements of 30.4.1.3 [thread.timedmutex.requirements] p. 9 and p. 16 as indicated and modify the Effects elements p. 5 and p. 12 to clarify the lock state in the presence of exceptions. Note that the edit also fixes a minor incorrectness in p. 5: Duration types need to compare against duration<>::zero(), not 0:

    3 The expression m.try_lock_for(rel_time) shall be well-formed and have the following semantics:

    [...]

    5 Effects: The function attempts to obtain ownership of the mutex within the relative timeout (30.2.4) specified by rel_time. If the time specified by rel_time is less than or equal to 0rel_time.zero(), the function attempts to obtain ownership without blocking (as if by calling try_lock()). The function shall return within the timeout specified by rel_time only if it has obtained ownership of the mutex object or an exception is thrown. If an exception is thrown then a lock shall not have been acquired for the current execution agent. [ Note: As with try_lock(), there is no guarantee that ownership will be obtained if the lock is available, but implementations are expected to make a strong effort to do so. — end note ]

    [...]

    9 Throws: Nothing unless an exception is thrown by an operation of rel_time. [Note: Instantiations of duration types supplied by the implementation as specified in 20.11.7 [time.clock] do not throw exceptions. — end note].

    10 The expression m.try_lock_until(abs_time) shall be well-formed and have the following semantics:

    [...]

    12 Effects: The function attempts to obtain ownership of the mutex. If abs_time has already passed, the function attempts to obtain ownership without blocking (as if by calling try_lock()). The function shall return before the absolute timeout (30.2.4) specified by abs_time only if it has obtained ownership of the mutex object or an exception is thrown. If an exception is thrown then a lock shall not have been acquired for the current execution agent. [ Note: As with try_lock(), there is no guarantee that ownership will be obtained if the lock is available, but implementations are expected to make a strong effort to do so. — end note ]

    [...]

    16 Throws: Nothing unless an exception is thrown by the now() function of the used clock or by an operation of abs_time. [Note: Instantiations of time point types and clocks supplied by the implementation as specified in 20.11.7 [time.clock] do not throw exceptions. — end note].

  11. Modify the class timed_mutex synopsis in 30.4.1.3.1 [thread.timedmutex.class] as indicated:

    class timed_mutex {
    public:
      [...]
      template <class Rep, class Period>
        bool try_lock_for(const chrono::duration<Rep, Period>& rel_time) noexcept;
      template <class Clock, class Duration>
        bool try_lock_until(const chrono::time_point<Clock, Duration>& abs_time) noexcept;
      [...]
    };
    
  12. Modify the class recursive_timed_mutex synopsis in 30.4.1.3.2 [thread.timedmutex.recursive] as indicated:

    class recursive_timed_mutex {
    public:
      [...]
      template <class Rep, class Period>
        bool try_lock_for(const chrono::duration<Rep, Period>& rel_time) noexcept;
      template <class Clock, class Duration>
        bool try_lock_until(const chrono::time_point<Clock, Duration>& abs_time) noexcept;
      [...]
    };
    
  13. Modify the class template unique_lock synopsis in 30.4.2.2 [thread.lock.unique] as indicated. This edit seems also to fix an inconsistency between the timed waiting c'tors and the timed waiting member functions (see next bullet):

    template <class Mutex>
    class unique_lock {
    public:
      [...]
      template <class Clock, class Duration>
        unique_lock(mutex_type& m, const chrono::time_point<Clock, Duration>& abs_time) noexcept;
      template <class Rep, class Period>
        unique_lock(mutex_type& m, const chrono::duration<Rep, Period>& rel_time) noexcept;
      [...]
    };
    
  14. Modify the constructor prototypes in 30.4.2.2.1 [thread.lock.unique.cons] before p. 14 and p. 17 and re-add Throws elements as indicated. This edit seems also to fix an inconsistency compared to the timed waiting member functions:

    template <class Clock, class Duration>
      unique_lock(mutex_type& m, const chrono::time_point<Clock, Duration>& abs_time) noexcept;
    

    [...]

    16 Postconditions: pm == &m and owns == res, where res is the value returned by the call to m.try_lock_until(abs_time).

    ?? Throws: Nothing unless the exception is thrown by m.try_lock_until(abs_time).

    template <class Rep, class Period>
      unique_lock(mutex_type& m, const chrono::duration<Rep, Period>& rel_time) noexcept;
    

    [...]

    19 Postconditions: pm == &m and owns == res, where res is the value returned by the call to m.try_lock_for(rel_time).

    ?? Throws: Nothing unless the exception is thrown by m.try_lock_for(rel_time).

  15. Modify the time-related Throws elements in 30.5.1 [thread.condition.condvar], p. 19, p. 25, p. 36 and add some new Throws elements as indicated. The latter are needed to honor possible exceptions from predicates [As an editorial recommendation it is suggested if issue 1497 is accepted to insert the new Throws element following [thread.condition.condvar] p. 14 in front of the added "std::system_error when an exception is required (30.2.2)" of 1497 and insert the word "Otherwise, " between these sentences. The same recommendation is given for the similar Throws element addition following [thread.condition.condvar] p. 29]:

    [...]

    template <class Predicate>
    void wait(unique_lock<mutex>& lock, Predicate pred);
    

    14 Effects:

    while (!pred())
      wait(lock);
    

    ?? Throws: Any exception thrown by an operation of pred or as result of the remaining effects.

    [...]

    19 Throws: Any exception thrown by Clock::now() or by an operation of abs_time. [Note: Instantiations of time point types and clocks supplied by the implementation as specified in 20.11.7 [time.clock] do not throw exceptions. — end note] Otherwise system_error when an exception is required (30.2.2).

    [...]

    25 Throws: Any exception thrown by an operation of rel_time. [Note: Instantiations of duration types supplied by the implementation as specified in 20.11.7 [time.clock] do not throw exceptions. — end note] Otherwise system_error when an exception is required (30.2.2).

    [...]

    template <class Clock, class Duration, class Predicate>
    bool wait_until(unique_lock<mutex>& lock,
      const chrono::time_point<Clock, Duration>& abs_time, Predicate pred);
    

    27 Effects:

    while (!pred())
      if (wait_until(lock, abs_time) == cv_status::timeout)
        return pred();
    return true;
    

    28 Returns: pred()

    29 [ Note: The returned value indicates whether the predicate evaluates to true regardless of whether the timeout was triggered. — end note ]

    ?? Throws: Any exception thrown by an operation of pred or as result of the remaining effects.

    template <class Rep, class Period, class Predicate>
    bool wait_for(unique_lock<mutex>& lock,
      const chrono::duration<Rep, Period>& rel_time, Predicate pred);
    

    [...]

    31 Effects: as if

    return wait_until(lock, chrono::steady_clock::now() + rel_time, std::move(pred));
    

    [...]

    36 Throws: Any exception thrown by an operation of rel_time or pred. [Note: Instantiations of duration types supplied by the implementation as specified in 20.11.7 [time.clock] do not throw exceptions. — end note] Otherwise system_error when an exception is required (30.2.2).

  16. Modify the time-related Throws elements in 30.5.2 [thread.condition.condvarany], p. 15, p. 20, p. 30 and add some new Throws elements as indicated. The latter are needed to honor possible exceptions from predicates:

    [...]

    template <class Lock, class Predicate>
    void wait(Lock& lock, Predicate pred);
    

    11 Effects:

    while (!pred())
      wait(lock);
    

    ?? Throws: Any exception thrown by an operation of pred or as result of the remaining effects.

    [...]

    15 Throws: Any exception thrown by Clock::now() or by an operation of abs_time. [Note: Instantiations of time point types and clocks supplied by the implementation as specified in 20.11.7 [time.clock] do not throw exceptions. — end note] Otherwise system_error when an exception is required (30.2.2).

    [...]

    20 Throws: Any exception thrown by an operation of rel_time. [Note: Instantiations of duration types supplied by the implementation as specified in 20.11.7 [time.clock] do not throw exceptions. — end note]. Otherwise system_error when an exception is required (30.2.2).

    [...]

    template <class Lock, class Clock, class Duration, class Predicate>
    bool wait_until(Lock& lock, const chrono::time_point<Clock, Duration>& abs_time, Predicate pred);
    

    22 Effects:

    while (!pred())
      if (wait_until(lock, abs_time) == cv_status::timeout)
        return pred();
    return true;
    

    23 Returns: pred()

    24 [ Note: The returned value indicates whether the predicate evaluates to true regardless of whether the timeout was triggered. — end note ]

    ?? Throws: Any exception thrown by an operation of pred or as result of the remaining effects.

    template <class Lock, class Rep, class Period, class Predicate>
    bool wait_for(Lock& lock, const chrono::duration<Rep, Period>& rel_time, Predicate pred);
    

    25 Effects: as if

    return wait_until(lock, chrono::steady_clock::now() + rel_time, std::move(pred));
    

    [...]

    30 Throws: Any exception thrown by an operation of rel_time or pred. [Note: Instantiations of duration types supplied by the implementation as specified in 20.11.7 [time.clock] do not throw exceptions. — end note] Otherwise system_error when an exception is required (30.2.2).


1502. [FCD] Specification of [futures.state]

Section: 30.6.4 [futures.state] Status: Open Submitter: INCITS Opened: 2010-08-25 Last modified: 2011-02-21

View all other issues in [futures.state].

View all issues with Open status.

Discussion:

Addresses US-195

The intent and meaning of the paragraph is not apparent.

Proposed resolution:


1504. [FCD] Term "are serialized" is not defined

Section: 30.6.5 [futures.promise] Status: Open Submitter: INCITS Opened: 2010-08-25 Last modified: 2011-02-21

View other active issues in [futures.promise].

View all other issues in [futures.promise].

View all issues with Open status.

Discussion:

Addresses US-196

The term "are serialized" is not defined (30.6.5 [futures.promise] p. 21, 25).

[ Resolution proposed by ballot comment: ]

Replace "are serialized" with "shall not introduce a data race (17.6.4.8)".

[ 2010-11-02 Daniel translates proposal into proper wording changes ]

Proposed resolution:

  1. Change 30.6.5 [futures.promise] p. 21 as indicated:

    21 Synchronization: calls to set_value and set_exception on a single promise object are serializedshall not introduce a data race ([res.on.data.races]). [ Note: and they synchronize and serialize with other functions through the referred associated asynchronous state. — end note ]

  2. Change 30.6.5 [futures.promise] p. 25 as indicated:

    25 Synchronization: calls to set_value and set_exception on a single promise object are serializedshall not introduce a data race ([res.on.data.races]). [ Note: and they synchronize and serialize with other functions through the referred associated asynchronous state. — end note ]


1505. [FCD] Synchronization between promise::set_value and future::get

Section: 30.6.5 [futures.promise] Status: Open Submitter: INCITS Opened: 2010-08-25 Last modified: 2011-02-21

View other active issues in [futures.promise].

View all other issues in [futures.promise].

View all issues with Open status.

Discussion:

Addresses US-197

There is no defined synchronization between promise::set_value and future::get (30.6.5 [futures.promise] p. 21, 25).

[ Resolution proposed by ballot comment: ]

Replace "[Note: and they synchronize and serialize with other functions through the referred associated asynchronous state. — end note]" with the normative "They synchronize with (1.10) any operation on a future object with the same associated asynchronous state marked ready."

[ 2010-11-02 Daniel translates proposal into proper wording changes ]

Proposed resolution:

  1. Change 30.6.5 [futures.promise] p. 21 as indicated:

    21 Synchronization: calls to set_value and set_exception on a single promise object are serialized. [ Note: and they synchronize and serialize with other functions through the referred associated asynchronous state. — end note ]They synchronize with ([intro.multithread]) any operation on a future object with the same associated asynchronous state marked ready.

  2. Change 30.6.5 [futures.promise] p. 25 as indicated:

    25 Synchronization: calls to set_value and set_exception on a single promise object are serialized. [ Note: and they synchronize and serialize with other functions through the referred associated asynchronous state. — end note ]They synchronize with ([intro.multithread]) any operation on a future object with the same associated asynchronous state marked ready.


1507. [FCD] promise::XXX_at_thread_exit functions have no synchronization requirements

Section: 30.6.5 [futures.promise] Status: Open Submitter: INCITS Opened: 2010-08-25 Last modified: 2011-02-21

View other active issues in [futures.promise].

View all other issues in [futures.promise].

View all issues with Open status.

Discussion:

Addresses US-199

promise::XXX_at_thread_exit functions have no synchronization requirements. Specifying synchronization for these member functions requires coordinating with the words in 30.6.5/21 and 25, which give synchronization requirements for promise::set_value and promise::set_exception (30.6.5 [futures.promise] p. 26 ff., p. 29 ff.).

[ Resolution proposed by ballot comment: ]

Change 30.6.5/21 to mention set_value_at_thread_exit and set_exception_at_thread_exit; with this text, replace 30.6.5/25 and add two new paragraphs, after 30.6.5/28 and 30.6.5/31.

Proposed resolution:


1521. Requirements on internal pointer representations in containers

Section: 23.2.1 [container.requirements.general] Status: New Submitter: Mike Spertus Opened: 2010-10-16 Last modified: 2011-02-21

View other active issues in [container.requirements.general].

View all other issues in [container.requirements.general].

View all issues with New status.

Discussion:

Addresses US-104, US-141

The standard doesn't say that containers should use abstract pointer types internally. Both Howard and Pablo agree that this is the intent. Further, it is necessary for containers to be stored, for example, in shared memory with an interprocess allocator (the type of scenario that allocators are intended to support).

In spite of the (possible) agreement on intent, it is necessary to make this explicit:

An implementations may like to store the result of dereferencing the pointer (which is a raw reference) as an optimization, but that prevents the data structure from being put in shared memory, etc. In fact, a container could store raw references to the allocator, which would be a little weird but conforming as long as it has one by-value copy. Furthermore, pointers to locales, ctypes, etc. may be there, which also prevents the data structure from being put in shared memory, so we should make explicit that a container does not store raw pointers or references at all.

[ Pre-batavia ]

This issue is being opened as part of the response to NB comments US-104/141. See paper N3171 in the pre-Batavia mailing.

Proposed resolution:

Add to the end of 23.2.1 [container.requirements.general] p. 8:

[..] In all container types defined in this Clause, the member get_allocator() returns a copy of the allocator used to construct the container or, if that allocator has been replaced, a copy of the most recent replacement. The container may not store internal objects whose types are of the form T * or T & except insofar as they are part of the item type or members.


1523. [FCD] noexcept for Clause 29

Section: 29 [atomics] Status: New Submitter: Hans Boehm Opened: 2010-11-13 Last modified: 2010-11-14

View other active issues in [atomics].

View all other issues in [atomics].

View all issues with New status.

Discussion:

Addresses GB-63 for Clause 29

Clause 29 does not specify noexcept for any of the atomic operations. It probably should, though that's not completely clear. In particular, atomics may want to throw in implementations that support transactional memory.

Proposed resolution:


1524. [FCD] Allocation functions are missing happens-before requirements and guarantees

Section: 5.3.4 [expr.new], 5.3.5 [expr.delete] Status: New Submitter: Hans Boehm Opened: 2011-02-26 Last modified: 2011-02-28

View all issues with New status.

Discussion:

Addresses US-34

Technical details:

When the same unit of storage is allocated and deallocated repeatedly, operations on it can't be allowed to race between the allocator and the user program. But I don't see any mention of happens-before in the descriptions of allocation and deallocation functions.

Proposed resolution (not wording yet):

[2011-02-26: Hans comments and drafts wording]

The second requirement already exists, almost verbatim, as 18.6.1.4 [new.delete.dataraces] p. 1. I think this is where the statement belongs. However, this paragraph requires work to correctly address the first part of the issue.

Proposed resolution:

Change 18.6.1.4 [new.delete.dataraces] p. 1 as follows:

1 The library versions of operator new and operator delete, user replacement versions of global operator new and operator delete, and the C standard library functions calloc, malloc, realloc, and free shall not introduce data races (1.10 [intro.multithread]) as a result of concurrent calls from different threads. For purposes of determining the existence of data races, the library versions of operator new, user replacement versions of global operator new, and the C standard library functions calloc and malloc shall behave as though they accessed and modified only the storage referenced by the return value. The library versions of operator delete, user replacement versions of operator delete, and the C standard library function free shall behave as though they accessed and modified only the storage referenced by their first argument. The C standard library realloc function shall behave as though it accessed and modified only the storage referenced by its first argument and by its return value. Calls to these functions that allocate or deallocate a particular unit of storage shall occur in a single total order, and each such deallocation call shall happen before the next allocation (if any) in this order.


2003. String exception inconsistency in erase.

Section: 21.4.1 [string.require] Status: Open Submitter: José Daniel García Sánchez Opened: 2010-10-21 Last modified: 2011-02-21

View all other issues in [string.require].

View all issues with Open status.

Discussion:

Clause 21.4.1 [string.require]p3 states:

No erase() or pop_back() member function shall throw any exceptions.

However in 21.4.6.5 [string::erase] p2 the first version of erase has

Throws: out_of_range if pos > size().

Proposed resolution:

Update [string.require]p/3:

3 No erase() or pop_back() member function shall throw any exceptions.


2005. unordered_map::insert(T&&) protection should apply to map too

Section: 23.4.4.4 [map.modifiers], 23.4.5.3 [multimap.modifiers] Status: Open Submitter: P.J. Plauger Opened: 2010-10-14 Last modified: 2011-02-21

View all issues with Open status.

Discussion:

In [unord.map.modifiers], the signature:

template <class P>
    pair<iterator, bool> insert(P&& obj);

now has an added Remarks paragraph:

Remarks: This signature shall not participate in overload resolution unless P is implicitly convertible to value_type.

The same is true for unordered_multimap.

But neither map nor multimap have this constraint, even though it is a Good Thing(TM) in those cases as well.

[ The submitter suggests: Add the same Remarks clause to [map.modifiers] and [multimap.modifiers]. ]

[ 2010-10-29 Daniel comments: ]

I believe both paragraphs need more cleanup: First, the current Requires element conflict with the Remark; second, it seems to me that the whole single Requires element is intended to be split into a Requires and an Effects element; third, the reference to tuple is incorrect (noticed by Paolo Carlini); fourth, it refers to some non-existing InputIterator parameter relevant for a completely different overload; sixth, the return type of the overload with hint is wrong. The following proposed resolution tries to solve these issues as well and uses similar wording as for the corresponding unordered containers. Unfortunately it has some redundancy over Table 99, but I did not remove the specification because of the more general template parameter P - the Table 99 requirements apply only for an argument identical to value_type.

Proposed resolution:

  1. Change 23.4.4.4 [map.modifiers] around p. 1 as indicated:
    template <class P> pair<iterator, bool> insert(P&& x);
    template <class P> pair<iterator, bool> insert(const_iterator position, P&& x);
    

    1 Requires: P shall be convertible to value_type is constructible from std::forward<P>(x)..

    If P is instantiated as a reference type, then the argument x is copied from. Otherwise x is considered to be an rvalue as it is converted to value_type and inserted into the map. Specifically, in such cases CopyConstructible is not required of key_type or mapped_type unless the conversion from P specifically requires it (e.g., if P is a tuple<const key_type, mapped_type>, then key_type must be CopyConstructible). The signature taking InputIterator parameters does not require CopyConstructible of either key_type or mapped_type if the dereferenced InputIterator returns a non-const rvalue pair<key_type,mapped_type>. Otherwise CopyConstructible is required for both key_type and mapped_type.
    ? Effects: Inserts x converted to value_type if and only if there is no element in the container with key equivalent to the key of value_type(x). For the second form, the iterator position is a hint pointing to where the search should start.

    ? Returns: For the first form, the bool component of the returned pair object indicates whether the insertion took place and the iterator component - or for the second form the returned iterator - points to the element with key equivalent to the key of value_type(x).

    ? Complexity: Logarithmic in general, but amortized constant if x is inserted right before position.

    ? Remarks: These signatures shall not participate in overload resolution unless P is implicitly convertible to value_type.

  2. Change 23.4.5.3 [multimap.modifiers] around p. 1 as indicated:
    template <class P> iterator insert(P&& x);
    template <class P> iterator insert(const_iterator position, P&& x);
    

    1 Requires: P shall be convertible to value_type is constructible from std::forward<P>(x).

    If P is instantiated as a reference type, then the argument x is copied from. Otherwise x is considered to be an rvalue as it is converted to value_type and inserted into the map. Specifically, in such cases CopyConstructible is not required of key_type or mapped_type unless the conversion from P specifically requires it (e.g., if P is a tuple<const key_type, mapped_type>, then key_type must be CopyConstructible). The signature taking InputIterator parameters does not require CopyConstructible of either key_type or mapped_type if the dereferenced InputIterator returns a non-const rvalue pair<key_type, mapped_type>. Otherwise CopyConstructible is required for both key_type and mapped_type.
    ? Effects: Inserts x converted to value_type. For the second form, the iterator position is a hint pointing to where the search should start.

    ? Returns: An iterator that points to the element with key equivalent to the key of value_type(x).

    ? Complexity: Logarithmic in general, but amortized constant if x is inserted right before position.

    ? Remarks: These signatures shall not participate in overload resolution unless P is implicitly convertible to value_type.

[ 2010 Batavia: ]

We need is_convertible, not is_constructible, both in ordered and unordered containers.

Proposed resolution:

  1. Add a new Remarks element after 23.4.4.4 [map.modifiers] p. 1:
    template <class P> pair<iterator, bool> insert(P&& x);
    template <class P> pair<iterator, bool> insert(const_iterator position, P&& x);
    

    1 Requires: P shall be convertible to value_type.

    If P is instantiated as a reference type, then the argument x is copied from. Otherwise x is considered to be an rvalue as it is converted to value_type and inserted into the map. Specifically, in such cases CopyConstructible is not required of key_type or mapped_type unless the conversion from P specifically requires it (e.g., if P is a tuple<const key_type, mapped_type>, then key_type must be CopyConstructible). The signature taking InputIterator parameters does not require CopyConstructible of either key_type or mapped_type if the dereferenced InputIterator returns a non-const rvalue pair<key_type,mapped_type>. Otherwise CopyConstructible is required for both key_type and mapped_type.

    ? Remarks: These signatures shall not participate in overload resolution unless P is implicitly convertible to value_type.

  2. Change 23.4.5.3 [multimap.modifiers] around p. 1 as indicated:
    template <class P> iterator insert(P&& x);
    template <class P> iterator insert(const_iterator position, P&& x);
    

    1 Requires: P shall be convertible to value_type.

    If P is instantiated as a reference type, then the argument x is copied from. Otherwise x is considered to be an rvalue as it is converted to value_type and inserted into the map. Specifically, in such cases CopyConstructible is not required of key_type or mapped_type unless the conversion from P specifically requires it (e.g., if P is a tuple<const key_type, mapped_type>, then key_type must be CopyConstructible). The signature taking InputIterator parameters does not require CopyConstructible of either key_type or mapped_type if the dereferenced InputIterator returns a non-const rvalue pair<key_type, mapped_type>. Otherwise CopyConstructible is required for both key_type and mapped_type.

    ? Remarks: These signatures shall not participate in overload resolution unless P is implicitly convertible to value_type.


2008. Conflicting Error Conditions for packaged_task::operator()

Section: 30.6.9.1 [futures.task.members] Status: New Submitter: Pete Becker Opened: 2010-06-21 Last modified: 2011-02-21

View other active issues in [futures.task.members].

View all other issues in [futures.task.members].

View all issues with New status.

Discussion:

The Throws clause for packaged_task::operator() says that it throws "a future_error exception object if there is no associated asynchronous state or the stored task has already been invoked." However, the Error Conditions clause does not define an error condition when the stored task has already been invoked, only when the associated state is already ready (i.e. the invocation has completed).

[2011-02-17 Anthony provides an alternative resolution]

Previous proposed resolution:

Change the first bullet item in 30.6.9.1 [futures.task.members] /22:

void operator()(ArgTypes... args);

20 ...

21 ...

22 Error conditions:

Proposed resolution:

  1. Change the first bullet item in 30.6.9.1 [futures.task.members] p. 17:

    void operator()(ArgTypes... args);
    

    15 ...

    16 ...

    17 Error conditions:

    • promise_already_satisfied if the associated asynchronous state is already readystored task has already been invoked.
    • no_state if *this has no associated asynchronous state.
  2. Change the first bullet item in 30.6.9.1 [futures.task.members] p. 21:

    void make_ready_at_thread_exit(ArgTypes... args);
    

    19 ...

    20 ...

    21 Error conditions:

    • promise_already_satisfied if the associated asynchronous state already has a stored value or exceptionstored task has already been invoked.
    • no_state if *this has no associated asynchronous state.

2009. Reporting out-of-bound values on numeric string conversions

Section: 21.5 [string.conversions] Status: Review Submitter: Alisdair Meredith Opened: 2010-07-19 Last modified: 2010-11-13

View all other issues in [string.conversions].

Discussion:

The functions (w)stoi and (w)stof are specified in terms of calling C library APIs for potentially wider types. The integer and floating-point versions have subtly different behaviour when reading values that are too large to convert. The floating point case will throw out_of_bound if the read value is too large to convert to the wider type used in the implementation, but behaviour is undefined if the converted value cannot narrow to a float. The integer case will throw out_of_bounds if the converted value cannot be represented in the narrower type, but throws invalid_argument, rather than out_of_bounds, if the conversion to the wider type fails due to overflow.

Suggest that the Throws clause for both specifications should be consistent, supporting the same set of fail-modes with the matching set of exceptions.

Proposed resolution:

21.5p3 [string.conversions]

int stoi(const string& str, size_t *idx = 0, int base = 10);
long stol(const string& str, size_t *idx = 0, int base = 10);
unsigned long stoul(const string& str, size_t *idx = 0, int base = 10);
long long stoll(const string& str, size_t *idx = 0, int base = 10);
unsigned long long stoull(const string& str, size_t *idx = 0, int base = 10);

...

3 Throws: invalid_argument if strtol, strtoul, strtoll, or strtoull reports that no conversion could be performed. Throws out_of_range if strtol, strtoul, strtoll or strtoull sets errno to ERANGE, or if the converted value is outside the range of representable values for the return type.

21.5p6 [string.conversions]

float stof(const string& str, size_t *idx = 0);
double stod(const string& str, size_t *idx = 0);
long double stold(const string& str, size_t *idx = 0);

...

6 Throws: invalid_argument if strtod or strtold reports that no conversion could be performed. Throws out_of_range if strtod or strtold sets errno to ERANGE or if the converted value is outside the range of representable values for the return type.


2010. is_* traits for binding operations can't be meaningfully specialized

Section: 20.8.9.1.1 [func.bind.isbind] Status: Open Submitter: Sean Hunt Opened: 2010-07-19 Last modified: 2011-02-21

View all other issues in [func.bind.isbind].

View all issues with Open status.

Discussion:

20.8.9.1.1 [func.bind.isbind] says for is_bind_expression:

Users may specialize this template to indicate that a type should be treated as a subexpression in a bind call.

But it also says:

If T is a type returned from bind, is_bind_expression<T> shall be publicly derived from integral_constant<bool, true>, otherwise from integral_constant<bool, false>.

This means that while the user is free to specialize, any specialization would have to be false to avoid violating the second requirement. A similar problem exists for is_placeholder.

[ 2010 Batavia (post meeting session) ]

Alisdair recognises this is clearly a bug introduced by some wording he wrote, the sole purpose of this metafunction is as a customization point for users to write their own bind-expression types that participate in the standard library bind protocol. The consensus was that this should be fixed in Madrid, moved to Open.

Proposed resolution:


2011. unexpected output required of strings

Section: 21.4.8.9 [string.io] Status: Open Submitter: James Kanze Opened: 2010-07-23 Last modified: 2011-02-21

View all other issues in [string.io].

View all issues with Open status.

Discussion:

What should the following code output?

#include <string>
#include <iostream>
#include <iomanip>

int 
main() 
{ 
   std::string test("0X1Y2Z"); 
   std::cout.fill('*'); 
   std::cout.setf(std::ios::internal, std::ios::adjustfield); 
   std::cout << std::setw(8) << test << std::endl; 
} 

I would expect "**0X1Y2Z", and this is what the compilers I have access to (VC++, g++ and Sun CC) do. But according to the standard, it should be "0X**1Y2Z":

21.4.8.9 [string.io]/5:

template<class charT, class traits, class Allocator>
  basic_ostream<charT, traits>&
    operator<<(basic_ostream<charT, traits>& os, const basic_string<charT,traits,Allocator>& str);

Effects: Behaves as a formatted output function (27.7.3.6.1 [ostream.formatted.reqmts]). After constructing a sentry object, if this object returns true when converted to a value of type bool, determines padding as described in 22.4.2.2.2 [facet.num.put.virtuals], then inserts the resulting sequence of characters seq as if by calling os.rdbuf()->sputn(seq, n), where n is the larger of os.width() and str.size(); then calls os.width(0).

22.4.2.2.2 [facet.num.put.virtuals]/5:

[...]

Stage 3: A local variable is initialized as

fmtflags adjustfield= (flags & (ios_base::adjustfield));

The location of any padding is determined according to Table 88.

If str.width() is nonzero and the number of charT's in the sequence after stage 2 is less than str.width(), then enough fill characters are added to the sequence at the position indicated for padding to bring the length of the sequence to str.width(). str.width(0) is called.

Table 88 — Fill padding
State Location
adjustfield == ios_base::left pad after
adjustfield == ios_base::right pad before
adjustfield == internal and a sign occurs in the representation pad after the sign
adjustfield == internal and representation after stage 1 began with 0x or 0X pad after x or X
otherwise pad before

Although it's not 100% clear what "the sequence after stage 2" should mean here, when there is no stage 2, the only reasonable assumption is that it is the contents of the string being output. In the above code, the string being output is "0X1Y2Z", which starts with "0X", so the padding should be inserted "after x or X", and not before the string. I believe that this is a defect in the standard, and not in the three compilers I tried.

[ 2010 Batavia (post meeting session) ]

Consensus that all known implementations are consistent, and disagree with the standard. Preference is to fix the standard before implementations start trying to conform to the current spec, as the current implementations have the preferred form. Howard volunteered to drught for Madrid, move to Open.

Proposed resolution:


2012. Associative maps should insert pair, not tuple

Section: 23.4 [associative] Status: New Submitter: Paolo Carlini Opened: 2010-10-29 Last modified: 2011-02-21

View all other issues in [associative].

View all issues with New status.

Discussion:

I'm seeing something strange in the paragraphs 23.4.4.4 [map.modifiers] and 23.4.5.3 [multimap.modifiers]: they both talk about tuple<const key_type, mapped_type> but I think they should be talking about pair<const key_type, mapped_type> because, among other reasons, a tuple is not convertible to a pair. If I replace tuple with pair everything makes sense to me.

The proposed resolution is obvious.

[ 2010-11-07 Daniel comments ]

This is by far not the only necessary fix within both sub-clauses. For details see the 2010-10-29 comment in 2005.

Proposed resolution:

Apply the resolution proposed by the 2010-10-29 comment in 2005.


2013. Do library implementers have the freedom to add constexpr?

Section: 17.6.5.6 [constexpr.functions] Status: New Submitter: Matt Austern Opened: 2010-11-12 Last modified: 2011-02-21

View all issues with New status.

Discussion:

Suppose that a particular function is not tagged as constexpr in the standard, but that, in some particular implementation, it is possible to write it within the constexpr constraints. If an implementer tags such a function as constexpr, is that a violation of the standard or is it a conforming extension?

There are two questions to consider. First, is this allowed under the as-if rule? Second, if it does not fall under as-if, is there (and should there be) any special license granted to implementers to do this anyway, sort of the way we allow elision of copy constructors even though it is detectable by users?

I believe that this does not fall under "as-if", so implementers probably don't have that freedom today. I suggest changing the WP to grant it. Even if we decide otherwise, however, I suggest that we make it explicit.

Proposed resolution:

In 17.6.4.6 [constexpr.functions], change paragraph 1 to:

This standard explicitly requires that certain standard library functions are constexpr [dcl.constexpr]. Additionally, an implementation may declare any function to be constexpr if that function's definition satisfies the necessary constraints. Within any header that provides any non-defining declarations of constexpr functions or constructors an implementation shall provide corresponding definitions.


2015. Incorrect pre-conditions for some type traits

Section: 20.9.4 [meta.unary] Status: New Submitter: Nikolay Ivchenkov Opened: 2010-11-08 Last modified: 2011-02-21

View all other issues in [meta.unary].

View all issues with New status.

Discussion:

According to N3126 ‑ 3.9/9,

"Scalar types, trivial class types (Clause 9), arrays of such types and cv‑qualified versions of these types (3.9.3) are collectively called trivial types."

Thus, an array (possibly of unknown bound) can be trivial type, non‑trivial type, or an array type whose triviality cannot be determined because its element type is incomplete.

According to N3126 ‑ Table 45, preconditions for std::is_trivial are defined as follows:

"T shall be a complete type, (possibly cv-qualified) void, or an array of unknown bound"

It seems that "an array of unknown bound" should be changed to "an array of unknown bound of a complete element type". Preconditions for some other templates (e.g., std::is_trivially_copyable, std::is_standard_layout, std::is_pod, and std::is_literal_type) should be changed similarly.

On the other hand, some preconditions look too restrictive. For example, std::is_empty and std::is_polymorphic might accept any incomplete non‑class type.

[2011-02-18: Daniel provides wording proposal]

While reviewing the individual preconditions I could find three different groups of either too weakening or too strengthening constraints:

  1. is_empty/is_polymorphic/is_abstract/has_virtual_destructor:

    These traits can only apply for non‑union class types, otherwise the result must always be false

  2. is_base_of:

    Similar to the previous bullet, but the current wording comes already near to that ideal, it only misses to add the non‑union aspect.

  3. is_trivial/is_trivially_copyable/is_standard_layout/is_pod/is_literal_type:

    These traits always require that std::remove_all_extents<T>::type to be cv void or a complete type.

Proposed resolution:

  1. Modify the pre-conditions of the following type traits in 20.9.4.3 [meta.unary.prop], Table 48 — Type property predicates:

    Table 48 — Type property predicates
    Template Condition Preconditions
    ...
    template <class T>
    struct is_trivial;
    T is a trivial type (3.9) remove_all_extents<T>::type
    shall be a complete type, or (possibly
    cv-qualified) void, or an array of
    unknown bound
    .
    template <class T>
    struct is_trivially_copyable;
    T is a trivially copyable
    type (3.9)
    remove_all_extents<T>::type
    shall be a complete type, or (possibly
    cv-qualified) void, or an array of
    unknown bound
    .
    template <class T>
    struct is_standard_layout;
    T is a standard-layout
    type (3.9)
    remove_all_extents<T>::type
    shall be a complete type, or (possibly
    cv-qualified) void, or an array of
    unknown bound
    .
    template <class T>
    struct is_pod;
    T is a POD type (3.9) remove_all_extents<T>::type
    shall be a complete type, or (possibly
    cv-qualified) void, or an array of
    unknown bound
    .
    template <class T>
    struct is_literal_type;
    T is a literal type (3.9) remove_all_extents<T>::type
    shall be a complete type, or (possibly
    cv-qualified) void, or an array of
    unknown bound
    .
    template <class T>
    struct is_empty;
    T is a class type, but not a
    union type, with no
    non-static data members
    other than bit-fields of
    length 0, no virtual
    member functions, no
    virtual base classes, and
    no base class B for which
    is_empty<B>::value is
    false.
    T shall be a complete type,
    (possibly cv-qualified) void, or
    an array of unknown bound
    If T
    is a non‑union class type, T
    shall be a complete type
    .
    template <class T>
    struct is_polymorphic;
    T is a polymorphic
    class (10.3)
    T shall be a complete type,
    type, (possibly cv-qualified) void, or
    an array of unknown bound
    If T
    is a non‑union class type, T
    shall be a complete type
    .
    template <class T>
    struct is_abstract;
    T is an abstract
    class (10.4)
    T shall be a complete type,
    type, (possibly cv-qualified) void, or
    an array of unknown bound
    If T
    is a non‑union class type, T
    shall be a complete type
    .
    ...
    template <class T>
    struct has_virtual_destructor;
    T has a virtual
    destructor (12.4)
    T shall be a complete type,
    (possibly cv-qualified) void, or
    an array of unknown bound
    If T
    is a non‑union class type, T
    shall be a complete type
    .
  2. Modify the pre-conditions of the following type traits in 20.9.6 [meta.rel], Table 50 — Type relationship predicates:

    Table 50 — Type relationship predicates
    Template Condition Comments
    ...
    template <class Base, class
    Derived>
    struct is_base_of;
    Base is a base class of
    Derived (10) without
    regard to cv-qualifiers
    or Base and Derived
    are not unions and
    name the same class
    type without regard to
    cv-qualifiers
    If Base and Derived are
    non‑union class types
    and are different types
    (ignoring possible cv-qualifiers)
    then Derived shall be a complete
    type. [ Note: Base classes that
    are private, protected, or
    ambigious are, nonetheless, base
    classes. — end note ]
    ...

2016. Allocators must be no-throw swappable

Section: 17.6.3.5 [allocator.requirements] Status: Open Submitter: Daniel Krügler Opened: 2010-11-17 Last modified: 2011-02-21

View all other issues in [allocator.requirements].

View all issues with Open status.

Discussion:

During the Batavia meeting it turned out that there is a definition hole for types satisfying the Allocators requirements: The problem became obvious when it was discussed whether all swap functions of Containers with internal data handles can be safely tagged with noexcept or not. While it is correct that the implicit swap function of an allocator is required to be a no-throw operation (because move/copy-constructors and assignment operators are required to be no-throw functions), there are no such requirements for specialized swap overloads for a particular allocator.

But this requirement is essential because the Containers are required to support swappable Allocators, when the value allocator_traits<>::propagate_on_container_swap evaluates to true.

[2011-02-10 Alberto, Daniel, and Pablo collaborated on the proposed wording]

The proposed resolution (based on N3225) attempts to solve the following problems:

  1. Table 44 — Allocator requirements, expression rows X::propagate_on_container_copy_assignment, X::propagate_on_container_move_assignment, and X::propagate_on_container_swap only describe operations, but no requirements. In fact, if and only if these compile-time predicates evaluate to true, the additional requirements CopyAssignable, no-throw MoveAssignable, and no-throw lvalue Swappable, respectively, are imposed on the allocator types.
  2. 23.2.1 [container.requirements.general] p. 9 misses to refer to the correct swap conditions: The current wording does not relate to 17.6.3.2 [swappable.requirements] as it should and omits to mention that lvalues shall be swapped. Additional there is one situation described twice in p. 8 and p. 9 (undefined behaviour unless a.get_allocator() == b.get_allocator() or allocator_traits<allocator_type>::propagate_on_container_swap::value == true), which should be cleaned up.

Proposed resolution:

  1. Adapt the following three rows from Table 44 — Allocator requirements:

    Table 44 — Allocator requirements
    Expression Return type Assertion/note
    pre-/post-condition
    Default
    X::propagate_on_container_copy_assignment Identical to or derived from true_type
    or false_type
    true_type only if an allocator of type X should be copied
    when the client container is copy-assigned. See Note B, below.
    false_type
    X::propagate_on_container_move_assignment Identical to or derived from true_type
    or false_type
    true_type only if an allocator of type X should be moved
    when the client container is move-assigned. See Note B, below.
    false_type
    X::propagate_on_container_swap Identical to or derived from true_type
    or false_type
    true_type only if an allocator of type X should be swapped
    when the client container is swapped. See Note B, below.
    false_type
  2. Following 17.6.3.5 [allocator.requirements] p. 3 insert a new normative paragraph:

    Note B: If X::propagate_on_container_copy_assignment::value is true, X shall satisfy the CopyAssignable requirements (Table 39 [copyassignable]). If X::propagate_on_container_move_assignment::value is true, X shall satisfy the MoveAssignable requirements (Table 38 [moveassignable]) and the move operation shall not throw exceptions. If X::propagate_on_container_swap::value is true, lvalues of X shall be swappable (17.6.3.2 [swappable.requirements]) and the swap operation shall not throw exceptions.

  3. Modify 23.2.1 [container.requirements.general] p. 8 and p. 9 as indicated:

    8 - [..] The allocator may be replaced only via assignment or swap(). Allocator replacement is performed by copy assignment, move assignment, or swapping of the allocator only if allocator_traits<allocator_type>::propagate_on_container_copy_assignment::value, allocator_traits<allocator_type>::propagate_on_container_move_assignment::value, or allocator_traits<allocator_type>::propagate_on_container_swap::value is true within the implementation of the corresponding container operation. The behavior of a call to a container's swap function is undefined unless the objects being swapped have allocators that compare equal or allocator_traits<allocator_type>::propagate_on_container_swap::value is true. In all container types defined in this Clause, the member get_allocator() returns a copy of the allocator used to construct the container or, if that allocator has been replaced, a copy of the most recent replacement.

    9 - The expression a.swap(b), for containers a and b of a standard container type other than array, shall exchange the values of a and b without invoking any move, copy, or swap operations on the individual container elements. Lvalues of aAny Compare, Pred, or Hash objects belonging to a and b shall be swappable and shall be exchanged by unqualified calls to non-member calling swap as described in 17.6.3.2 [swappable.requirements]. If allocator_traits<allocator_type>::propagate_on_container_swap::value is true, then lvalues of allocator_type shall be swappable and the allocators of a and b shall also be exchanged using a an unqualified call to non-member swap call as described in 17.6.3.2 [swappable.requirements]. Otherwise, theythe allocators shall not be swapped, and the behavior is undefined unless a.get_allocator() == b.get_allocator(). Every iterator referring to an element in one container before the swap shall refer to the same element in the other container after the swap. It is unspecified whether an iterator with value a.end() before the swap will have value b.end() after the swap.


2018. regex_traits::isctype Returns clause is wrong

Section: 28.7 [re.traits] Status: New Submitter: Jonathan Wakely Opened: 2010-11-16 Last modified: 2011-02-21

View all other issues in [re.traits].

View all issues with New status.

Discussion:

28.7 [re.traits] p. 12 says:

returns true if f bitwise or'ed with the result of calling lookup_classname with an iterator pair that designates the character sequence "w" is not equal to 0 and c == '_'

If the bitmask value corresponding to "w" has a non-zero value (which it must do) then the bitwise or with any value is also non-zero, and so isctype('_', f) returns true for any f. Obviously this is wrong, since '_' is not in every ctype category.

There's a similar problem with the following phrases discussing the "blank" char class.

Proposed resolution:

Replace the Returns clause with a description in terms of ctype categories, rather than pseudocode in terms of bitwise operations. (full replacement wording to follow)


2021. Further incorrect usages of result_of

Section: 20.8.9.1.2 [func.bind.bind], 30.6.1 [futures.overview], 30.6.8 [futures.async] Status: New Submitter: Daniel Krügler Opened: 2010-12-07 Last modified: 2011-02-21

View all other issues in [func.bind.bind].

View all issues with New status.

Discussion:

Issue 2017 points out some incorrect usages of result_of in the declaration of the function call operator overload of reference_wrapper, but there are more such specification defects:

  1. According to 20.8.9.1.2 [func.bind.bind] p. 3:

    [..] The effect of g(u1, u2, ..., uM) shall be INVOKE(fd, v1, v2, ..., vN, result_of<FD cv (V1, V2, ..., VN)>::type) [..]

    but fd is defined as "an lvalue of type FD constructed from std::forward<F>(f)". This means that the above usage must refer to result_of<FD cv & (V1, V2, ..., VN)> instead.

  2. Similar in 20.8.9.1.2 [func.bind.bind] p. 10 bullet 2 we have:

    if the value of is_bind_expression<TiD>::value is true, the argument is tid(std::forward<Uj>(uj)...) and its type Vi is result_of<TiD cv (Uj...)>::type

    Again, tid is defined as "lvalue of type TiD constructed from std::forward<Ti>(ti)". This means that the above usage must refer to result_of<TiD cv & (Uj...)> instead. We also have similar defect as in 2017 in regard to the argument types, this leads us to the further corrected form result_of<TiD cv & (Uj&&...)>. This is not the end: Since the Vi are similar sensitive to the argument problem, the last part must say:

    "[..] its type Vi is result_of<TiD cv & (Uj&&...)>::type &&"

    (The bound arguments Vi can never be void types, therefore we don't need to use the more defensive std::add_rvalue_reference type trait)

  3. The function template async is declared as follows (the other overload has the same problem):

    template <class F, class... Args>
    future<typename result_of<F(Args...)>::type>
    async(F&& f, Args&&... args);
    

    This usage has the some same problems as we have found in reference_wrapper (2017) and more: According to the specification in 30.6.8 [futures.async] the effective result type is that of the call of

    INVOKE(decay_copy(std::forward<F>(f)), decay_copy(std::forward<Args>(args))...)
    

    First, decay_copy potentially modifies the effective types to decay<F>::type and decay<Args>::type.... Second, the current specification is not really clear, what the value category of callable type or the arguments shall be: According to the second bullet of 30.6.8 [futures.async] p. 3:

    Invocation of the deferred function evaluates INVOKE(g, xyz) where g is the stored value of decay_copy(std::forward<F>(f)) and xyz is the stored copy of decay_copy(std::forward<Args>(args))....

    This seems to imply that lvalues are provided in contrast to the direct call expression of 30.6.8 [futures.async] p. 2 which implies rvalues instead. The specification needs to be clarified.

Proposed resolution:

The suggested wording changes are against the working draft N3225.

  1. Change 20.8.9.1.2 [func.bind.bind] p. 3 as indicated:

    Returns: A forwarding call wrapper g with a weak result type (20.8.2). The effect of g(u1, u2, ..., uM) shall be INVOKE(fd, v1, v2, ..., vN, result_of<FD cv & (V1, V2, ..., VN)>::type), where cv represents the cv-qualifiers of g and the values and types of the bound arguments v1, v2, ..., vN are determined as specified below. [..]

  2. Change 20.8.9.1.2 [func.bind.bind] p. 10 bullet 2 as indicated:

    if the value of is_bind_expression<TiD>::value is true, the argument is tid(std::forward<Uj>(uj)...) and its type Vi is result_of<TiD cv & (Uj&&...)>::type&&;

  3. This resolution assumes that the wording of 30.6.8 [futures.async] is incorrectly implying rvalues as arguments of INVOKE, those should be lvalues instead.

    Change the function signatures in header <future> synopsis 30.6.1 [futures.overview] p. 1 and in 30.6.8 [futures.async] p. 1 as indicated:

    template <class F, class... Args>
    future<typename result_of<typename decay<F>::type&(typename decay<Args>::type&...)>::type>
    async(F&& f, Args&&... args);
    template <class F, class... Args>
    future<typename result_of<typename decay<F>::type&(typename decay<Args>::type&...)>::type>
    async(launch policy, F&& f, Args&&... args);
    
  4. Change 30.6.8 [futures.async] p. 4 as indicated: [Note: There is one tiny editorial correction that completes one :: scope specifier] [Note: This sub-section need more wording: The call expressions used imply a different value category]

    Returns: an object of type future<typename result_of<typename decay<F>::type&(typename decay<Args>::type&...)>::type> that refers to the associated asynchronous state created by this call to async.


2025. Incorrect semantics of move assignment operator of packaged_task

Section: 30.6.9.1 [futures.task.members] Status: New Submitter: Daniel Krügler Opened: 2010-12-08 Last modified: 2011-02-21

View other active issues in [futures.task.members].

View all other issues in [futures.task.members].

View all issues with New status.

Discussion:

According to 30.6.9.1 [futures.task.members] p. 7 bullet 2:

packaged_task& operator=(packaged_task&& other);

7 Effects:

The argument other given to the move constructor is an lvalue and must be converted into an rvalue via appropriate usage of std::move.

Proposed resolution:

The suggested wording changes are against the working draft N3225.

  1. Change 30.6.9.1 [futures.task.members] p. 7 bullet 2 as indicated:

    packaged_task& operator=(packaged_task&& other);
    

    7 Effects:

    • [...]

    • packaged_task<R, ArgTypes...>(std::move(other)).swap(*this).


2028. messages_base::catalog overspecified

Section: 22.4.7.1 [locale.messages] Status: New Submitter: Howard Hinnant Opened: 2011-02-14 Last modified: 2011-02-25

View all issues with New status.

Discussion:

In 22.4.7.1 [locale.messages], messages_base::catalog is specified to be a typedef to int. This type is subsequently used to open, access and close catalogs.

However, an OS may have catalog/messaging services that are indexed and managed by types other than int. For example POSIX, publishes the following messaging API:

typedef unspecified nl_catd;

nl_catd catopen(const char* name , int oflag);
char*   catgets(nl_catd catd, int set_id, int msg_id, const char* s);
int     catclose(nl_catd catd);

I.e., the catalog is managed with an unspecified type, not necessarily an int. Mac OS uses a void* for nl_catd (which is conforming to the POSIX standard). The current messages_base spec effectively outlaws using the built-in OS messaging service supplied for this very purpose!

[2011-02-24: Chris Jefferson updates the proposed wording, changing unspecified to unspecified signed integral type]

Proposed resolution:

  1. Modify 22.4.7.1 [locale.messages]:

    namespace std {
      class messages_base {
      public:
        typedef intunspecified signed integral type catalog;
      };
      ...
    }
    

2032. Incorrect synchronization clause of async function

Section: 30.6.8 [futures.async] Status: New Submitter: Alberto Ganesh Barbati Opened: 2011-02-17 Last modified: 2011-02-21

View all other issues in [futures.async].

View all issues with New status.

Discussion:

Clause 30.6.8 [futures.async] has undergone significant rewording in Batavia. Due to co-presence of at least three different sources of modification there is a part where changes have overlapped (marked by an Editor's note), which should be reconciled. Moreover, I believe that a few non-overlapping sentences are now incorrect and should be fixed, so the problem cannot be handled editorially. (See c++std-lib-29667.)

Proposed resolution:

  1. Edit 30.6.4 [futures.state], paragraph 3 as follows.

    An asynchronous return object is an object that reads results from an associated asynchronous state. A waiting function of an asynchronous return object is one that potentially blocks to wait for the associated asynchronous state to be made ready. If a waiting function can return before the state is made ready because of a timeout (30.2.5), then it is a timed waiting function, otherwise it is a non-timed waiting function.

  2. Edit within 30.6.8 [futures.async] paragraph 3 bullet 2 as follows.

    Effects: [...]

    • if policy & launch::deferred is non-zero — [...] The associated asynchronous state is not made ready until the function has completed. The first call to a non-timed waiting function (30.6.4 [futures.state]) requiring a non-timed wait on an asynchronous return object referring to the this associated asynchronous state created by this async call to become ready shall invoke the deferred function in the thread that called the waiting function;. once Once evaluation of INVOKE(g, xyz) begins, the function is no longer considered deferred. [...]
  3. Edit 30.6.8 [futures.async] paragraph 5 as follows.

    Synchronization: Regardless of the provided policy argument,

    • the invocation of async synchronizes with (1.10) the invocation of f. [Note: this statement applies even when the corresponding future object is moved to another thread. —end note]; and
    • the completion of the function f is sequenced before (1.10) the associated asynchronous state is made ready. [Note: f might not be called at all, so its completion might never happen. —end note]

    If policy & launch::async is non-zero, If the implementation chooses the launch::async policy,

    • a call to a waiting function on an asynchronous return object that shares the associated asynchronous state created by this async call shall block until the associated thread has completed, as if joined (30.3.1.5);
    • the join() on the created thread object the associated thread completion synchronizes with (1.10) the return from the first function that successfully detects the ready status of the associated asynchronous state or with the return from the last function that releases the associated asynchronous state returns, whichever happens first. [Editor's note: N3196 changes the following sentence as indicated. N3188 removes the sentence. Please pick one.] If the invocation is deferred, the completion of the invocation of the deferred function synchronizes with the successful return from a call to a waiting function on the associated asynchronous state.

2033. Preconditions of reserve, shrink_to_fit, and resize functions

Section: 23.3.6.3 [vector.capacity], 23.3.3.3 [deque.capacity] Status: New Submitter: Nikolay Ivchenkov Opened: 2011-02-20 Last modified: 2011-02-22

View all other issues in [vector.capacity].

View all issues with New status.

Discussion:

I have several questions with regard to the working paper N3225 (C++0x working draft):

  1. Where the working draft specifies preconditions for shrink_to_fit member function of std::vector and std::deque?

  2. Where the working draft specifies preconditions for 'void reserve(size_type n)' member function of std::vector?

  3. Does a call to 'void resize(size_type sz)' of std::vector require the element type to be DefaultConstructible? If yes, why such requirement is not listed in the Requires paragraph?

  4. Does a call to 'void resize(size_type sz)' of std::vector require the element type to be MoveAssignable because the call erase(begin() + sz, end()) mentioned in the Effects paragraph would require the element type to be MoveAssignable?

  5. Why CopyInsertable requirement is used for 'void resize(size_type sz)' of std::vector instead of MoveInsertable requirement?

Proposed resolution:


2034. Initialization of atomics is misspecified so that it doesn't preserve sequential consistency

Section: 29.3 [atomics.order] Status: New Submitter: Hans Boehm Opened: 2011-02-26 Last modified: 2011-02-28

View other active issues in [atomics.order].

View all other issues in [atomics.order].

View all issues with New status.

Discussion:

This violates the core intent of the memory model, as stated in the note in 1.10 [intro.multithread] p. 21.

This was discovered by Mark Batty, and pointed out in their POPL 2011 paper, "Mathematizing C++ Concurrency", section 4, "Sequential consistency of SC atomics". The problem is quite technical, but well-explained in that paper.

This particular issue was not understood at the time the FCD comments were generated. But it is closely related to a number of FCD comments. It should have arisen from US-171, though that's not the actual history.

This issue has been under discussion for several months in a group that included a half dozen or so of the most interested committee members. The P/R represents a well-considered consensus among us:

Proposed resolution:

Modify 29.3 [atomics.order] p.3, so that the normative part reads:

3 There shall be a single total order S on all memory_order_seq_cst operations, consistent with the "happens before" order and modification orders for all affected locations, such that each memory_order_seq_cst operation that loads a value observes either the last preceding modification according to this order S, A, or the result of an operation X that is not memory_order_seq_cst. Furthermore, if there is a last preceding memory_order_seq_cst modification A, then X must not happen before A. [ Note: Although it is not explicitly required that S include locks, it can always be extended to an order that does include lock and unlock operations, since the ordering between those is already included in the "happens before" ordering. — end note ]


2035. Output iterator requirements are broken

Section: 24.2.4 [output.iterators] Status: New Submitter: Daniel Krügler Opened: 2011-02-27 Last modified: 2011-02-28

View all other issues in [output.iterators].

View all issues with New status.

Discussion:

During the Pittsburgh meeting the proposal N3066 became accepted because it fixed several severe issues related to the iterator specification. But the current working draft (N3225) does not reflect all these changes. Since I'm unaware whether every correction can be done editorial, this issue is submitted to take care of that. To give one example: All expressions of Table 108 — "Output iterator requirements" have a post-condition that the iterator is incrementable. This is impossible, because it would exclude any finite sequence that is accessed by an output iterator, such as a pointer to a C array. The N3066 wording changes did not have these effects.

Proposed resolution:

Modify the column contents of Table 108 — "Output iterator requirements", 24.2.4 [output.iterators], as indicated:

Table 108 — Output iterator requirements (in addition to Iterator)
Expression Return type Operational semantics Assertion⁄note
pre-⁄post-condition
*r = o result is not used   Remark: After this operation
r is not required to be
dereferenceable.
post: r is incrementable.
++r X&   &r == &++r.
Remark: After this operation
r is not required to be
dereferenceable or incrementable.
post: r is incrementable.
r++ convertible to const X& { X tmp = r;
++r;
return tmp; }
Remark: After this operation
r is not required to be
dereferenceable or incrementable.
post: r is incrementable.
*r++ = o result is not used   Remark: After this operation
r is not required to be
dereferenceable or incrementable.
post: r is incrementable.