Apparently, the way std::remove( in <algorithm> ) works is that it pushed the unwanted elements to the front and changes the end() iterator position. I tried
to see the removed elements and i succeeded with an overflow. Why do you think the implemented it that way ? why didn't the implement std::remove in such a way that it invalidates the iterators after the removal ?
std::remove can't change the size of a container. not all containers can change their size, array for example. If you need to actually delete something from the container, and the container has the ability to do that. Then you can use the remove erase idiom.
Apparently, the way std::remove( in <algorithm> ) works is that it pushed the unwanted elements to the front
It moves valid elements to the front and returns new (logical) end.
As Yanson said, remove operattes on iterators, which does not store information about container and methods and avaliability of erasing, so this part you should do manually.
Elements "after the new end" are in unspecified state, it is not guaranteed to be elemnts removed: http://coliru.stacked-crooked.com/a/b344e47b2d50d214 (modified Yanson example). For more complex classes those extra elements usually moved-from and therefore unusable (only thing you can safely do with them is to destroy or assign new value)
> why didn't the implement std::remove in such a way that it invalidates the iterators after the removal ?
Iterators pointing to an element between the new logical end and the physical end of the range are still dereferenceable, but the elements themselves have unspecified values.
A call to remove is typically followed by a call to a container's erase method.