From: Aristid Breitkreuz (aribrei_at_[hidden])
Date: 2006-10-28 14:29:37
Thanks for the insight!
Am Samstag, den 28.10.2006, 18:07 +0200 schrieb "JOAQUIN LOPEZ MU?Z":
> Hello Aristid,
> Well, I too support the inclusion of standalone TR1-compliant
> unordered containers into Boost, but since you mention
> Boost.MultiIndex hashed indices let me explain how they stand
> in comparison with unordered_[multi]set. The instantiation
> completely replicates the interface and complexity bounds of
> except that insert(const value&) returns a pair<iterator,bool>
> both for hashed_unique and hashed_non_unique indices, while
> unordered_multiset::insert returns an iterator.
Will hashed_non_unique ever return a false second there?
> Due to design constraints, B.MI hashed indices provide the
> following guarantees that are *not* mandated for TR1 unordered
> * Iterator validity is preserved in any case during insertion
> or rehashing: TR1 allows for iterator invalidation when a rehash
> (implicit or explicit) is performed.
> * Erasing an element or range of elements via iterators does not
> throw ever, as the internal hash function and equality predicate
> objects are not actually invoked.
> * rehash provides the strong exception safety guarantee
> unconditionally. TR1 only warrants it if the internal hash
> function and equality predicate objects do not throw.
> These stronger guarantees might result in some performance
> penalties in the area of iterator increment, erase and
> rehash operations, though my measurings lead me to think
> that the actual impact is low or negligible.
Does this imply that implementing TR1 unordered containers on top of
B.MI would not impose a serious performance drawback? The interface is
nearly the same so writing a TR1 compliant wrapper should be ... doable,
And it should be done if it shall be part of 1.35 :-).
PS: I hope 1.34 will come out soon now. (Who doesn't?)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk