Collaboration diagram for SymbolMap:
It's very small and fast if most/all of the Symbols are being mapped (but it would be poor for a very sparse mapping).
A mapping to Symbol::NULL is the same as no mapping.
I can imagine a cluster of SymbolMaps which would NOT have the "one SymbolTable" restriction, but would have a vector for each SymbolTable used. To avoid hashtable overhead, that cluster would probably use the SymbolTableNumbers, so it would grow with the number of SymbolTables in the process.
Alternatively, you could easily support a small number of SymbolTables with linear-time access, which is decent for the normal case of one or two symbol tables. Maybe a SymbolMap2.
Definition at line 28 of file SymbolMap.h.
we want to know what SymbolTable will be used.
If you don't know yet, you can use hungry mode (below).