Boost logo

Boost :

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 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.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at