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

From: David Abrahams (dave_at_[hidden])
Date: 2007-12-11 11:05:26

on Sun Dec 09 2007, Ion Gaztañaga <igaztanaga-AT-gmail.com> wrote:

> Thorsten Ottosen 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.
>
> You are right. The draft says in 23.1 (Container requirements):
>
> 10 Unless otherwise specified (see 23.2.2.3 and 23.2.5.4) all
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> container types defined in this clause meet the following additional
> requirements:
>
> [...]
>
> — no erase(), pop_back() or pop_front() function throws an exception.

So it is "otherwise specified" for vector and deque.

> so the predicate for associative container should not throw, because 
> erase(const key_type &k) can't throw. 

They're unrelated.

> On the other hand, this seems strange. I understand making
> erase(iterator) no-throw, but I find strange making erase(const
> key_type &)don't think the standard wanted to forbid exceptions from
> the predicate. Clearly unordered containers are different:
>
> 23.1.3.1 Exception safety guarantees [unord.req.except]
>
> 1 For unordered associative containers, no clear() function throws an 
> exception. No erase() function throws an exception unless that exception 
> is thrown by the container’s Hash or Pred object (if any).
>
> Why this difference? I hope someone knows the answer ;-)

Because unordered associative containers may rehash when erasing.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com