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

From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2007-12-09 11:34:09

Daniel James skrev:
> Ion Gaztañaga wrote:
>> Thorsten Ottosen wrote:

>>> One thing puzzled me though:
>>> (see http://igaztanaga.drivehq.com/unordered/unordered/comparison.html)
>>>
>>> "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

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.

> 
> One example where they could throw is if the hash function used a 
> numeric type which throws an exception when it overflows (which does 
> suggest a buggy hash function but there you go).

Well, I think it is wrong to allow for incorrect hash-functions. We 
can't really protect against that anyway.

> 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?

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

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? If so, I don't 
see why operator== is any different.

-Thorsten