This is distinct from flat-out using unordered_map everywhere; I assume that still has library problems.
We have base/containers/hash_tables.h which uses various pre-C++11 hash_map (and hash_set and friends) implementations. But they all have random differences between each other.
1. MSVC hash_map requires a total order on the key[1], so we have to define otherwise unnecessary operator<'s.
2. Mumble mumble rvalue references?? I ran into this monster [2] trying to get ssl_session_cache_openssl.cc building on Windows. I wasn't able to get it working, but I'm not familiar with rvalue references. Switching to unordered_map made the error go away, so I didn't dig further.
3. std::hash and MSVC provide a hash for T* just hashes the pointer value. __gnu_cxx::hash does not. See [3] where we define the hash on COMPILER_GCC, but not COMPILER_MSVC. (There's lots of them.)
4. C++11 does not specialize hash<const char*>. so it's still the pointer value. As far as I can tell, both __gnu_cxx::hash and MSVC's stdext::hash_value specialize to hash the C string, despite their default comparisons comparing by pointer equality (!!?!?). [4] is the case I found in Chromium. It seems to want the pointer version anyway.
I propose we align all the behaviors around C++11 semantics in advance of actually switching to unordered_map. On MSVC, just use unordered_map. Others, continue to use what we have right now, but replace the default hash with one that matches C++11[5].
Thoughts?
[5] I was going to suggest we go to std::tr1::unordered_map on other platforms, but stlport is a problem. Looking at the headers, it has std::tr1::unordered_map, but the hash looks like the pre-standard one.