Is there any standard/guarantees for exception safety in STL operations?
in [C++]
|
Prev: Iterator-like interface to a collection of unrelated types?
Next: It would be better if unique_ptr were a type modifier?
From: Dragan Milenkovic on 23 Jul 2010 22:59 On 07/23/2010 01:59 AM, Thomas Richter wrote: > Bo Persson wrote: [snip] >> Most of the operations are optimized for the non-throwing case. A lot >> of them can be written in an exception-neutral way, so that any >> exceptions thrown will not have to be catch'ed by the library. If you >> look into the library, there are very few try-catch statements outside >> the stream library. If the library is to report "exception thrown when >> inserting object 42", the exception would first have to be caught, at >> extra cost. > > That's not exactly what I was asking. I don't mind if exception recovery > takes time or is complex, but at least, it should be reasonably possible. > [snip] > > Sure, but maybe I need a different recovery strategy. And then I have > little means of implementing one. That's what I'm saying. How about you check the answer Louis Lavery gave? 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. -- Dragan [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: nmm1 on 24 Jul 2010 23:26
In article <i2dkhc$idh$1(a)speranza.aioe.org>, Dragan Milenkovic <dragan(a)plusplus.rs> wrote: >On 07/23/2010 01:59 AM, Thomas Richter wrote: >> Bo Persson wrote: >[snip] >>> Most of the operations are optimized for the non-throwing case. A lot >>> of them can be written in an exception-neutral way, so that any >>> exceptions thrown will not have to be catch'ed by the library. If you >>> look into the library, there are very few try-catch statements outside >>> the stream library. If the library is to report "exception thrown when >>> inserting object 42", the exception would first have to be caught, at >>> extra cost. >> >> That's not exactly what I was asking. I don't mind if exception recovery >> takes time or is complex, but at least, it should be reasonably possible. >> >> Sure, but maybe I need a different recovery strategy. And then I have >> little means of implementing one. That's what I'm saying. > >How about you check the answer Louis Lavery gave? > >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. That misses the critical point. The library does not specify enough behaviour in most exceptional cases, which means that it is impossible to write portable or reliable recovery code. As I posted, it could do a lot better, WITHOUT comprimising efficiency, but the design, specification and implementation efforts are comparable with what has already been done. Regards, Nick Maclaren. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |