Opened 6 years ago

Closed 6 years ago

#8069 closed Bugs (invalid)

Boost unordered_map iterator bug

Reported by: Karalis Apostolos <tolis@…> Owned by: Daniel James
Milestone: To Be Determined Component: unordered
Version: Boost 1.53.0 Severity: Problem
Keywords: Cc:


The documentation ( 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.

Attachments (1)

main.cpp (2.3 KB) - added by Karalis Apostolos <tolis@…> 6 years ago.

Download all attachments as: .zip

Change History (6)

Changed 6 years ago by Karalis Apostolos <tolis@…>

Attachment: main.cpp added

comment:1 Changed 6 years ago by viboes

Component: Noneunordered
Owner: set to Daniel James

comment:2 Changed 6 years ago by 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.

comment:3 Changed 6 years ago by 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).

comment:4 Changed 6 years ago by 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.

comment:5 Changed 6 years ago by Daniel James

Resolution: invalid
Status: newclosed
Note: See TracTickets for help on using tickets.