From: Ion GaztaÃ±aga (igaztanaga_at_[hidden])
Date: 2007-12-09 16:58:47
Thorsten Ottosen wrote:
> 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.
You are right. The draft says in 23.1 (Container requirements):
10 Unless otherwise specified (see 126.96.36.199 and 188.8.131.52) all container
types defined in this clause meet the following additional requirements:
â no erase(), pop_back() or pop_front() function throws an exception.
so the predicate for associative container should not throw, because
erase(const key_type &k) can't throw. 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
184.108.40.206 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 ;-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk