[ann]Fast_lookup - first snapshot available
First snapshot of the to-be proposed Fast_lookup library is available for download at the vault. Direct link (watch for line breaks!): http://boost-sandbox.sourceforge.net/vault/index.php?&order= &directory=fast_lookup Sorry, no documentation as of yet. Fast_lookup provides "sorted vector"-based versions of standard associative containers, thus embracing the common practice. Highlights of this release: * map and set have been implemented * Two different storage policies - 'default' and KeepKeysSeparate, which is usually faster, but takes more memory * Out-of-the-box support for Boost.Serialization I haven't done any significant optimizations yet, but the performance tests are in, and they show that we are in pretty good shape(compared to Loki::AssocVector). Fast_lookup currently does not work on vc6 though I've made some initial stabs at this problem. Since I'm going on vacation starting from this Friday, the next snapshot will likely be posted in August. Planned features include multiset and multimap + indirect storage(some parts of pointer_containers library will be probably reused) Any suggestions, comments, feature requests or critique are welcome.
"Mikhail Glushenkov" <bbman@mail.ru> wrote in message news:loom.20050609T001915-758@post.gmane.org... | First snapshot of the to-be proposed Fast_lookup library is available | for download at the vault. | Direct link (watch for line breaks!): | http://boost-sandbox.sourceforge.net/vault/index.php?&order= | &directory=fast_lookup | Sorry, no documentation as of yet. | | Fast_lookup provides "sorted vector"-based versions of standard associative | containers, thus embracing the common practice. | | Highlights of this release: | * map and set have been implemented | * Two different storage policies - 'default' and KeepKeysSeparate, which is | usually faster, but takes more memory | * Out-of-the-box support for Boost.Serialization | Any suggestions, comments, feature requests or critique are welcome. I don't have much to say apart from that I'm looking forward to the library. Sometimes people critisize std::set/map for using a predicate to sort the elements. Maybe it could be possible (either by default or by policies) to use -1,0,1 comparison instead (if it has a speed advantage). I think Gabriel Dos Reis has some more problems with std::set, but I have forgotten them now. Keep up the good work! :-) -Thorsten
Jonathan Turkanis <technews <at> kangaroologic.com> writes:
Thorsten Ottosen wrote:
I think Gabriel Dos Reis has some more problems with std::set, but I have forgotten them now.
There's the question of whether you should trust the user to modify elements
in
a set.
Standard says that that set::iterator may be the same type as set::const_iterator. In Fast_lookup this behaviour is enabled only in debug mode by default.
Mikhail Glushenkov wrote:
Jonathan Turkanis <technews <at> kangaroologic.com> writes:
Thorsten Ottosen wrote:
I think Gabriel Dos Reis has some more problems with std::set, but I have forgotten them now.
There's the question of whether you should trust the user to modify elements in a set.
Standard says that that set::iterator may be the same type as set::const_iterator.
I'm mentioning ways people have said the standard could be improved.
In Fast_lookup this behaviour is enabled only in debug mode by default.
Why have different behavior in debug mode? Jonathan
"Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message news:d88m89$g6g$1@sea.gmane.org... | "Mikhail Glushenkov" <bbman@mail.ru> wrote in message | news:loom.20050609T001915-758@post.gmane.org... || Fast_lookup provides "sorted vector"-based versions of standard associative || containers, thus embracing the common practice. || || Highlights of this release: || * map and set have been implemented || * Two different storage policies - 'default' and KeepKeysSeparate, which is || usually faster, but takes more memory || * Out-of-the-box support for Boost.Serialization | || Any suggestions, comments, feature requests or critique are welcome. | | I don't have much to say apart from that I'm looking forward to the library. When I think about it, it would also be nice if you coudl control when you use something similar to boost::ptr_vector<T> for holding the objects. For big objects, this would be faster. Also, for a map it can really mean al lot performance wise if you donøt have to construct before its needed. Something like value& fast_map::lazy_insert( something_conparable_and-convertible_to_the_key_type& r ); think of word-counting with strings: fast_map<string,unsigned> m; sub_range<string> s = ...; m.laze_insert(s)++; br -Thorsten
On Wed, 8 Jun 2005 22:26:26 +0000 (UTC) Mikhail Glushenkov <bbman@mail.ru> wrote:
Sorry, no documentation as of yet.
Any suggestions, comments, feature requests or critique are welcome.
I think you need some docs, if you want even a minimal number of people to actually look at it.
Jody Hagins <jody-boost-011304 <at> atdesk.com> writes:
On Wed, 8 Jun 2005 22:26:26 +0000 (UTC) Mikhail Glushenkov <bbman <at> mail.ru> wrote:
Sorry, no documentation as of yet.
Any suggestions, comments, feature requests or critique are welcome.
I think you need some docs, if you want even a minimal number of people to actually look at it.
OK, I'll keep that in mind next time. I just wanted to post something before I go on vacation.
participants (4)
-
Jody Hagins -
Jonathan Turkanis -
Mikhail Glushenkov -
Thorsten Ottosen