2449. vector::insert invalidates end()?

Section: 23.3.11.5 [vector.modifiers] Status: NAD Submitter: Marc Glisse Opened: 2014-10-21 Last modified: 2017-03-14

Priority: 3

View all other issues in [vector.modifiers].

View all issues with NAD status.

Discussion:

this issue is based on the discussion here.

23.3.11.5 [vector.modifiers] says about vector::insert: "If no reallocation happens, all the iterators and references before the insertion point remain valid." This doesn't seem to guarantee anything about the iterator at the point of insertion.

The question comes from people asking if the following is valid, assuming a sufficient call to reserve() was done first:

v.insert(v.end(), v.begin(), v.end());

It could fail for an implementation using a sentinel for the end of the vector, but I don't know of any (it would be quite inconvenient). And for any implementation using a simple position as iterator (pointer (possibly in a wrapper), or base+offset), this is needlessly restrictive. The fact that this alternative:

v.insert(v.end(), &v[0], &v[0]+v.size())

is arguably valid (again assuming a large enough reserve()) makes it a bit confusing that the first version isn't (23.2.4 [sequence.reqmts] has a precondition that iterator arguments to insert() do not point into the sequence, but vector::insert is more refined and seems to give enough guarantees that it cannot fail).

Then we might as well say that vector iterators act as positions, and that after a reallocation-free operation an iterator points to the same position, whatever may be there now…

[2017-03-04, Kona]

NAD. The problem description is incorrect; it is a violation of table entry 87 a.insert(p, i, j) - "i and j are not iterators into a".

Proposed resolution: