Boost logo

Boost :

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2005-02-20 10:21:43


Hi John, thanks for your comments!

----- Mensaje original -----
De: John Maddock <john_at_[hidden]>
Fecha: Sábado, Febrero 19, 2005 6:02 pm
Asunto: Re: [boost] [multi_index][hash][rfc] Hashed indices preview
        +Boost.Hash
[...]
>
> > 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?
>
> Well it's not unreasonable, you need what you need.

BTW, have you read the committee's resolution to this
issue? It doesn't make any sense to me (Bill Wade's concern,
OTOH, seems very rasonable.)
>
> > 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 don't see how you can place it in a detail namespace if users
> are going to
> be expected to (possibly) provide their own specialisations of the
> hash
> function object.
>
> I've no objection to either a fast track review, or just adding to
> cvs,

I think Daniel is going to ask for a fasttrack review, and
Thorsten volunteered to manage it. In the meantime, I'll commit
my update and Boost.Hash code only, and wait for the outcome
of Daniel's review --it'll be his responsabiity to upload
docs, test, etc. if the lib is accepted.

Best,

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk