Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2007-12-11 11:02:37

on Sun Dec 09 2007, Thorsten Ottosen <> wrote:

> Daniel James skrev:
>> Ion Gaztañaga wrote:
>>> Thorsten Ottosen wrote:
>>>> One thing puzzled me though:
>>>> (see
>>>> "The containers hash or predicate function can throw exceptions from erase"
>>>> This migth be what the standard requires, but it certainly seems
>>>> non-intuitive. Why not just require that neither hash nor predicates can
>>>> throw?
>>> The same could be said about Predicate for ordered containers like
>>> std::set/map. I haven't seen a practical case where the comparison could
>>> throw. But standard library experts should answer this better than me.
> Well, the table at
> 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.

No, the ordered containers don't do any predicate evaluation in

>> Another is that the
>> data required to evaluate the hash function or check for equality is
>> expensive and is lazily evaluated. For example, if you had a class which
>> represents file, and based your equality test on calculating the SHA-1
>> signature then you might only calculate it when required - which could
>> be a call to the hash or equality function.
> 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?

It might be cached data that is later thrown out, or stored on disk.

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

Why should it? Vector/deque erase don't.

> Does erase give the strong guarantee otherwise?
> Since erase(const Key&) for ordered containers cannot throw, so I guess
> it is implicitly required that Pred(x,y) must not throw?

Nope, see above.

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at