Ok, where is the repo?
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?
I'm interested in each of these. And I have ideas about how to move forward
implementing them. I'd also like to work on applying what we make toward
several already open libraries, by writing some bindings to python and some
other languages. I'm interested in writing some protobuf/capnproto
specifications and some data-type translations between the vernacular too.
Can we discuss a work partitioning and road map to move forward? Are there
any shared documents, like google docs that discuss plans and ideas?
On Thu, Mar 5, 2015 at 12:13 PM, Antony Polukhin
2015-03-05 19:34 GMT+03:00 Kenneth Adam Miller < kennethadammiller@gmail.com> :
Are there any already made outlined plans? Because I need to use a specialized radix tree (or caching trie) for a very highly performance critical task and I was wondering if I could somehow get my code into boost so that the code can be reused. The Trie type itself could be an NVI interface, and the specializations mere exchangable templates.
What do you think?
Boost.Trie is currently not optimized and probably has some issues. Any good suggestions, patches, feature requests and documentation improvements are welcomed. This is an open source, so all you need to do to help - just contact the developers and show the code.
Cosmin Boaca is actively developing the library, so he could probably give you some ideas about stuff that he needs help with.
-- Best regards, Antony Polukhin
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost