This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofTC1 status.
Section: 23.2[container.requirements]Status:TC1Submitter: David VandevoordeOpened: 1998-06-23Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [container.requirements].
View all issues withTC1 status.
Discussion:
The std::sort algorithm can in general only sort a given sequenceby moving around values. The list<>::sort() member on the otherhand could move around values or just update internal pointers. Eithermethod can leave iterators into the list<> dereferencable, butthey would point to different things.
Does the FDIS mandate anywhere which method should be used forlist<>::sort()?
Matt Austern comments:
I think you've found an omission in the standard.
The library working group discussed this point, and there wassupposed to be a general requirement saying that list, set, map,multiset, and multimap may not invalidate iterators, or change thevalues that iterators point to, except when an operation does itexplicitly. So, for example, insert() doesn't invalidate any iteratorsand erase() and remove() only invalidate iterators pointing to theelements that are being erased.
I looked for that general requirement in the FDIS, and, while Ifound a limited form of it for the sorted associative containers, Ididn't find it for list. It looks like it just got omitted.
The intention, though, is that list<>::sort does notinvalidate any iterators and does not change the values that anyiterator points to. There would be no reason to have the memberfunction otherwise.
Proposed resolution:
Add a new paragraph at the end of 23.1:
Unless otherwise specified (either explicitly or by defining a function in terms of other functions), invoking a container member function or passing a container as an argument to a library function shall not invalidate iterators to, or change the values of, objects within that container.
Rationale:
This was US issue CD2-23-011; it was accepted in London but thechange was not made due to an editing oversight. The wording in theproposed resolution below is somewhat updated from CD2-23-011,particularly the addition of the phrase "or change the valuesof"