Re: Is there any standard/guarantees for exception safety in STL operations?
On 20 Jul., 06:45, "Peter C. Chapin" <pcc482...@gmail.com> wrote:
On 2010-07-19 15:51, Daniel Kr?gler wrote:
? if an exception is thrown by an insert() function while
inserting a single element, that function has no effects.
... and what if we are inserting more than one element? what effect(s)
we are going to have?
The above quoted wording was intentionally restricted to the
"one-element" insertion, so this is not incomplete. It was
decided that a type satisfying a container type is not required
to ensure the strong exception guarantee for multiple
element insertions. User-provided container types can easily
strengthen this requirement, if necessary.
The standard explains what happens if an exception is thrown during a
single element insertion, but appears to be silent about the multiple
element case (true?). Okay, so inserting multiple elements does not
provide the strong guarantee, but what sort of guarantee does it
provide?
In non-normative wording: It provides the basic guarantee as described
before. I.e. the state is valid, but unknown.
Is the result UB? Is an implementation permitted to reformat my
hard drive in that case?
The result is *no* UB and there is no valid state that is supposed to
reformat your hard drive.
As mentioned before: The library is in general prepared that user-code
may throw exceptions. It explicitly mentions those situations, where
it may not, e.g. it may never throw exceptions in destructors that
are called within library code (e.g. as part of destroying a
container).
Note how 17.6.3.8/2 (FCD) does specifically mention exception:
"In particular, the effects are undefined in the following cases:
[..]
? for types used as template arguments when instantiating a template
component, if the operations on the type do not implement the
semantics
of the applicable Requirements subclause (20.2.5, 23.2, 24.2, 26.2).
Operations on such types can report a failure by throwing an
exception
unless otherwise specified.
? if any replacement function or handler function or destructor
operation
exits via an exception, unless specifically allowed in the applicable
Required behavior: paragraph.
[..]"
Please note the sentence:
"Operations on such types can report a failure by throwing an
exception
unless otherwise specified"
which is a general statement *including* user-defined types ("types
used
as template arguments").
And please note the follow-up bullet, which makes exceptions leaving
destructors, replacement functions, or handler functions in general
boo-boo (UB) *unless* explicitly allowed. One such explicit allowance
is
that for the handler function for set_unexpected_handler in 15.5.2/3:
"The std::unexpected() function shall not return, but it can throw (or
re-
throw) an exception. [..] If it throws or rethrows an exception that
the
exception-specification does not allow then the following happens: If
the
exception-specification does not include the class std::bad_exception
(18.8.2.1) then the function std::terminate() is called, otherwise
the
thrown exception is replaced by an implementation-defined object of
the type std::bad_exception and the search for another handler will
continue at the call of the function whose exception-specification
was
violated."
or for the replacement forms of the global allocation functions, e.g.
18.6.1.1/3:
"Required behavior: Return a non-null pointer to suitably aligned
storage
(3.7.4), or else throw a bad_alloc exception. This requirement is
binding
on a replacement version of this function."
etc. The conclusion from this is, that a general *throw-allowance* is
given
but the standard does not explicitly say what the state will be after
this
This is not different than saying that the state is "unknown but
valid".
I agree that this last conclusion is only indirect, but IMO the only
reasonable one.
Additional to this "basic exception guarantee" the standard sometimes
requires more by giving additional (stronger) guarantees. These
situations
do typically describe a state that we can informally describe as
"strong
exception guarantee". The only "exception" I found from this rule
(there maybe some others lurking around) during a quick survey of the
FCD is the normative description of forward_list::sort, 23.3.3.5/22:
"Effects: [..] If an exception is thrown the order of the elements in
*this
is unspecified."
IMO it would be better to strike this one, because it doesn't say
anything
new and causes irritations when comparing with the lack of these extra
guarantees.
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]