Revised 2013-09-03 at 13:09:31 UTC

Tentative Issues


2078. Throw specification of async() incomplete

Section: 30.6.8 [futures.async] Status: Tentatively NAD Editorial Submitter: Nicolai Josuttis Opened: 2011-08-29 Last modified: 2012-11-14

View other active issues in [futures.async].

View all other issues in [futures.async].

View all issues with Tentatively NAD Editorial status.

Discussion:

The current throw specification of async() does state:

-6- Throws: system_error if policy is launch::async and the implementation is unable to start a new thread.

First it seems not clear whether this only applies if policy equals launch::async of if the async launch mode flag is set (if policy|launch::async!=0)

In the discussion Lawrence Crowl also wrote:

More generally, I think what we want to say is that if the implementation cannot successfully execute on one of the policies allowed, then it must choose another. The principle would apply to implementation-defined policies as well.

Peter Sommerlad:

Should not throw. That was the intent. "is async" meat exactly.

[2012, Portland: move to Tentatively NAD Editorial]

If no launch policy, it is undefined behavior.

Agree with Lawrence, should try all the allowed policies. We will rephrase so that the policy argument should be lauch::async. Current wording seems good enough.

We believe this choice of policy statement is really an editorial issue.

Proposed resolution:


2085. Wrong description of effect 1 of basic_istream::ignore

Section: 27.7.2.3 [istream.unformatted] Status: Tentatively Ready Submitter: Krzysztof Zelechowski Opened: 2011-09-11 Last modified: 2013-05-21

View other active issues in [istream.unformatted].

View all other issues in [istream.unformatted].

View all issues with Tentatively Ready status.

Discussion:

27.7.2.3 [istream.unformatted] in N3242 currently has the following to say about the semantics of basic_istream::ignore:

[..]. Characters are extracted until any of the following occurs:

This statement, apart from being slightly ungrammatical, indicates that if (n == numeric_limits<streamsize>::max()), the method returns without extracting any characters.

The description intends to describe the observable behaviour of an implementation in terms of logical assertions. Logical assertions are not "bullets" that can be "entered" but need not; they are predicates that can evaluate to true or false.

The description contains two predicates, either of them causes extraction to terminate. In the incriminated case, the first predicate is evaluates to true because its premise is false, therefore no characters will be extracted.

The intended semantics would be described by the following statement:

[..]. Characters are extracted until any of the following occurs:

[2013-04-20, Bristol]

Resolution: Ready.

Proposed resolution:

This wording is relative to the FDIS.

Change 27.7.2.3 [istream.unformatted] p25 as indicated:

basic_istream<charT,traits>&
  ignore(streamsize n = 1, int_type delim = traits::eof());

-25- Effects: Behaves as an unformatted input function (as described in 27.7.2.3 [istream.unformatted], paragraph 1). After constructing a sentry object, extracts characters and discards them. Characters are extracted until any of the following occurs:


2087. iostream_category() and noexcept

Section: 27.5 [iostreams.base] Status: Tentatively Ready Submitter: Nicolai Josuttis Opened: 2011-09-22 Last modified: 2013-05-21

View all other issues in [iostreams.base].

View all issues with Tentatively Ready status.

Discussion:

In <system_error> we have:

const error_category& generic_category() noexcept;
const error_category& system_category() noexcept;

In <future> we have:

const error_category& future_category() noexcept;

But in <ios> we have:

const error_category& iostream_category();

Is there any reason that iostream_category() is not declared with noexcept or is this an oversight?

Daniel:

This looks like an oversight to me. We made the above mentioned changes as part of noexcept-ifying the thread library but iostream_category() was skipped, so it seems to be forgotten. There should be no reason, why it cannot be noexcept. When doing so, we should also make these functions noexcept (similar to corresponding overloads):

error_code make_error_code(io_errc e);
error_condition make_error_condition(io_errc e);

Suggested wording provided by Daniel.

[2013-04-20, Bristol]

Unanimous.

Resolution: move to tentatively ready.

Proposed resolution:

