Re: Is there any standard/guarantees for exception safety in STL operations?
On 21 Jul., 15:04, Michael Kilburn <crusader.m...@gmail.com> wrote:
I'll skip most of the quoting and will try to summarize all these
postings -- so you are saying that:
1) unless explicitly specified otherwise any STL operation provides
basic exception guarantee
While thinking of it: Iterators are a rather underspecified in this
regard. The standard does not say so explicitly, but I think that
a container with iterators that potentially throw exceptions
won't even provide the basic guarantee (in general).
2) there are no cases on unspecified behaviour other than 3 you
mentioned (exception from dtor, replacement and handler functions)
Exceptions from dtor, replacement, and handler functions cause
undefined behaviour, not unspecified behaviour. And: No: I cannot
*promise* you that there is no unspecified behaviour left ;-)
3) there are places where strong guarantee is guaranteed and mentioned
explicitly
This is correct.
Are those point correct?
I cannot provide your any guarantee, especially I cannot give you the
guarantee of completeness. 17.6.4.11 (FCD) lists some further
constraints, e.g. C-functions shall not throw exceptions unless
they are customized by user-provided functions that might throw
(e.g. qsort and bsearch can handle exceptions from the compare
function). But note that handlers provided to atexit which throw
exceptions will provoke terminate.
What are the "replacement and handler functions" -- functors I pass
into std::transform/etc?
No. /Handler functions/ are only those mentioned in 17.6.3.7, i.e.
user-provided function pointers provided to set_unexpected,
set_new_handler, and set_terminate. /Replacement functions/ are
those mentioned in 17.6.3.6, i.e. the user-provided replacements
for global operator new/delete (all forms).
Normal functors may throw what they like (unless specified
elsewhere...)
Would be really nice to have a shortlist of cases where STL gives
strong guarantee. Plus readable explanation for undefined behaviour
cases. It is quite painful to extract this infromation from standard
right now.
I suggest that someone interested writes a book and gets the money
he or she deserves for that - the good thing is: This book will always
require updates ;-)
And this, of course, contributes to current state of things
in industry, where 80% of senior level developers do not know what is
going to happen if while throwing exception another exception gets
produced (I did a lot of interviews lately (not as a candidate :-)))
and host of apps that goes bananaz when something goes wrong (like out
of memory).
I won't deny that the standard as a document is hard to read and
hard to interpret. It's mainly written for technicians that are
supposed
to implement a compiler or a standard library. I also agree that
specifying exception guarantees is not on it's top priority list,
even
though the situation has (slightly) improved over the years.
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! ]