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: why aren't comparators passed as refs or c-refs in algorithms?
From: Dragan Milenkovic on 30 Jul 2010 10:12 On 07/30/2010 08:54 PM, Bo Persson wrote: > Dragan Milenkovic wrote: [snip] >> This I agree. I do feel uneasy, like there is a hole in >> the specification of std::vector. Me likes things clean >> and strictly defined, yes. Maybe, they should have just >> banned objects that throw on copy/move. >> > > But they didn't want to do that, just because some type can throw once > in a million years. Sorry, I didn't understand this. I hope you are not describing a class whose ctor can throw only rarely... A type can either throw or it can not; chances and probability must be excluded from the logic. But I'm pretty sure this is not what you meant... > It is still allowed to put these objects in a vector, but perhaps you > should avoid multi-object inserts in the middle of the vector, at > times when the risc of an exception is high. :-) > > Or perhaps the application can live with the "consistent but unknown > state" of the vector, by discarding it and letting the higher level > operation fail? Youtube video not loading, please try again! I fully agree that these options _are_ useful. My statement about banning classes that throw on copy/move had only one purpose -- such design would stop people from trashing C++ as the specs would be well defined (and restricted, though). :-P I'm glad to have seen this thread. Some aspects of C++ are now a bit more clear than before. -- Dragan [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: nmm1 on 30 Jul 2010 23:32 In article <i2vb0n$b02$1(a)speranza.aioe.org>, Dragan Milenkovic <dragan(a)plusplus.rs> wrote: >On 07/30/2010 08:54 PM, Bo Persson wrote: >> >>> This I agree. I do feel uneasy, like there is a hole in >>> the specification of std::vector. Me likes things clean >>> and strictly defined, yes. Maybe, they should have just >>> banned objects that throw on copy/move. >> >> But they didn't want to do that, just because some type can >> throw once in a million years. > >Sorry, I didn't understand this. I hope you are not describing >a class whose ctor can throw only rarely... A type can either >throw or it can not; chances and probability must be excluded >from the logic. But I'm pretty sure this is not what you meant... I am pretty sure that he did, and he is right. In engineering, an understanding of exception probability is critical, and real software engineering is what it says. The "computer science" that excludes chance and probability is quite rightly damned as being nothing to do with computing and not a science. >> It is still allowed to put these objects in a vector, but perhaps you >> should avoid multi-object inserts in the middle of the vector, at >> times when the risc of an exception is high. :-) >> >> Or perhaps the application can live with the "consistent but unknown >> state" of the vector, by discarding it and letting the higher level >> operation fail? Youtube video not loading, please try again! > >I fully agree that these options _are_ useful. My statement about >banning classes that throw on copy/move had only one purpose >-- such design would stop people from trashing C++ as the specs >would be well defined (and restricted, though). :-P Many languages have taken the dogmatic "computer science" approach of banning everything that isn't easily and precisely definable, and most of those have quite rightly been "trashed" as ivory tower academic onanism, completely irrelevant to the real world. None have lasted long - for example, there was ONE program written in standard Pascal that ever took off (TeX) - Borland developed a very different language. C++ is no different from almost all other languages in failing to face up to the problem of real exceptions (as distrinct from using exceptions as alternate returns). The reason is that it is a HARD problem, and there is no simple "computer science" solution. What is throughly unhelpful is people treating C++ as a Holy Dogma and damning those who point out serious defects as heretics. And this is an area where it has serious defects, just like almost every other one of the dozens of languages I have used. Heaven help us, there aren't many that do ANY better, and most do worse :-( Whether it is feasible to reduce these defects is less clear; the fact that virtually every other language has not done so is a pretty clear indication of the fundamental difficulty of the problem. Modern Ada claims to do better, but I have never had time to investigate it in detail. Regards, Nick Maclaren. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Bo Persson on 30 Jul 2010 23:36
Dragan Milenkovic wrote: > On 07/30/2010 08:54 PM, Bo Persson wrote: >> Dragan Milenkovic wrote: > [snip] >>> This I agree. I do feel uneasy, like there is a hole in >>> the specification of std::vector. Me likes things clean >>> and strictly defined, yes. Maybe, they should have just >>> banned objects that throw on copy/move. >>> >> >> But they didn't want to do that, just because some type can throw >> once in a million years. > > Sorry, I didn't understand this. I hope you are not describing > a class whose ctor can throw only rarely... A type can either > throw or it can not; chances and probability must be excluded > from the logic. But I'm pretty sure this is not what you meant... I did actually. :-) There are classes that can throw, but you might know in advance that it isn't going to happen today. If might throw for lack of resources, but I know that there are plenty of those resources right now. Then it would be safe to use the class anyway. For an extreme example, say that you have a class that throws an exception, but only on February 29th, if it is a Thursday with a lunar eclipse. Now I know that today it is around July or August in a year that isn't divisible by 4. Should the standard say that I cannot put my class in a std::vector, because it throws exceptions? The library designers chose not to do that, leaving it up to me. Can I live with the effects, or can I tell that nothing bad will happen right now? I agree that the standard isn't a tutorial, but often a rather dry statement of facts. To avoid repetitions, and the risk of contradictions with that, it sometimes only states a certain rule in one place, where it is first needed. Occationally it is not obvious where that place is, but that's how it is. The 1300 pages of the current draft doesn't exacly encourage adding more explanations either. :-) Bo Persson -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |