Re: [boost] [review] Review of Unordered library begins today December 7

From: Daniel James (daniel_james_at_[hidden])
Date: 2007-12-09 12:13:50

On 09/12/2007, Thorsten Ottosen <thorsten.ottosen_at_[hidden]> wrote:
>
> Well, the table at
>
> http://igaztanaga.drivehq.com/unordered/unordered/comparison.html
>
> says that erase() does not throw for ordered containers (which is
> correct). Anyway, this means any argument used to assume that predicate
> evaluation is a no-throw should be the same for unordered containers.

comp.std.c++ would be the place to discuss logical inconsistencies in
the standard.

> > Another is that the
> > data required to evaluate the hash function or check for equality is
> > expensive and is lazily evaluated. [....]
>
> yes, but would the lazy evaluation be done when inserting the object in
> the first place, thus not leaving it any lazy evaluation when calling erase?

Maybe the data is cached, not memoized and is no longer present during
the erase. This might happen if it's expensive to store. Anyway, I'm
just trying to provide hypothetical examples of hash functions which
throw - not justify the decision. Having said that, it would be
bizarre to allow the hash function to throw in insert and not in
erase. How would it know?

> Why does erase( const_iterator ) (and range version), not provide the
> no-throw guarantee?

Because that's what the standard says... Perhaps I'm being pedantic in
my reading, the intent might have been that the hash function is never
called during those overloads of erase.

This implementation actually does provide the no throw guarantee. But
Jeremy Maitin-Shepard's version (on which it is based) didn't because
the iterators didn't store the bucket, and required the hash to be
calculated to work out which bucket the elements to be deleted are in.
Which I think the standard allows.

> Does erase give the strong guarantee otherwise?

Exceptions are only allowed from the hash or predicate objects. So no
throw if they are no throw.

> Since erase(const Key&) for ordered containers cannot throw, so I guess
> it is implicitly  required that Pred(x,y) must not throw? If so, I don't
> see why operator== is any different.

Because the different parts of the standard were written at different
times by different people? I can only speculate.

Daniel