Is there any standard/guarantees for exception safety in STL operations?
in [C++]
|
Prev: Is there any standard/guarantees for exception safety in STL operations?
Next: Is there any standard/guarantees for exception safety in STL operations?
From: Howard Hinnant on 24 Jul 2010 23:27 On Jul 24, 9:59 am, Dragan Milenkovic <dra...(a)plusplus.rs> wrote: > > Also, you may describe the concrete problem that bothers you and someone > will most likely provide the most clean and effective way to achieve it. > > Recovery is still possible in the current library, but you have > to do it yourself. Does that count as "reasonably possible"? And people > _do_ care about time and complexity, it's the standard library... should > we all write our own in order to optimize it? You just cannot ask for > something that would ruin the library. Well said. Many people don't realize that it is relatively easy to add features when using a minimal & fast library - making an informed engineering tradeoff between features and performance. But when given a feature- rich library (without access to a low-level API), one can't make it fast when you don't need the features. Doing so is a common mistake in library design: forgetting or dismissing the importance of the low- level layer. -Howard -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Kenneth 'Bessarion' Boyd on 26 Jul 2010 07:48 On Jul 26, 12:45 pm, Mathias Gaunard <loufo...(a)gmail.com> wrote: > It is fairly trivial to write a wrapper of std::vector<T>::insert for > example that provides strong exception safety, so I don't see what you > mean by "there is NO WAY" to do it. > Technique is simple: build another temporary vector, then if all went > well swap (which is nothrow). That technique can be virtually applied > in all cases you'd want to make a primitive strongly exception-safe. At least for C++0X, std::vector<T>::insert is the only insert member function that requires fixing. All of the others are required to at least satisfy the strong exception guarantee anyway([container.requirements.general]/11, plus tracing all four listed exemptions to that). However, per [vector.modifiers]/1 simply doing the insert on the copy and then swapping is not required to make a uniformly strongly exception-safe wrapper for std::vector<T>::insert : we have unspecified behavior for an exception- throwing move constructor of a type that is not copy-constructible. Is the intent there that the strong exception guarantee on such a move constructor will prevent the unspecified behavior? [I haven't verified that the other failures are contained properly by working with a copy, but untrained gut reaction suggests this will otherwise work.] -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Mathias Gaunard on 26 Jul 2010 13:40 On Jul 26, 11:48 pm, "Kenneth 'Bessarion' Boyd" <zaim...(a)zaimoni.com> wrote: > However, per [vector.modifiers]/1 simply > doing the insert on the copy and then swapping is not required to make > a uniformly strongly exception-safe wrapper for > std::vector<T>::insert : we have unspecified behavior for an exception- > throwing move constructor of a type that is not copy-constructible. What move constructor are you talking about? That of the allocator? -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Mathias Gaunard on 26 Jul 2010 14:22 On Jul 26, 11:48 pm, n...(a)cam.ac.uk wrote: > In any case, your statement is false unless the standard > mechanism already provides basic exception safety Which it obviously does. All standard primitives provide basic exception safety, even if that is not worded in a way satisfying to you. Basic exception safety is the lowest guarantee any decent C++ code has to provide. If there were leaks in the standard library, that would be a major bug... > which isn't the > case everywhere, as far as I can see. > > There are several killers. > > The first is 1.3.13 in n3092: "Undefined behaviour may also be > expected when this International Standard omits the description of > any explicit definition of behaviour." As Bjarne's Appendix E > (Standard-Library Exception Safety) shows, there is a very patchy > collection of guarantees. Right. So your point is that the C++ standard library is not well enough specified, which is a defect. If you care enough, why not fix it? I'm not aware, though, of this being in the list of defects, so surely the issue is not acknowledged. In any case, implementers are smart enough to realize their code shouldn't leak even if they're not explicitly specified to. > Related to this is the complexity of the wording, which is a firm > guarantee that some aspects will be missed by almost all programmers, > implementors and even in the standard itself. I am still trying to > track down WHERE it says certain things that experts (like Bjarne > and Howard) have said are specified. Like the "no memory leaks"! Ask them for assistance? > There is also the major problem that a lot of the 'guarantees' are > actually very harsh constraints on the use of the library - e.g. > the number of things that are not allowed to throw, even though > there are potentially unavoidable exceptions in them. What is not allowed to throw? > Related to > this is the implicit restriction that all asynchronous exceptions > are undefined behaviour. That's not realistic, in practice. Just what the hell are you talking about with your asynchronous exceptions? There is no such notion in C++. Code is not interrupted within its execution by exceptions. Exceptions get thrown as part of the normal execution flow. So not throwing any exception in a piece of code means that the piece of code is nothrow, which is the highest guarantee possible: the operation never fails. Asynchronous exceptions that could interrupt any code anywhere *do not exist*. I'm pretty sure std::vector<T>::swap is guaranteed to be nothrow (at least that's what the literature says), and with this you can easily implement any operation in a strongly exception-safe way simply by using a transactional copy-work-swap model. That's not the most efficient way to do it, but it certainly does the job and contradicts your statement "there is no way to do it". > The traditional definition of "exception safety" was that the > behaviour was defined and "reasonable", no matter what raised an > exception - INCLUDING when one was raised asynchronously. As I > said, that might mean that an item might be either inserted or not, > or a sort had part-completed, but those can be used as a basis for > recovery. This is a C++ newsgroup. The definitions assumed of "exception" and "exception-safety" are that of C++. Search for the Abrahams guarantees, which are the de facto reference definitions of what exception-safety is in a C++ context. > A specification that exceptions raised under some circumstances are > safe, but others (equally likely to arise) lead to undefined behaviour > isn't something that I would want to build a high-RAS system on. I'm sorry the C++ standard library does not fulfill all your fault- tolerant wishes. It was meant to be general-purpose, not to be used to build high-RAS systems. Surely you can understand not everyone wants to pay a big overhead for guarantees they care little about. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Michael Kilburn on 27 Jul 2010 06:13
On Jul 26, 12:48 pm, "Alf P. Steinbach /Usenet" <alf.p.steinbach +use...(a)gmail.com> wrote: > * Michael Kilburn, on 18.07.2010 05:24: >> I have checked C++ standard and did not find requirements imposed on >> library implementation with respect to exception safety. > > Have you tried googling for "exception safety in the stl"? > > Disclaimer: I haven't. > > But I believe that was the paper (by Dave Abrahams) where e.g. the term > "strong > guarantee" originated. > > You might also take a look at the third appendix, I believe it was, to > Bjarne Stroustrup's The C++ Programming Language, 3rd edition. Of course! Best thing I found was webpage guarantees provided by good old STLPort. But problem is that it is not a standard. Afair Bjarne did not put much emphasis on these concepts (I reserve the right to be wrong) and common reference is an article written by David Abrahams (one you mentioned). Anyway -- since I am reading standard on regular basis, my point was to find these guarantees there. Which is turned out to be non-trivial task -- whoever was documenting these definitely did not want anyone to find them out... Even though Daniel cleared some fog for me (thanks!), it seems there are still black holes in standard with respect to this. Which for me means "you can't write portable C++ program that uses STL". :-( I can't believe my initial question resulted in such a flame war in parallel branches... Looks like old "you can't implement stack safely in C++" problem. ;-) Thank you, Michael. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |