Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p><code>pop_back</code> is usually defined in terms of <code>erase(end()-1, end())</code>.</p> <p>When you erase a range of iterators from a vector, all iterators from the first erased and forward are invalidated. This includes a range of one.</p> <p>In general, a valid derefencable non input iterator always refers to the same data 'location' until it becomes invalidated. In the case of <code>erase</code>, all non-invalid iterators afterwards have the same value <em>and</em> location currently.</p> <p>Both of the above rules would have to be amended to get the behavior you want. The first to something like 'unless you erase the last element in so doing, in which case the first erased element becomes the one-past-the-end iterator'. And the still valid iterator will become not dereferencable, a possibly unique state change for an iterator that is, as far as I know, without precedent in C++.</p> <p>The cost is both extra tricky verbage in the standard to cover your requested behavior and sanity checks for strict iterators. The benefit -- well, I do not see one: in every situation you will have to know exactly what just happened (a very particular iterator just became one past the end instead of being invalidated), and if you know that is the case you could just talk about <code>end</code>.</p> <p>And words are required. When you call <code>erase( a, b )</code>, every iterator from <code>a</code> on will have its state changed in some way (<code>*a</code> will not return the same value, and how that changes must be specified). C++ takes the easy way, and simply states that every iterator whose state is changed by <code>erase</code> becomes invalid, and using it is undefined behavior: this allows the maximium latitude to the implementer.</p> <p>In theory, it can also allow for optimizations. If you dereference an iterator before and after an <code>erase</code> operation, the value you get can be considered the same! (assuming no possible indirect modification of the container within object destructors, which can be proven as well).</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload