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
|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.
|1.3. hash indices iterators are bidirectional.
|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
|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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk