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: Francis Glassborow on 18 Jul 2010 21:01 Michael Kilburn wrote: > On Jul 18, 3:29 pm, Daniel Kr�gler <daniel.krueg...(a)googlemail.com> > wrote: >>> I have checked C++ standard and did not find requirements imposed on >>> library implementation with respect to exception safety. >>> ... >> There exist some very general statements and guarantees, see below. > > Yes, I saw them... the problem is that quite often they are not "very > general" -- they are incomplete! I'll quote an example from those > provided by you: In one sense they are incomplete, but in another they say as much as can be reasonably said and the programmer has to note what is guaranteed. > > >> 5) 23.1/10: >> >> "Unless otherwise specified (see 23.2.1.3 and 23.2.4.3) all >> container types defined in this clause meet the following >> additional requirements: >> � if an exception is thrown by an insert() function while >> inserting a single element, that function has no effects. > > ... and what if we are inserting more than one element? what effect(s) > we are going to have? > What can it say? In general it will not be able to return to the original so if it matters the programmer must adopt a different strategy if exceptions could be thrown and you require a strong guarantee. To require a strong guarantee would impose an unreasonable burden on everyone who does not care or who knows that an exception cannot be thrown. > >> � no swap() function throws an exception unless that exception >> is thrown by the copy constructor or assignment operator of >> the container�s Compare object (if any; see 23.1.2).[..]" > > ... and what is going to happen to the object? If you insist on having a copy ctor or an assignment operator that can throw in the circumstances detailed then it is unreasonable to require a strong guarantee. If this is a problem for the programmer they must adopt a far more expensive (time and resources) option. But it is not reasonable to impose that cost on everyone. > > >> 6) 23.2.1.3/2: >> >> "Notes: If an exception is thrown other than by the copy >> constructor or assignment operator of T there are no effects." > > ... and what if it is thrown by assignment operator? See above. Note that most copy ctors and copy assignments do not throw. I think that the problem is that you would like guarantees that could only be provided at a high cost to everyone. I think that if you try to implement containers such as vector<> with a strong guarantee for all operations you will realise why the Standard does not make this promise. It can be done but the cost would be so high that few would want to pay it if they did not have to. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Thomas Richter on 26 Jul 2010 07:16
Mathias Gaunard wrote: > On Jul 26, 12:55 am, n...(a)cam.ac.uk wrote: > >> There is NO WAY that a programmer can add recovery facilities to >> the current STL. An implementor can - but, to make it usable, has >> to specify its properties and constraints - i.e. design an extended >> STL standard. > > 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. Oh please, come on. How applicable is that in an embedded application? And, even worse, if it is "that trivial", why doesn't the STL provide this "trivial" extension? A "safe_vector<..>" might come handy in cases, and you can surely implement it much better than *that*. So long, Thomas -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |