Issue 1215: list::merge with unequal allocators (original) (raw)

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

1215. list::merge with unequal allocators

Section: 23.3.11.5 [list.ops] Status: C++11 Submitter: Pablo Halpern Opened: 2009-09-24 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [list.ops].

View all issues with C++11 status.

Discussion:

In Bellevue (I think), we passedN2525, which, among other things, specifies that the behavior oflist::splice is undefined if the allocators of the two lists being spliced do not compare equal. The same rationale should apply tolist::merge. The intent of list::merge (AFAIK) is to move nodes from one sorted list into another sortedlist without copying the elements. This is possible only if the allocators compare equal.

Proposed resolution:

Relative to the August 2009 WP,N2857, change 23.3.11.5 [list.ops], paragraphs 22-25 as follows:

void merge(list&& x); template void merge(list&& x, Compare comp);

Requires: both the list and the argument list shall be sorted according to operator< or comp.

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 bycomp; that is, for every iterator i, in the range other than thefirst, the condition comp(*i, *(i - 1)) will befalse.

Remarks: Stable. If (&x != this) the range [x.begin(), x.end()) is empty after the merge. No elements are copied by this operation. The behavior is undefined if this->get_allocator() != x.get_allocator().

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