This wording is relative to the FDIS.

  1. Change 27.5.1 [iostreams.base.overview], header <ios> synopsis as indicated:

    #include <iosfwd>
    namespace std {
      […]
      error_code make_error_code(io_errc e) noexcept;
      error_condition make_error_condition(io_errc e) noexcept;
      const error_category& iostream_category() noexcept;
    }
    
  2. Change the prototype declarations in 27.5.6.5 [error.reporting] as indicated:

    error_code make_error_code(io_errc e) noexcept;
    

    -1- Returns: error_code(static_cast<int>(e), iostream_category()).

    error_condition make_error_condition(io_errc e) noexcept;
    

    -2- Returns: error_condition(static_cast<int>(e), iostream_category()).

    const error_category& iostream_category() noexcept;
    

    -3- Returns: A reference to an object of a type derived from class error_category.

    -4- The object’s default_error_condition and equivalent virtual functions shall behave as specified for the class error_category. The object’s name virtual function shall return a pointer to the string "iostream".


2125. TimedMutex specification problem

Section: 30.4.1.3 [thread.timedmutex.requirements], 30.4.1.3.1 [thread.timedmutex.class] Status: Tentatively NAD Editorial Submitter: Vicente J. Botet Escriba Opened: 2012-01-01 Last modified: 2012-11-14

View all other issues in [thread.timedmutex.requirements].

View all issues with Tentatively NAD Editorial status.

Discussion:

30.4.1.3.1 [thread.timedmutex.class] says:

The class timed_mutex shall satisfy all of the TimedMutex requirements (30.4.1.3 [thread.timedmutex.requirements]). It shall be a standardlayout class (Clause 9 [class]).

Problem here is that 30.4.1.3 [thread.timedmutex.requirements] does not define a requirement set named "TimedMutex", it only refers to "timed mutex types"

[See also issue 2126]

[2012, Portland: move to Tentatively NAD Editorial]

We have timed mutex type, but it is labeled timed mutex requirements

We can make a suggestion, but will send to the editor as it seems purely editorial. There is a typo, and we don't have the timed mutex but 30.4.1.3 [thread.timedmutex.requirements] already says timed mutex type, and we need to reuse that term down in the class to fulfil the mutex requirement.

[To Editor:]

Replace this one with timed mutex type.

Proposed resolution:


2126. Several specification problems in regard to mutex requirements

Section: 30.4.1 [thread.mutex.requirements], 30.4.1.2.1 [thread.mutex.class], 30.4.1.2 [thread.mutex.requirements.mutex], 30.4.1.2.2 [thread.mutex.recursive], 30.4.1.3 [thread.timedmutex.requirements], 30.4.1.3.1 [thread.timedmutex.class], 30.4.1.3.2 [thread.timedmutex.recursive] Status: Tentatively NAD Editorial Submitter: Pete Becker Opened: 2012-01-16 Last modified: 2012-11-14

View all other issues in [thread.mutex.requirements].

View all issues with Tentatively NAD Editorial status.

Discussion:

30.4.1.2.1 [thread.mutex.class]/3 says that the class mutex "shall satisfy all the Mutex requirements (30.4.1 [thread.mutex.requirements])". 30.4.1.2.1 [thread.mutex.class] is part of 30.4.1 [thread.mutex.requirements], so at the very least, this requirement is recursive. But worse, there is nothing that says what "the Mutex requirements" refers to. For example, the "Lockable requirements" section starts with "A type L meets the Lockable requirements if …". There is no such statement for "the Mutex requirements".

Organizationally, paragraphs 1-26 in 30.4.1.2 [thread.mutex.requirements.mutex] should probably be in a subclause with a name. (This is actually an ISO requirement, to avoid exactly this kind of ambiguous referencing) Then the first sentence of 30.4.1.2.1 [thread.mutex.class]/3 can become a note: "The class mutex meets the requirements of (whatever)", since that subclause already says that the mutex types "shall meet the requirements set out in this section."

And similarly for 30.4.1.2.2 [thread.mutex.recursive]/2 (recursive_mutex).

30.4.1.3 [thread.timedmutex.requirements], Timed mutex types, also needs the same rearrangement: its introductory requirements should be moved into a subclause, and the first sentences of 30.4.1.3.1 [thread.timedmutex.class]/2 and 30.4.1.3.2 [thread.timedmutex.recursive]/2 should be turned into notes that refer to this new subclause and to the new subclause in 30.4.1.2 [thread.mutex.requirements.mutex].

[See also issue 2125]

[2012, Portland: move to Tentatively NAD Editorial]

Seems no real ambiguity. May need some reorg of text rather then changing the wording.

Is there much that needs to be changed? But Pete's suggestion of putting requirement in separate sub section is good. Should be the direction to editor.

