hash_map vs unordered_map

[marek.vondrak]

Hi,
I am wondering if there are any functional differences between SGI's
hash_map and tr1's unordered_map. Can these two containers be
interchanged? What would it take to switch from hash_map to
unordered_map? Thank you.
-Marek

 

[Leandro Melo]

Hi,
I am wondering if there are any functional differences between SGI's
hash_map and tr1's unordered_map. Can these two containers be
interchanged? What would it take to switch from hash_map to
unordered_map? Thank you.

Hi.

It's not clear to me what exactly is your doubt. Just like SGI's
hash_map the "new" unordered_map is also based on a hash table. Since
hash_map (and hash_set, hash_multimap, hash_multiset) is not standard,
several compilers have provided their own implementation (GCC's for
example is based on SGI's hash map). Usually the implementation
differs in some aspect, even related to the interface (including the
template parameters), and are located in an extended namespace.

There're implementations of TR1 with support for unordered_map. IIRC
Boost's TR1 lacked this particular data structure (I'm not sure if
it's there yet), but Visual Studio's 2008 feature pack does included
it. You might wanna try one of those so you can check out the
differences.

Well, does this help at all?

 

[marek.vondrak]

It's not clear to me what exactly is your doubt. Just like SGI's
hash_map the "new" unordered_map is also based on a hash table. Since
hash_map (and hash_set, hash_multimap, hash_multiset) is not standard,
several compilers have provided their own implementation (GCC's for
example is based on SGI's hash map).

Right. GCC provides SGI style hash_map under the name
__gnu_cxx::hash_map, MSVC with Dinkumware C++ library under the name
stdext::hash_map. The Dinkumware version differs from the SGI's
hash_map in certain minor details, but wrappers can be written so that
it would behave as SGI's hash_map. Now, my question is if the same
thing can be easily done with unordered_map, such that the wrapper
would have the same external interface like SGI's hash_map and provide
same guarantees about iterator invalidations, etc. I have an existing
code base that assumes that there is a class ext::hash_map that has
the semantics of SGI hash_map and that maps either to
__gnu_cxx::hash_map, SGI's hash_map, STLPort's hash_map or a wrapper
around stdext::hash_map. I would like to extend this so it could be
mapped to tr1::unordered_map as well.

-Marek