Re: [boost] [ boost ] [ Trie ]

Subject: Re: [boost] [ boost ] [ Trie ]
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-03-05 13:14:08

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/