Suggest this is an editorial change. Happy with Pete's comments.

Proposed resolution:


2131. Member function getline taking a string as parameter

Section: 27.7.2.3 [istream.unformatted] Status: Tentatively NAD Submitter: Loïc Joly Opened: 2012-03-05 Last modified: 2013-05-21

View other active issues in [istream.unformatted].

View all other issues in [istream.unformatted].

View all issues with Tentatively NAD status.

Discussion:

I think the following code should be legal:

void f(std::istream& is)
{
  std::string s;
  is.getline(s); // Would be equivalent to std::getline(is, s)
}

[2013-04-20, Bristol]

Unanimous that this is a new feature request and not a issue.

Resolution: Tentatively NAD

Proposed resolution:

This wording is relative to N3376.

  1. Change the class template basic_istream synopsis, 27.7.2.1 [istream], as indicated

    namespace std {
      template <class charT, class traits = char_traits<charT> >
      class basic_istream : virtual public basic_ios<charT,traits> {
      public:
        […]
        // 27.7.2.3 Unformatted input:
        […]
        basic_istream<charT,traits>& getline(char_type* s, streamsize n);
        basic_istream<charT,traits>& getline(char_type* s, streamsize n,
          char_type delim);
        template<class Allocator>
        basic_istream<charT,traits>& getline(basic_string<charT,traits,Allocator>& str);
        template<class Allocator>
        basic_istream<charT,traits>& getline(basic_string<charT,traits,Allocator>& str,
          char_type delim);
        […]
      };
    }
    
  2. Insert the following two new prototype descriptions after 27.7.2.3 [istream.unformatted] paragraph 24:

    basic_istream<charT,traits>& getline(char_type* s, streamsize n);
    

    -24- Returns: getline(s,n,widen('\n'))

    template<class Allocator>
    basic_istream<charT,traits>& getline(basic_string<charT,traits,Allocator>& str);
    

    -??- Returns: std::getline(*this, str)

    template<class Allocator>
    basic_istream<charT,traits>& getline(basic_string<charT,traits,Allocator>& str, char_type delim);
    

    -??- Returns: std::getline(*this, str, delim)


2134. Redundant Mutex requirement?

Section: 30.4.1.2 [thread.mutex.requirements.mutex] Status: Tentatively NAD Editorial Submitter: Pete Becker Opened: 2012-03-05 Last modified: 2012-11-14

View all other issues in [thread.mutex.requirements.mutex].

View all issues with Tentatively NAD Editorial status.

Discussion:

30.4.1.2 [thread.mutex.requirements.mutex]/11 says that prior unlock operations synchronize with m.lock().

30.4.1.2 [thread.mutex.requirements.mutex]/19 says that if m.try_lock() succeeds, prior unlock operations synchronize with the operation.

30.4.1.2 [thread.mutex.requirements.mutex]/25 says that m.unlock() synchronizes with subsequent successful lock operations.

Does the third requirement add anything to the first two? If not, it should probably be a non-normative note.

[2012, Portland: move to Tentatively NAD Editorial]

Agree that third note should be non-normative and adds nothing.

Seems An Editorial change, but does changing a normative to non-normative wording makes it a non-editorial change?

Ask the editor. If not editorial, then we will agree on the fix as removal of the third point, then we will put it in ready state for Bristol.

Proposed resolution:


2143. ios_base::xalloc should be thread-safe

Section: 27.5.3 [ios.base] Status: Tentatively Ready Submitter: Alberto Ganesh Barbati Opened: 2012-03-14 Last modified: 2013-05-21

View all other issues in [ios.base].

View all issues with Tentatively Ready status.

Discussion:

The static function ios_base::xalloc() could be called from multiple threads and is not covered by 17.6.4.10 [res.on.objects] and 17.6.5.9 [res.on.data.races]. Adding a thread-safety requirement should not impose a significant burden on implementations, as the function can be easily implemented with hopefully lock-free atomics.

[2013-04-20, Bristol]

Unanimous.

Resolution: move tentatively ready. (Inform Bill about this issue.)

Proposed resolution:

This wording is relative to N3376.

  1. In 27.5.3.5 [ios.base.storage] add a new paragraph after paragraph 1:

    static int xalloc();
    

    -1- Returns: index ++.

    -?- Remarks: Concurrent access to this function by multiple threads shall not result in a data race (1.10 [intro.multithread]).


