On 5 Mar 2015 at 12:15, Kenneth Adam Miller wrote:
Cosmin: Are you open to the idea of having the trie act as a container and sort of adopt a superset of the operations that work on traditional STL containers?
Are you open to the idea of having the trie be parameterizable with concurrency strategies? With value strategies that can even be an additional data structures?
Are you open to the idea of having one specialization that is highly optimized for integer keys, with separate implementations for x32/x64?
There is one of these already at https://github.com/ned14/nedtries. I wouldn't recommend using its STL container implementation, but its C macro/C++ template implementation is plenty sound and very mature. If the concurrent unordered map GSoC goes well, it will be followed by a concurrent map GSoC (extension) which internally is based on concurrent bitwise tries. These are vastly faster under concurrent modification than red black trees, and still provide excellent concurrency given a good key hash function. None of these are a proper full fat trie container implementation, but then in my own code I don't need that right now, I need concurrent maps ordered and unordered. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/