Boost logo

Boost :

From: Wyss, Felix (FelixW_at_[hidden])
Date: 2004-01-02 22:08:58


I think it would be better to mandate that resize()
  1) guarantees iterators remain valid
  2) provides the strong exception guarantee

This pretty much requires storing the hash code in the buckets, which in
my opinion is very favorable anyway. In practice, the average runtime
memory usage of such a hash table can actually be lower, as running the
hash table with a higher load factor incurs only a negligible
performance penalty.

Felix

> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> On Behalf Of David Abrahams
> Sent: Friday, January 02, 2004 20:47
> To: boost_at_[hidden]
> Subject: [boost] Re: N1456 Hash table implementation
>
> Jeremy Maitin-Shepard <jbms_at_[hidden]> writes:
>
> > David Abrahams <dave_at_[hidden]> writes:
> >
> >> Jeremy Maitin-Shepard <jbms_at_[hidden]> writes:
> >>> The behavior of rehash in the case that an exception is thrown by
the
> >>> hash function is not specified in the proposal. In this
> >>> implementation, if an exception is thrown by a hash function
during a
> >>> rehash operation, the hash table is cleared. This appears to be
> better
> >>> behavior than leaving the container in state where it contains an
> >>> arbitrary set of elements.
> >
> >> Why is that better? It seems overconstrained to me.
> >
> > I have a hard time seeing what a user would do with the remaining
> > elements other than erase them.
>
> Shouldn't that be up to the user? If the user wants to terminate()
> the program immediately, should she have to pay for the erasure
> anyway?
>
> Why is an cleared hash table any more useful than any other state it
> might end up in?
>
> > Also, if the elements are not
> > cleared, there are three possibilities for choosing which set of
> > elements to include: the elements in the existing buckets, the
elements
> > in the new buckets, or the largest set of elements.
>
> Or some unspecified set of elements. It doesn't really matter.
>
> --
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>


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