Is there any standard/guarantees for exception safety in STL operations?
in [C++]
|
Prev: What are requirements for allocator destructor?
Next: Is there any standard/guarantees for exception safety in STL operations?
From: Kenneth 'Bessarion' Boyd on 26 Jul 2010 23:43 On Jul 26, 11:40 pm, Mathias Gaunard <loufo...(a)gmail.com> wrote: > 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? The one referenced there: T's. -- [ 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 23:43 On Jul 26, 11:35 pm, n...(a)cam.ac.uk wrote: > Sigh. No. Think mainframes - systems where the architecture > allowed you to recover from system-generated interrupts - events > that, in Unix and Microsoft systems, are mapped into signals. > > In C++, a signal handler can raise an exception - that generates > an asynchronous exception. The principle is easy, but the devil is > in the detail, as usual. Throwing C++ exceptions from signal handlers is an implementation- specific extension to the standards; strictly conformant code won't use such extensions. It's not disallowed, but I wouldn't be complaining about defects in the C++ standard for this. -- [ 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 23:46 On Jul 27, 5:35 am, n...(a)cam.ac.uk wrote: > >"Exceptions caused by asynchronous signals"? > >I don't know what you're talking about, but that seems quite outside > >the scope of C++. > > Quite probably, but I would regard that as being more a deficiency > of C++'s scope than anything else. While having that opinion is fine, making such strong statements based on erroneous assumptions of what the C++ exception model is -- as defined by C++ --, and what can and cannot be done with it, is fairly annoying, as this spreads misinformation. > In C++, a signal handler can raise an exception - that generates > an asynchronous exception. Standard C++ has no notion of signals either. In any case, exceptions do not unwind outside of a signal handler, so it could be argued they remain locally synchronous. In my opinion, the best way to deal with asynchronous requests such as these is to put them in a queue, and poll the queue from time to time. This ensures you don't get interrupted in a middle of a primitive that needs to never fail. This is actually the original design that was taken for cooperative thread cancellation in C++0x, but that was unfortunately dropped. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Joshua Maurice on 27 Jul 2010 06:39
On Jul 27, 7:46 am, Mathias Gaunard <loufo...(a)gmail.com> wrote: > On Jul 27, 5:35 am, n...(a)cam.ac.uk wrote: >> In C++, a signal handler can raise an exception - that generates >> an asynchronous exception. > > Standard C++ has no notion of signals either. What? A quick search of the C++03 standard shows otherwise. For example, 17.4.1.2 [lib.headers] / 3 and 4. It mentions how <csignal> is the header as defined as the C Programming Language Standard ISO/ IEC 9899:1990. 18.7 [lib.support.runtime] explains that the signal handling of <csignal> is the same as that defined in the C standard. The list goes on. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |