Talk:cpp/container/vector/erase
Effects
I'd change first sentence of the current long and complex explanation of the erase effects:
Iterators and references to the erased elements and to the elements between them and the end of the container are invalidated.
with much shorter and easier to understand as specified in the C++11 standard document:
Invalidates iterators and references at or after the point of the erase.
--Mloskot (talk) 06:47, 22 November 2013 (PST)
Inverted complexity explanation
If I'm right, the complexity description 1) actually refers to the version 2) and viceversa.
139.19.106.205 07:23, 3 August 2014 (PDT) Hernán.
Return value is a valid iterator
I believe the purpose of returning the next iterator is to make it easy to write a correct loop that removes elements as it goes. This is more obvious (and shown in the sample code) for std::map::erase.
Would it be stating the obvious to point out that the returned iterator is from the updated container, and therefore valid? (Is this even guaranteed by the standard? I assume it must be, but, being unfamiliar with the standards docs, I haven't looked it up.)
Would it be making the sample code too verbose to add an example of deleting while iterating?
--CygA (talk) 15:13, 22 September 2017 (PDT)
- a small addition to the example showing the use of the return value would be helpful, I think. --Cubbi (talk) 17:04, 24 September 2017 (PDT)
From the C++11 standard, 23.2.3, note 12 (the C++17 standard says the same):
The iterator returned from a.erase(q) points to the element immediately following q prior to the element being erased. If no such element exists, a.end() is returned.
This seems ambiguous to me. "Prior to the element being erased" probably means "It followed q prior to erasing", but that could technically also be parsed as "The iterator from prior to erasing". I guess it's supposed to be obvious that the returned iterator must be valid and therefore obtained from after erasing? Because why else would an iterator be returned?