2150. Unclear specification of find_end

Section: 25.2.6 [alg.find.end] Status: Tentatively Ready Submitter: Andrew Koenig Opened: 2012-03-28 Last modified: 2013-05-21

View all issues with Tentatively Ready status.

Discussion:

25.2.6 [alg.find.end] describes the behavior of find_end as returning:

The last iterator i in the range [first1,last1 - (last2 - first2)) such that for any nonnegative integer n < (last2 - first2), the following corresponding conditions hold: *(i + n) == *(first2 + n), pred(*(i + n), *(first2 + n)) != false.

Does "for any" here mean "for every" or "there exists a"? I think it means the former, but it could be interpreted either way.

Daniel: The same problem exists for the following specifications from Clause 25 [algorithms]:

  1. 25.2.13 [alg.search] p2 and p6
  2. 25.3.10 [alg.reverse] p4
  3. 25.3.13 [alg.partitions] p5 and p9
  4. 25.4 [alg.sorting] p5
  5. 25.4.2 [alg.nth.element] p1
  6. 25.4.3.1 [lower.bound] p2
  7. 25.4.3.2 [upper.bound] p2
  8. 25.4.7 [alg.min.max] p21 and p23

[2013-04-20, Bristol]

Unanimous agreement on the wording.

Resolution: move to tentatively ready

Proposed resolution:

