[boost] Re: [repost][multi_index][hash][rfc] Hashed indices preview+ Boost.Hash

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-02-16 08:57:14

|There are a number of things we'd like to ask you feedback about:
|
|1. Hashed indices are modeled according to the latest TR1 draft, with
|some significant diversions:
|1.1. erase() does not throw ever, even it the user-provided Hash object
|throws. This is imposed by the general framework of Boost.MultiIndex.
|This goodie does not come for free: if the Hash object throws, erase()
|decays to a linear search. Not that there's any alternative, but I'd
|like
|to point it out.

seems ok. an exception should not occur very often.

|1.2. insert() has strong exception safety (TR1 only requires basic.)
|Again, the way Boost.MultiIndex is designed forces this.

seems ok.

|1.3. hash indices iterators are bidirectional.

seems ok.

|1.4. Usual implementations use one pointer per bucket, whereas
|Boost.MultiIndex has two pointers per bucket. This addresses potential
|performance problems of insert() and erase() under low load conditions,
|as discussed in
|http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1756.pdf
|issue 6.14. Is this convenient?

|6. Yet, this hasn't undergone any formal review, so some of you might
|(with reason) object to its being commited to the CVS. From our point
|of view, we have three valid alternatives:
|  * Boost members agree to have it in CVS without more ado.
|  * As this is used by Boost.MultiIndex, Boost.Hash is suitable for
|  fasttrack review.
|  * This is untolerable and the library should be push_back()'ed to
|  the review queue. Meanwhile, Boost.Hash should live as an impl
|  detail of Boost.MultiIndex.

I would prefer a fast-track review. I think we have plenty of room
in between reviews. If you need a fast-track review manager, then
I don't mid doing so.

-Thorsten