Boost logo

Boost :

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 and 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
different: 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, gregod at, cpdaniel at, john at