This wording is relative to N3376.

  1. Change 25.2.6 [alg.find.end] p2 as indicated:

    template<class ForwardIterator1, class ForwardIterator2>
    ForwardIterator1 
    find_end(ForwardIterator1 first1, ForwardIterator1 last1,
             ForwardIterator2 first2, ForwardIterator2 last2);
    template<class ForwardIterator1, class ForwardIterator2,
             class BinaryPredicate>
    ForwardIterator1
    find_end(ForwardIterator1 first1, ForwardIterator1 last1,
             ForwardIterator2 first2, ForwardIterator2 last2,
             BinaryPredicate pred);
    

    […]

    -2- Returns: The last iterator i in the range [first1,last1 - (last2 - first2)) such that for anyevery nonnegative integer n < (last2 - first2), the following corresponding conditions hold: *(i + n) == *(first2 + n), pred(*(i + n), *(first2 + n)) != false. Returns last1 if [first2,last2) is empty or if no such iterator is found.

  2. Change 25.2.13 [alg.search] p2 and p6 as indicated:

    template<class ForwardIterator1, class ForwardIterator2>
    ForwardIterator1
    search(ForwardIterator1 first1, ForwardIterator1 last1,
           ForwardIterator2 first2, ForwardIterator2 last2);
    template<class ForwardIterator1, class ForwardIterator2,
             class BinaryPredicate>
    ForwardIterator1
    search(ForwardIterator1 first1, ForwardIterator1 last1,
           ForwardIterator2 first2, ForwardIterator2 last2,
           BinaryPredicate pred);
    

    […]

    -2- Returns: The first iterator i in the range [first1,last1 - (last2-first2)) such that for anyevery nonnegative integer n less than last2 - first2 the following corresponding conditions hold: *(i + n) == *(first2 + n), pred(*(i + n), *(first2 + n)) != false. Returns first1 if [first2,last2) is empty, otherwise returns last1 if no such iterator is found.

    […]

    template<class ForwardIterator, class Size, class T>
    ForwardIterator
    search_n(ForwardIterator first, ForwardIterator last, Size count,
             const T& value);
    template<class ForwardIterator, class Size, class T,
             class BinaryPredicate>
    ForwardIterator
    search_n(ForwardIterator first, ForwardIterator last, Size count,
             const T& value, BinaryPredicate pred);
    

    […]

    -6- Returns: The first iterator i in the range [first,last-count) such that for anyevery non-negative integer n less than count the following corresponding conditions hold: *(i + n) == value, pred(*(i + n),value) != false. Returns last if no such iterator is found.

  3. Change 25.3.10 [alg.reverse] p4 as indicated:

    template<class BidirectionalIterator, class OutputIterator>
    OutputIterator
    reverse_copy(BidirectionalIterator first,
                 BidirectionalIterator last, OutputIterator result);
    

    […]

    -4- Effects: Copies the range [first,last) to the range [result,result+(last-first)) such that for anyevery non-negative integer i < (last - first) the following assignment takes place: *(result + (last - first) - i) = *(first + i).

  4. Change 25.3.13 [alg.partitions] p5 and p9 as indicated:

    template<class ForwardIterator, class Predicate>
    ForwardIterator
    partition(ForwardIterator first,
              ForwardIterator last, Predicate pred);
    

    […]

    -5- Returns: An iterator i such that for anyevery iterator j in the range [first,i) pred(*j) != false, and for anyevery iterator k in the range [i,last), pred(*k) == false.

    […]

    template<class BidirectionalIterator, class Predicate>
    BidirectionalIterator
    stable_partition(BidirectionalIterator first,
                     BidirectionalIterator last, Predicate pred);
    

    […]

    -9- Returns: An iterator i such that for anyevery iterator j in the range [first,i), pred(*j) != false, and for anyevery iterator k in the range [i,last), pred(*k) == false. The relative order of the elements in both groups is preserved.

  5. Change 25.4 [alg.sorting] p5 as indicated:

    -5- A sequence is sorted with respect to a comparator comp if for anyevery iterator i pointing to the sequence and anyevery non-negative integer n such that i + n is a valid iterator pointing to an element of the sequence, comp(*(i + n), *i) == false.

  6. Change 25.4.2 [alg.nth.element] p1 as indicated:

    template<class RandomAccessIterator>
    void nth_element(RandomAccessIterator first, RandomAccessIterator nth,
                     RandomAccessIterator last);
    template<class RandomAccessIterator, class Compare>
    void nth_element(RandomAccessIterator first, RandomAccessIterator nth,
                     RandomAccessIterator last, Compare comp);
    

    -1- After nth_element the element in the position pointed to by nth is the element that would be in that position if the whole range were sorted. Also for anyevery iterator i in the range [first,nth) and anyevery iterator j in the range [nth,last) it holds that: !(*i > *j) or comp(*j, *i) == false.

  7. Change 25.4.3.1 [lower.bound] p2 as indicated:

    template<lass ForwardIterator, class T>
    ForwardIterator
    lower_bound(ForwardIterator first, ForwardIterator last,
                const T& value);
    template<class ForwardIterator, class T, class Compare>
    ForwardIterator
    lower_bound(ForwardIterator first, ForwardIterator last,
                const T& value, Compare comp);
    

    […]

    -2- Returns: The furthermost iterator i in the range [first,last] such that for anyevery iterator j in the range [first,i) the following corresponding conditions hold: *j < value or comp(*j, value) != false.

  8. Change 25.4.3.2 [upper.bound] p2 as indicated:

    template<lass ForwardIterator, class T>
    ForwardIterator
    upper_bound(ForwardIterator first, ForwardIterator last,
                const T& value);
    template<class ForwardIterator, class T, class Compare>
    ForwardIterator
    upper_bound(ForwardIterator first, ForwardIterator last,
                const T& value, Compare comp);
    

    […]

    -2- Returns: The furthermost iterator i in the range [first,last] such that for anyevery iterator j in the range [first,i) the following corresponding conditions hold: !(value < *j) or comp(value, *j) == false.

  9. Change 25.4.7 [alg.min.max] p21 and p23 as indicated:

    template<class ForwardIterator>
    ForwardIterator min_element(ForwardIterator first, ForwardIterator last);
    template<class ForwardIterator, class Compare>
    ForwardIterator min_element(ForwardIterator first, ForwardIterator last,
                                Compare comp);
    

    -21- Returns: The first iterator i in the range [first,last) such that for anyevery iterator j in the range [first,last) the following corresponding conditions hold: !(*j < *i) or comp(*j, *i) == false. Returns last if first == last.

    […]

    template<class ForwardIterator>
    ForwardIterator max_element(ForwardIterator first, ForwardIterator last);
    template<class ForwardIterator, class Compare>
    ForwardIterator max_element(ForwardIterator first, ForwardIterator last,
                                Compare comp);
    

    -23- Returns: The first iterator i in the range [first,last) such that for anyevery iterator j in the range [first,last) the following corresponding conditions hold: !(*i < *j) or comp(*i, *j) == false. Returns last if first == last.


2167. Copy assignment requirements of Containers

Section: 23.2.1 [container.requirements.general] Status: Tentatively NAD Submitter: Dean Michael Berris Opened: 2012-07-13 Last modified: 2012-11-14

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

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

View all issues with Tentatively NAD status.

