Boost logo

Boost :

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2002-09-27 11:37:01


Fredrik Blomqvist wrote:
[...]
> > vector1.push_back(e1);
> > try {
> > vector2.push_back(e2):
> > }
> > catch(...) {
> > vector1.pop_back();
> > throw;
> > }
>
> Isn't this a good example of something scopeguard ...

would also solve... but >>NOT<< having any nasty portability
problems [and that's just one reason among a couple of others
to avoid catch(...)-like-above thing] with respect to "safety"
of thread cancel and thread exit under currently-quite-common-
threaded-C++-approach known as "forced unwinding"-Y'know-
"catch(...)-doesn't-exist" that, unfortunately, IS used by
numerous C++ implementations out there... like the following
one: <for example>

http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/EDCLB130/3.522.14
("3.522.14 pthread_cancel() -- Cancel a Thread")

http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/EDCLB130/3.522.30
("3.522.30 pthread_exit() -- Exit a Thread")

"....
   Standards / Extensions C or C++ Dependencies
   POSIX.4a both POSIX(ON)
 ....
 Special Behavior for C++

 Destructors for automatic objects on the stack will
 be run when a thread is canceled. The stack is unwound
 and the destructors are run in reverse order. "

<?>

regards,
alexander.

--
http://groups.google.com/groups?selm=3D89CACB.12BB6122%40web.de
("action_on_propagation_of(...) {")

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk