|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