http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58153
--- Comment #5 from François Dumont <fdumont at gcc dot gnu.org> --- And your remark is good too and will avoid me to spend some time on this idea. Standard requirements regarding validity of iterators won't let us have iterators invalidated because another iterator is erased, I do not need to challenge it. For information, on my side I was more concerned about how I would represent the past-the-end iterator. Regarding the idea of having an erase_after method, usage of a forward_list data structure for the hashtable implementation is a libstdc++ implementation detail, not a Standard requirement. So Standard committee hasn't design it with such a design decision. Our choice of a forward_list data structure is at the moment the best tradeoff we came too but of course you are free to help us find a better one. Note that I remember having tried to use a doubly linked list when reviewing hashtable implementation but the memory overhead was resulting in worst performance. As you seem to have a lot of equivalent keys in your unordered_multimap<key, value> you should perhaps move to an unordered_map<key, Container<value>>. I even wonder if the libstdc++ profile mode could detect such an opportunity, potentially saying what type of container should be used.
