TrieContact: A Contact Book Built Like an Autocomplete Engine
How a dual-trie C++ design turns names and numbers into two different search problems, then stores each one for the fastest possible lookup.
- TrieContact is interesting because it organizes contact data around prefix search first, not around a generic record list.
- Its asymmetric dual-trie design gives names flexibility and phone numbers speed by matching each structure to the data it stores.
- Exact lookup is handled separately from prefix traversal, which keeps autocomplete fast without making retrieval awkward.
- The project trades memory for responsiveness, which is a sensible choice when the product goal is instant search feedback.
What Kind of Contact Book Is This?
TrieContact is not really a contact book in the usual sense. It is a prefix engine that happens to store contacts. That difference matters, because the whole system is organized around the question, what should happen the moment a user starts typing?
Most contact apps optimize for exact retrieval. TrieContact optimizes for the first few characters. That pushes the design toward tries, autocomplete, and instant suggestions instead of the more familiar database or hash-map approach.
Why Two Tries, Not One
This is the project’s best idea. Names and phone numbers look similar at the UI layer, but they are different search domains. Names need flexibility. Phone numbers need strict, tiny branching over a fixed alphabet of ten digits.
| Approach | Prefix search | Exact lookup | Memory footprint | Complexity |
|---|---|---|---|---|
| Flat list | Slow linear scan | Slow linear scan | Low | Very low |
| Hash map | Poor for prefixes | Fast | Moderate | Low |
| Single generic trie | Fast | Needs extra plumbing | Moderate to high | Moderate |
| TrieContact | Fast for names and numbers | Fast through maps | High | Higher |
The name trie and the number trie solve different problems
The name trie uses a map-backed child set, which gives it flexibility for richer character input. That choice is slower than a fixed array, but it avoids baking in a narrow alphabet. The number trie uses a 10-way array, which is exactly what digits want.
That asymmetry is the point. TrieContact does not insist on one elegant abstraction for both fields. It picks the structure that fits each data type, then keeps them synchronized.
struct triename {
map<char, struct triename*> namechild;
int isleaf;
};
struct trienum {
struct trienum* numchild[10];
int isleaf;
};
void insertcontact(string& name, string& number) {
// write into both tries and both maps
}
Inside the Insert Path
Insertion is where the design becomes concrete. One contact is written into the name trie, the number trie, and the exact-lookup maps that bridge them. That means every contact exists in multiple places for different kinds of queries.
This is why the repo feels more like a search system than a notebook. A single write creates several lookup paths, and each path is optimized for a different user intent: prefix completion, exact match, or reverse lookup.
| Lookup need | Best structure in TrieContact | Why it wins |
|---|---|---|
| Name prefix | Name trie | Flexible branching supports richer character sets |
| Number prefix | Number trie | Ten fixed children give predictable digit traversal |
| Exact name to number | nametonum map | Direct access without walking a trie |
| Exact number to name | numtoname map | Inverse lookup is immediate |
The Memory Trade-Off Nobody Can Ignore
Speed is not free here. The project stores the same contact in two tries and two maps, so memory cost rises fast. That is the bargain TrieContact makes in exchange for instant-feeling search.
For a small contact manager, that trade-off is reasonable. For a huge address book, it would start to hurt. The design is honest about its priorities: responsiveness first, compactness second.
What the Repo Says About Its Builder
The codebase looks like a compact C++ project built in a competitive-programming or student workflow. A single source file, <bits/stdc++.h>, and a bundled Windows executable all point to a builder who values directness over ceremony.
That context helps explain the shape of the project. It is not trying to be a polished platform. It is trying to prove an idea clearly: if you treat contact lookup like search, the data structure changes with it.
The Bottom Line
TrieContact is a neat reminder that product thinking starts with behavior, not storage. If users want autocomplete, build for autocomplete. If names and numbers behave differently, do not force them through the same pipe.
The repo’s real value is conceptual. It shows how a small CLI tool can still have a sharp architecture when the data model mirrors the user’s query model.
