Re: [boost] Status of Hash Collections?

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2006-10-28 14:53:18

----- Mensaje original -----
De: Aristid Breitkreuz <aribrei_at_[hidden]>
Fecha: Sábado, Octubre 28, 2006 8:30 pm
Asunto: Re: [boost] Status of Hash Collections?
Para: boost_at_[hidden]
[...] 
> Am Samstag, den 28.10.2006, 18:07 +0200 schrieb "JOAQUIN LOPEZ MU?Z":
[...]
> > multi_index_container<
> >   Value,
> >   indexed_by<
> >     hashed_[non_]unique<identity<Value>,Hash,Pred>
> >   >,
> >   Alloc
> > >
> > 
> > completely replicates the interface and complexity bounds of
> > 
> > unordered_[multi]set<Value,Hash,Pred,Alloc>
> > 
> > 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?

It can return a false if there are additional indices with
uniqueness constraints, hence the pair<iterator,bool> signature.

> > Due to design constraints, B.MI hashed indices provide the
> > following guarantees that are *not* mandated for TR1 unordered
> > containers:
[...]
> > 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,right?

It's certainly doable, but I don't see any reason to follow
this approach given that Daniel James' standalone implementation
available at the vault looks like is completely finished AFAICS.
We only need that Daniel or someone else write the docs
and request a formal review.

> 
> And it should be done if it shall be part of 1.35 :-).
> 
> Aristid Breitkreuz
> 
> PS: I hope 1.34 will come out soon now. (Who doesn't?)

We're close, the regression count is only 47 :)

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo