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