Boost unordered_map iterator bug

[Karalis Apostolos <tolis@…>]

The documentation (http://www.boost.org/doc/libs/1_53_0/doc/html/boost/unordered_map.html) states that mapped_type& operator[](key_type const& k) function can invalidate iterators, but only if the insert causes the load factor to be greater to or equal to the maximum load factor.

In particular, this does not happen. I have written a simple test for this. I compare boost::unordered_map with std::tr1::unordered_map. The former does not guarantuees that iterators are still valid if the insert DOES NOT cause the load factor to be greater to or equal to the maximum load factor.

I run tests with g++4.7.2 and boost 1.53.

[Daniel James]

The iterator is still valid, it's pointing at '0' which is the last element in the container, so your loop only prints out that element. Try printing out all the elements and you can see that the '0' comes last. Remember that these are unordered containers, so there's no guarantee that they'll have any particular order.

[Karalis Apostolos <tolis@…>]

Thanks for the reply.

I don't expect unordered map (keys) following a specific order. I thought that if i insert into an unordered map (e.g int->int) the pairs 0->5, 4->3, 6->9, 2->0 and before the insert of the pair 6->9 take the iterator of map[4 ] then after the insertion of the last pair, i can print out map[4 ], map[6 ] and map[2 ] using the operator ++. This is very useful in case of large unordered maps and multithreading (one thread inserts/looksup elements and another one checks every x seconds (the next) y map's elements, not simultaneously).

[Steven Watanabe]

You're assuming that the order of the elements in the container is the same as the insertion order. This is not the case. map[6] and map[2] could just as easily appear before map[4] when iterating over the container and in fact, as Daniel stated, this is what is happening in your test case.