on Sun Dec 09 2007, Thorsten Ottosen <thorsten.ottosen-AT-dezide.com> wrote:
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.
No, the ordered containers don't do any predicate evaluation in erase().
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 http://www.boost-consulting.com