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

### 2449. `vector::insert` invalidates `end()`?

Section: 24.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.

24.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 (24.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: