Tries are very fast data structures. Looking up a word takes O(sizeofword) time, while std::map
s are self-balacing trees. Why aren't the standard C++ map templates implemented with tries. Is there any specific reason? Are there any tradeoffs of using a trie instead of a self-balancing tree?

- 362,284
- 104
- 897
- 1,065

- 5,050
- 9
- 45
- 75
-
14How would you use a trie to store something that isn't a string (or at least string-like)? – Oliver Charlesworth Jan 20 '12 at 09:54
-
How do you got the O(n) complexity for trie? – n0rd Jan 20 '12 at 09:54
-
@n0rd: O(n) != O(sizeofword)... – Oliver Charlesworth Jan 20 '12 at 09:55
-
1Tries also have a large memory overhead. – Don Reba Jan 20 '12 at 09:57
-
1@OliCharlesworth pretty much depends on what we choose for `n`. – n0rd Jan 20 '12 at 09:58
-
@n0rd: True! I interpreted "n" as meaning "number of stored elements", though... – Oliver Charlesworth Jan 20 '12 at 09:59
-
@DonReba do they? I would have guessed that, as the keys are spread along the paths, they would have a little memory saving compared with a binary tree where all the keys have to be stored alongside the data. – fortran Jan 20 '12 at 10:10
-
@DonReba: implementation specific. Trie describe more a category (and a principle) than an actual implementation. While dummy implementations have large memory overhead, there are many ways to compress them: Patricia Trie use Path Compression, you need not have as many children as there are variations (think modulo) and you can group the leaves in "buckets". The latter means it is no longer a "pure" Trie, in a sense. – Matthieu M. Jan 20 '12 at 10:12
-
@fortran, a trie needs a large sparse index at every node for the available alphabet or a secondary search. – Don Reba Jan 20 '12 at 10:15
-
@DonReba that is true if the implementation uses some kind of hash-map for every node, but it could use a sorted array, that is very compact and also fast for lookup. – fortran Jan 20 '12 at 10:21
-
@fortran, with sorted arrays you get O(NlogN) time in query length. It is a time/memory tradeoff, as always. – Don Reba Jan 20 '12 at 10:46
-
@OliCharlesworth: You stated that there may be some input that is not a string, can you please cite a example for such a case? – Global Warrior Jan 22 '12 at 05:44
-
@Piyush: The key for a map can be any type you like, so long as you can provide a consistent definition for `<`. – Oliver Charlesworth Jan 22 '12 at 11:24
1 Answers
Tries can only be used when the keys to be stored can be processed digit by digit or character by character. The C++ std::map
and std::set
are designed to work with any comparable elements as keys, and thus can't be implemented in a way that processes the keys character by character. They instead (typically) use balanced binary search trees, which don't need to introspect on the keys and can instead just use a comparator to do fast lookups.
If you know for sure that certain properties hold for your keys, you can in some cases do even better than tries (see the van Emde Boas tree for an example). However, library designers have to design for a lot of use cases and thus may need to pick options that are slower than the absolutely best option because they need to handle the largest possible number of options.
Additionally, it's actually perfectly possible that a conforming C++ implementation contain a specialization of std::map
or std::set
that uses a trie when the keys are strings. I don't believe that any do, but it is in theory possible.
Hope this helps!

- 362,284
- 104
- 897
- 1,065
-
For smaller data sets the balanced-tree is likely more efficient than most common trie implementations. I find the trie really only becomes efficient with larger data sets. – edA-qa mort-ora-y Jan 20 '12 at 12:00