Created on 2018-03-19.00:00:00, last changed 2018-06-19.05:49:11.
This wording is relative to N4727.
Edit [forwardlist.ops] as indicated:
void merge(forward_list& x); void merge(forward_list&& x); template<class Compare> void merge(forward_list& x, Compare comp); template<class Compare> void merge(forward_list&& x, Compare comp);
-20- Requires: *this and x are both sorted with respect to the comparator operator< (for the first two overloads) or comp (for the last two overloads), and get_allocator() == x.get_allocator() is true.-21- Effects:
Merges the two sorted ranges [begin(), end()) and [x.begin(), x.end()). x is empty after the merge. If an exception is thrown other than by a comparison there are no effects. Pointers and references to the moved elements of x now refer to those same elements but as members of *this. Iterators referring to the moved elements will continue to refer to their elements, but they now behave as iterators into *this, not into x. -22- Remarks: Stable ([algorithm.stable]). The behavior is undefined if get_allocator() != x.get_allocator(). -23- Complexity: At most distance(begin(), end()) + distance(x.begin(), x.end()) - 1 comparisons .
[ 2018-06-18 after reflector discussion ]
Priority set to 3
LWG 300 changed list::merge to be a no-op when passed *this, but there's no equivalent rule for forward_list::merge. Presumably the forward_list proposal predated the adoption of LWG 300's PR and was never updated for the change. Everything in the discussion of that issue applies mutatis mutandis to the current specification of forward_list::merge.
|2018-06-19 05:49:11||admin||set||messages: + msg9936|
|2018-03-25 13:18:26||admin||set||messages: + msg9783|