This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of CD1 status.

300. list::merge() specification incomplete

Section: [list.ops] Status: CD1 Submitter: John Pedretti Opened: 2001-01-23 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [list.ops].

View all issues with CD1 status.


The "Effects" clause for list::merge() ( [list.ops], p23) appears to be incomplete: it doesn't cover the case where the argument list is identical to *this (i.e., this == &x). The requirement in the note in p24 (below) is that x be empty after the merge which is surely unintended in this case.

Proposed resolution:

In [list.ops], replace paragraps 23-25 with:

23 Effects: if (&x == this) does nothing; otherwise, merges the two sorted ranges [begin(), end()) and [x.begin(), x.end()). The result is a range in which the elements will be sorted in non-decreasing order according to the ordering defined by comp; that is, for every iterator i in the range other than the first, the condition comp(*i, *(i - 1)) will be false.

24 Notes: Stable: if (&x != this), then for equivalent elements in the two original ranges, the elements from the original range [begin(), end()) always precede the elements from the original range [x.begin(), x.end()). If (&x != this) the range [x.begin(), x.end()) is empty after the merge.

25 Complexity: At most size() + x.size() - 1 applications of comp if (&x ! = this); otherwise, no applications of comp are performed. If an exception is thrown other than by a comparison there are no effects.

[Copenhagen: The original proposed resolution did not fix all of the problems in [list.ops], p22-25. Three different paragraphs (23, 24, 25) describe the effects of merge. Changing p23, without changing the other two, appears to introduce contradictions. Additionally, "merges the argument list into the list" is excessively vague.]

[Post-Curaçao: Robert Klarer provided new wording.]