I realize that std::unordered_map doesn't make strong promises about its ordering. But it has to make SOME promises to make basic functionalitiy work.

For example, see the example in - and

My situation is nearly identical, except that I'm using std::unordered_map in a 'copy-on-write' (COW) situation, where under some circumstances, code iterating over a container might need to clone that container, and keep iterating.

This appears to work with ALL the containers I've tested, and all STL implementations, EXCEPT for libc++.

I now realize that this ISN'T really guaranteed by the standard, so I've just been getting lucky (at least for my use of std::unordered map.

Some code I would like to work:

unordered_map<int,int> m1  {{1,1},{2,2}};
unordered_map<int,int> m2 = m1;     // is there some portable way to copy so iteration order preserved?
auto                  newI = m1.begin ();
[[maybe_unused]] auto newE = m1.end ();
auto                  oldI = m2.begin ();
[[maybe_unused]] auto oldE = m2.end ();
while (newI != newE) {
    assert (newI->first == oldI->first);    // check items in new list in same order
    ++newI;
    ++oldI;
}
assert (oldI == oldE);  // both end at same time

NOTE - this works with all other (ordered) containers, like vector, and map<>, etc.

Providing a compiler explorer link to facilitate quick testing.

I realize that std::unordered_map doesn't make strong promises about its ordering. But it has to make SOME promises to make basic functionalitiy work.

For example, see the example in https://en.cppreference/w/cpp/container/unordered_map/erase - and https://cplusplus.github.io/LWG/issue2356

My situation is nearly identical, except that I'm using std::unordered_map in a 'copy-on-write' (COW) situation, where under some circumstances, code iterating over a container might need to clone that container, and keep iterating.

This appears to work with ALL the containers I've tested, and all STL implementations, EXCEPT for libc++.

I now realize that this ISN'T really guaranteed by the standard, so I've just been getting lucky (at least for my use of std::unordered map.

Some code I would like to work:

unordered_map<int,int> m1  {{1,1},{2,2}};
unordered_map<int,int> m2 = m1;     // is there some portable way to copy so iteration order preserved?
auto                  newI = m1.begin ();
[[maybe_unused]] auto newE = m1.end ();
auto                  oldI = m2.begin ();
[[maybe_unused]] auto oldE = m2.end ();
while (newI != newE) {
    assert (newI->first == oldI->first);    // check items in new list in same order
    ++newI;
    ++oldI;
}
assert (oldI == oldE);  // both end at same time

NOTE - this works with all other (ordered) containers, like vector, and map<>, etc.

Providing a compiler explorer link to facilitate quick testing.

• c++
• stdunorderedmap

• 7 It's an unordered map. They only guarantee you have order wise is that elements that hash to the same bucket are kept in insertion order. – NathanOliver Commented 2 days ago
• 1 use map instead of unordered_map – Ahmed AEK Commented 2 days ago
• 3 std::unordered_map<int,int> m2 = {m1.begin(), m1.end()}; fails your assert with gcc too Demo :-) – Jarod42 Commented 2 days ago
• 1 Why doesn't a std::map (or perhaps a std::flat_map) work for you? example – Ted Lyngmo Commented 2 days ago
• 1 @lewis Sorry, I was thinking about multi_map. looks like there is zero order guarantees, just that objects that hash the same will be in the same bucket. – NathanOliver Commented 2 days ago

1 Answer 1

This is not yet definitive. But so far it appears the consensus answer is that this isn't possible.

I believe the text of

https://cplusplus.github.io/LWG/issue2356

acknowledges the need for a container object to be traversable, while deleting parts of it which is why the particular requirements on 'erase'. However, the complete lack of ANY guarantees about iteration ordering (no matter how you work at it) for unordered_map (and unordered cousins) - makes them unsuitable libraries if you wish to use COW (copy-on-write) - because containers might need to 'copy' their data while an iteration is proceeding.