By the way should this construction v.insert( v.end(), v.begin(), v.end() ); be well-formed? I did not find that it has something as undefined behaviour.
However GCC and MS VC++ 2010 give wrong result for this codestd::vector<std::string> v { "1", "2", "3" };v.insert( v.end(), v.begin(), v.end() );
On Oct 18, 2014, at 4:54 PM, Marc <marc....@gmail.com> wrote:
> [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 valid (again assuming a large enough reserve()) makes it a bit confusing that the first version isn't.
>
> Then we might as well say that vector iterators act as positions, and that after a reallocation-free insertion an iterator points to the same position, whatever may be there now…
With sufficient capacity, all implementations I’m aware of will give you the expected result for your example.
However the C++98/11/14 standards explicit call out this code as undefined behavior. Table 100 — Sequence container requirements, in [sequence.reqmts], has a row:
a.insert(p, i, j)
There is a precondition on this operation that i and j are not iterators into a.