6

The built in maps and sets in C++ libraries (including unordered_map and multimap) requires that the find function (used to lookup a specific element) utilize an iterator for traversing the elements. The C++ reference site claims that looking up elements using these data structures takes on average constant time, much like a regular hash table. But wouldn't an iterator have to traverse the entire list, making this O(n) time on average, before finding the element?

DarkKunai99
  • 105
  • 1
  • 4
  • 13
  • An unordered map is a hash table, looking up the bucket is constant time (not accounting for the time it takes to hash the key). Collisions are generally handled via a simple list. – Chad Aug 23 '14 at 01:25
  • @Chad I'm aware of the unordered map being a hash table and looking up buckets is usually done in constant time. But how do you look up? Do you use the find function? – DarkKunai99 Aug 23 '14 at 07:19

1 Answers1

15

You statement are no true:

  • map, set, multimap and multiset are normally implemented as binary trees (ex: in VS are implemented as Red Black Trees), the find method in this case search the key using the property that in one node the left child is less than the node (according to the comparer) and the right child is greater than the node (according to the comparer). This give O(log n), as required by the standard.
  • In the case of unordered_map and unordered_set are implemented as hash tables, normally implemented as a collection of buckets (ex: std::vector<Bucket>) and the bucket is implemented as a collection of elements of the unordered_map (ex: std::vector<elem> or std::list<elem>), assuming that hashing function is constant time (or excluding the time), the search in this collections is in average constant time O(1) (the hashing give the bucket where the element are placed, if there are few elem in the bucket search between then the target elem). The worst case is when all elements are in the same bucket in this case the search of the target element would need to iterate through all elements in the bucket until found or not (in O(n)). With good hashing function you could increase probability of split evenly enough the elem in the bucket (obtaining the expected constant time).

Note: the find function return a iterator that don't mean that use iterator to search the requested element.

NetVipeC
  • 4,402
  • 1
  • 17
  • 19
  • so the find function does NOT take O(n) time to search? – DarkKunai99 Aug 23 '14 at 19:48
  • 2
    in `unordered_map` and similar, the search could take at most **O(n)** but it's the worst case scenario, normally take **O(1)**, all depend on how well the hash function evenly distribute the element in the buckets (the goal is every bucket have the same numbers of elements, the worst is all the elements are in the same bucket). The more _close_ the actual state of the data structure is to the _best O(1)_ or the _worst O(n)_ case the more close the runtime would be. Normally close to the worst case don't happen much (it would need a combination of really bad hashing function and strange data) – NetVipeC Aug 23 '14 at 20:05