🚀 go-pugleaf

In article <DI24xB.756@falcon.daytonoh.attgis.com> mennid <Dick.Menninger@daytonoh.attgis.com> writes:
| Although the wisdom of continuing the backward destruction
| of the array may be quite suspect, it seems that 15.2 of DWP

For non-heap arrays, the DWP does seems to say that.  Is this reasonable?

| gives compilers no choice but to do that.  The danger seems
| to be an inherent part of requiring exception handling
| (including the destructor processing while unwinding) to be
| exception-free.  Part of the problem here is that there can be
| an environmental thing for class T (or that particular array)
| that puts destruction of the other instances into the same
| exception case.  If that is the case, the destructor for the

I don't understand this at all.  Can you elaborate?

| class has to do the initial catch and put the class into
| a special state before rethrowing it.  Further, the exception
| instance has to deal with notifying class T on its "final"
| destruction.  If temporaries can get destroyed after copying
| those are not "final" destructions.  The notification would
| take the class out of the special state if appropriate.
| 
| If the problem is not environmental to T, then you must take
| your chances, but the DWP seems to say compilers better
| continue with destruction of the array.
| 
| A related question is:
| Does the DWP require the frames to be unwound
| while it looks for a handler that catches the exception,
| so that if it does not find a valid catcher all frames
| are still gracefully undone (barring another exception)?

The DWP makes it clear that stack frames need not be unwound if no handler
is found, but if a handler is found, locals in intervening frames must have
been destroyed by the time the handler is entered.

Scott

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]