Discussion:

Table 96 defines the general requirement for copy assignment (row 23, page 704) as:

Table 96 — Container requirements
Expression Return type Operational semantics Assertion/note pre-/post-condition Complexity
r = a X& post: r == a. linear

However there is no requirement that T is CopyInsertable into X.

[2012, Portland: Move to Tentatively NAD]

Howard notes that this may be a difficult requirement for std::array

We already have this requirement for allocator aware containers, and std::array already adds the appropriate extra requirement.

We say the necessary things in the necessary places, but the container requirements continue to cause confusion in where we sometimes say things. Consensus is that this issue remains NAD though.

Proposed resolution:

This wording is relative to N3376.

  1. Change Table 96 — "Container requirements" in 23.2.1 [container.requirements.general]:

    Table 96 — Container requirements
    Expression Return type Operational semantics Assertion/note pre-/post-condition Complexity
    r = a X& Requires: T is CopyInsertable into X.
    post: r == a.
    linear

2180. Exceptions from std::seed_seq operations

Section: 26.5.7.1 [rand.util.seedseq] Status: Tentatively Ready Submitter: Daniel Krügler Opened: 2012-08-18 Last modified: 2013-05-21

View all other issues in [rand.util.seedseq].

View all issues with Tentatively Ready status.

Discussion:

26.5.7.1 [rand.util.seedseq] p1 says upfront:

No function described in this section 26.5.7.1 [rand.util.seedseq] throws an exception.

This constraint seems non-implementable to me when looking especially at the members

template<class T>
seed_seq(initializer_list<T> il);

template<class InputIterator>
seed_seq(InputIterator begin, InputIterator end);

which have the effect of invoking v.push_back() for the exposition-only member of type std::vector (or its equivalent) over all elements of the provided range, so out-of-memory exceptions are always possible and the seed_seq object doesn't seem to be constructible this way.

In addition to the potential lack-of-resources problem, the operations of InputIterator might also throw exceptions.

Aside to that it should me mentioned, that a default constructor of vector<uint_least32_t> in theory can also throw exceptions, even though this seems less of a problem to me in this context, because such an implementation could easily use a different internal container in seed_seq that can hold this no-throw exception guarantee.

Secondly, a slightly different problem category related to exceptions occurs for the member templates

template<class RandomAccessIterator>
void generate(RandomAccessIterator begin, RandomAccessIterator end);

template<class OutputIterator>
void param(OutputIterator dest) const;

where the actual operations performed by the implementation would never need to throw, but since they invoke operations of a user-provided customization point, the overall operation, like for example

copy(v.begin(), v.end(), dest);

could also throw exceptions. In this particular example we can just think of a std::back_insert_iterator applied to a container that needs to allocate its elements used as the type for OutputIterator.

Even though Clause 26 [numerics] has mostly stronger exception constraints than other parts of the library the here discussed are overrestrictive, especially since no operation of std::seed_seq except the template generate is actually needed within the library implementation, as mentioned in the discussion of LWG 2124.

I suggest to remove the general no-exception constraints for operations of std::seed_seq except for member size() and the default constructor and to provide specific wording for generate() and param() to ensure that the algorithm itself is a nothrow operation, which is especially for generate() important, because the templates specified in 26.5.3 [rand.eng] and 26.5.4 [rand.adapt] also depend on this property indirectly, which is further discussed in LWG 2181.

Howard:

I suggest to use a different form for the exception specification, something similar to 20.10.9.1.3 [func.bind.bind] p4:

Throws: Nothing unless an operation on RandomAccessIterator throws an exception.

Daniel:

The currently suggested "what and when" form seems a bit more specific and harmonizes with the form used for function template generate_canonical from 26.5.7.2 [rand.util.canonical].

[2013-04-20, Bristol]

Open an editorial issue on the exception wording ("Throws: What and when").

Solution: move to tentatively ready.

Proposed resolution:

