This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofC++11 status.
Section: 27.4.3.2[string.require]Status:C++11Submitter: Hervé BrönnimannOpened: 2008-06-05Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [string.require].
View all issues withC++11 status.
Discussion:
In March, on comp.lang.c++.moderated, I asked what were thestring exception safety guarantees are, because I cannot see*any* in the working paper, and any implementation I know offersthe strong exception safety guarantee (string unchanged if amember throws exception). The closest the current draft comes tooffering any guarantees is 27.4.3[basic.string], para 3:
The class template
basic_stringconforms to the requirementsfor a Sequence Container (23.1.1), for a Reversible Container (23.1),and for an Allocator-aware container (91). The iterators supported bybasic_stringare random access iterators (24.1.5).
However, the chapter 23 only says, on the topic of exceptions: 23.2[container.requirements],para 10:
Unless otherwise specified (see 23.2.2.3 and 23.2.6.4) all container types defined in this clause meet the following additional requirements:
- if an exception is thrown by...
I take it as saying that this paragraph has *no* implication onstd::basic_string, asbasic_string isn't defined in Clause 23 andthis paragraph does not define a *requirement* of Sequencenor Reversible Container, just of the models defined in Clause 23.In addition, LWG Issue718(i) proposes to remove 23.2[container.requirements], para 3.
Finally, the fact that no operation on Traits should throwexceptions has no bearing, except to suggest (since the onlyother throws should be allocation,out_of_range, orlength_error)that the strong exception guarantee can be achieved.
The reaction in that group by Niels Dekker, Martin Sebor, andBo Persson, was all that this would be worth an LWG issue.
A related issue is thaterase() does not throw. This should bestated somewhere (and again, I don't think that the 23.2[container.requirements], para 1applies here).
[San Francisco:]
Implementors will study this to confirm that it is actually possible.
[Daniel adds 2009-02-14:]
The proposed resolution of paperN2815interacts with this issue (the paper does not refer to this issue).
[2009-07 Frankfurt:]
Move to Ready.
Proposed resolution:
Add a blanket statement in 27.4.3.2[string.require]:
- if any member function or operator of
basic_string<charT, traits, Allocator>throws, that function or operator has no effect.- no
erase()orpop_back()function throws.
As far as I can tell, this is achieved by any implementation. If I made amistake and it is not possible to offer this guarantee, theneither state all the functions for which this is possible(certainly at leastoperator+=,append,assign, andinsert),or add paragraphs to Effects clauses wherever appropriate.