Re: exception behaviour in containers
On 1 Okt., 19:42, d...@clovermail.net (Daniel) wrote:
[note to moderators: I tried sending this to the newsgroup about 48 hours ago
but I can't see it so I am trying again to the email address]
I can't see any descriptions/guarantees of what should happen if there is an
exception in certain container member functions. I am specifically interested
in copy constructor, assignment operator, and insertion. It seems there are a
few possibilities that could happen:
* unwind any changes and leave the container in the state previous to the
function call
* leave the operation partially complete, some elements copied
* abort leaving the container internal data structure corrupted
As recently explained by David Abrahams in the thread " Standard
library exception specifications might be lacking" found at
http://tinyurl.com/2vqroj
the current standard finished this part a little bit hasty due to time-
limits
and one of the out-comes of the thread was that at least some points
are still open (begin(), iterator::operator+, etc). Regrettably it is
no-where
explicitly written, but the intend of the STL seems to be to provide
at least
the basic safety guarantee. I base this assertion on more recent
attempts
to clarify the exception behaviour of the standard library in upcoming
multi-threading C++ as described in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2410.html
I don't think that the above mentioned copy-c'tor is relevant for the
discussion, because a failing c'tor will prevent the existence of a
to-be-constructed object and thus there is not much to corrupt (or
do you possibly mean the source??). In [container.requirements]/10+11
of the recent draft there are given general statements on insert for
the
single-insertion step (so this is not limited to unordered associative
containers). I think it was considered as too expensive to provide
the
strong guarantee for multi-inserts and if needed is easy to write.
Further-on several containers to give more precise guarantees, e.g.
in [deque.modifiers] or [vector.modifiers]
Greetings from Bremen,
Daniel Kr?gler
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]