unordered-map

I want to declare : std::unordered_map<CString, CString> m_mapMyMap; But when I build I got an error telling me that the standard C++ doesn't provide a hash function for CString, while CString have the (LPCSTR) operator. How do I properly implement a hash function for CString? Based on the MS STL implementation for std::string I created the following methods which can be used for std::unordered_set and std::unordered_map : namespace std { template <> struct hash<CString> { // hash functor for CString size_t operator()(const CString& _Keyval) const { // hash _Keyval to size_t value by

For both std::map and std::tr1::unordered_map , I see from the standard that: References to elements in the unordered_map container remain valid in all cases, even after a rehash. How are they doing that ( implementation-wise )? Are they maintaining all the entries as a kind of linked list and then the hash-table just stores pointers to the elements? Yes, linked lists are involved, although not quite in the way you suggest. The 2011 standard says (23.2.5 para 8), "The elements of an unordered associative container are organized into buckets. Keys with the same hash code appear in the same

I need to create a lookup function where a (X,Y) pair corresponds to a specific Z value. One major requirement for this is that I need to do it in as close to O(1) complexity as I can. My plan is to use an unordered_map. I generally do not use a hash table for lookup, as the lookup time has never been important to me. Am I correct in thinking that as long as I built the unordered_map with no collisions, my lookup time will be O(1)? My concern then is what the complexity becomes if there the key is not present in the unordered map. If I use unordered_map::find():, for example, to determine

I've read a lot about unordered_map (c++11) time-complexity here at stackoverflow, but I haven't found the answer for my question. Let's assume indexing by integer (just for example): Insert/at functions work constantly (in average time), so this example would take O(1) std::unordered_map<int, int> mymap = { { 1, 1}, { 100, 2}, { 100000, 3 } }; What I am curious about is how long does it take to iterate through all (unsorted) values stored in map - e.g. for ( auto it = mymap.begin(); it != mymap.end(); ++it ) { ... } Can I assume that each stored value is accessed only once (or twice or

I know how to use std::unordered_map::emplace , but how do I use emplace_hint ? Neither cplusplus nor cppreference provide a set of examples that illustrate how we might know where to put the element. Can anyone provide some information on this or give some examples / illustrations of when we might know where the emplaced element should go? What could an unordered_map potentially do with the hint? Well, if the iterator addresses an element with the same key as the element that emplace_hint has been asked to insert, then it can fail quickly - just a key comparison without any hashing or groping

I want to use tuple consisting of int , char , char in my unordered_map . I am doing like this: #include <string> #include <unordered_map> #include <cstring> #include <iostream> #include <tuple> using namespace std; tuple <int,char,char> kk; unordered_map<kk,int> map; int main() { map[1,"c","b"]=23; return 0; } but this gives me following errors: map.cpp:9:21: error: type/value mismatch at argument 1 in template parameter list for ‘template<class _Key, class _Tp, class _Hash, class _Pred, class _Alloc> class std::unordered_map’ map.cpp:9:21: error: expected a type, got ‘kk’ map.cpp:9:21: error

I am very confused by the name 'unordered_map'. The name suggests that the keys are not ordered at all. But I always thought they are ordered by their hash value. Or is that wrong (because the name implies that they are not ordered)? Or to put it different: Is this typedef map<K, V, HashComp<K> > HashMap; with template<typename T> struct HashComp { bool operator<(const T& v1, const T& v2) const { return hash<T>()(v1) < hash<T>()(v2); } }; the same as typedef unordered_map<K, V> HashMap; ? (OK, not exactly, STL will complain here because there may be keys k1,k2 and neither k1 < k2 nor k2 < k1.