This wording is relative to N3376.

  1. Edit 26.5.7.1 [rand.util.seedseq] p1 as indicated:

    -1- No function described in this section 26.5.7.1 [rand.util.seedseq] throws an exception.

  2. Edit 26.5.7.1 [rand.util.seedseq] around p2 as indicated:

    seed_seq();
    

    -2- Effects: Constructs a seed_seq object as if by default-constructing its member v.

    -?- Throws: Nothing.

  3. Edit 26.5.7.1 [rand.util.seedseq] around p7 as indicated:

    template<class RandomAccessIterator>
      void generate(RandomAccessIterator begin, RandomAccessIterator end);
    

    -7- Requires: RandomAccessIterator shall meet the requirements of a mutable random access iterator (Table 111) type. Moreover, iterator_traits<class RandomAccessIterator>::value_type shall denote an unsigned integer type capable of accommodating 32-bit quantities.

    -8- Effects: Does nothing if begin == end. Otherwise, with s = v.size() and n = end - begin, fills the supplied range [begin, end) according to the following algorithm […]

    -?- Throws: What and when RandomAccessIterator operations of begin and end throw.

  4. Edit 26.5.7.1 [rand.util.seedseq] around p9 as indicated:

    size_t size() const;
    

    -9- Returns: The number of 32-bit units that would be returned by a call to param().

    -??- Throws: Nothing.

    -10- Complexity: constant time.

  5. Edit 26.5.7.1 [rand.util.seedseq] around p11 as indicated:

    template<class OutputIterator>
      void param(OutputIterator dest) const;
    

    -11- Requires: OutputIterator shall satisfy the requirements of an output iterator (Table 108) type. Moreover, the expression *dest = rt shall be valid for a value rt of type result_type.

    -12- Effects: Copies the sequence of prepared 32-bit units to the given destination, as if by executing the following statement:

    copy(v.begin(), v.end(), dest);
    

    -??- Throws: What and when OutputIterator operations of dest throw.


2194. Impossible container requirements for adaptor types

Section: 23.6 [container.adaptors] Status: Tentatively Ready Submitter: Sebastian Mach Opened: 2012-10-05 Last modified: 2013-05-21

View all other issues in [container.adaptors].

View all issues with Tentatively Ready status.

Discussion:

The stack class template does not have an member type iterator, and therefore instantiations do not meet the general container requirements as described in 23.2.1 [container.requirements.general]. But 23.6.1 [container.adaptors.general] p1 says:

The headers <queue> and <stack> define the container adaptors queue, priority_queue, and stack. These container adaptors meet the requirements for sequence containers.

Since sequence containers is a subset of general containers, this imposes requirements on the container adaptors that are not satisfied.

Daniel Krügler: The wording change was performed as an editorial reorganization as requested by GB 116 occuring first in N3242, as a side-effect it does now make the previous implicit C++03 classification to [lib.sequences]/1 more obvious. As the NB comment noticed, the adaptors really are not sequences nor containers, so this wording needs to be fixed. The most simple way to realize that is to strike the offending sentence.

[ Daniel adds concrete wording. ]

[2013-04-20, Bristol]

Unanimous consensus that queue and stack are not meant to be sequences.

Decision: move to tentatively ready

Proposed resolution:

This wording is relative to N3376.

  1. Change 23.6.1 [container.adaptors.general] p1 as indicated:

    -1- The headers <queue> and <stack> define the container adaptors queue, priority_queue, and stack. These container adaptors meet the requirements for sequence containers.


2204. reverse_iterator should not require a second copy of the base iterator

Section: 24.5.1.3.4 [reverse.iter.op.star] Status: Tentatively NAD Submitter: David Abrahams Opened: 2012-10-30 Last modified: 2013-05-21

View all issues with Tentatively NAD status.

Discussion:

This note in 24.5.1.3.4 [reverse.iter.op.star]/2:

[ Note: This operation must use an auxiliary member variable rather than a temporary variable to avoid returning a reference that persists beyond the lifetime of its associated iterator. (See 24.2.) —end note ]

is incorrect because such iterator implementations are ruled out by 24.2.5 [forward.iterators]/6, where it says:

If a and b are both dereferenceable, then a == b if and only if *a and *b are bound to the same object.

[[2013-04-20, Bristol]]

Alisdair: sugested to strike the "exposition only" member.

Daniel: we must check that it wouldn't conflict with a previous solution to another issue.

Dietmar: This is an issue but the proposing word is not correct. When we have proxies inside the sequence.

Solution: NAD thanks to a contrieved example by Dietmar.

Proposed resolution:

Strike the note, 24.5.1.3.4 [reverse.iter.op.star]/2:

[ Note: This operation must use an auxiliary member variable rather than a temporary variable to avoid returning a reference that persists beyond the lifetime of its associated iterator. (See 24.2.) —end note ]