Re: [boost] Re: improved assertions?

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-06-24 12:33:19

----- Original Message -----
From: "Victor A. Wagner, Jr." <vawjr_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, June 21, 2002 6:58 PM
Subject: Re: [boost] Re: improved assertions?

> At Friday 2002/06/21 07:41, you wrote:
>
> >----- Original Message -----
> >From: "Victor A. Wagner, Jr." <vawjr_at_[hidden]>
> >To: <boost_at_[hidden]>
> >Sent: Thursday, June 20, 2002 7:19 PM
> >Subject: Re: [boost] Re: improved assertions?
> >
> >
> > > rely on unwinding _before_ the catch handler executes??
> >Yes, or at least, as the first event that ocurrs within the catch
handler.
> >Consider:
> >
> >void foo()
> >{
> >   std:auto_ptr<thing> resource(new thing);
> >   throw 0 ;
> >}
> >
> >void bar()
> >{
> >   try
> >  {
> >    foo();
> >  }
> >  catch ( int const& )
> >  {
> >    // At this point, the stack has been unwinded already, thus I know
that
> >'resource' from within foo()
> >    // is already deleted.
> >    // I could call exit(..) here without a leak (from what's done within
the
> >try-block).
> >  }
> >}
>
> Are you suggesting that calling exit() doesn't finish unwinding the stack
> when it's finished?
>
Yes.

3.6.1/4 says:

"void exit(int);
declared in <cstdlib> (18.3) terminates the program without leaving the
current block and hence with­
out destroying any objects with automatic storage duration (12.4)."

> That seems to me to make it impossible to write a program which doesn't
> "leak" if ANY call to exit() exists.
>
Yes, it leaks everything that that has been allocated further up in the
stack frame.

>
> > > I didn't suggest within the throwing frame, I suggested a new frame
(the
> > > catch LOOKS almost like a function anyhow)..... catch (const
> > > std::exception& except){body}
> >
> >But were would this new frame be? frames are always within frames in the
C++
> >execution model.
>
> Sorry, I mis-interpreted you use of "within".. I really did mean make
throw
> appear to be a call to function (create a new frame and all).
>
OK.

> >Currently, the catch handler 'frame' is coincident with the try-block
frame.
> >The throwing frame is necessarily nested, so the only way by which a
catch
> >handler could access the throwing frame (which is essentially what we're
> >looking for) is to be located within the throwing frame. It could be
nested
> >in the throwing frame if C++ used extended scopes, but even then it would
be
> >within the throwing frame.
>
> I wasn't referring to "access"ing the throwing frame in the normal sense
> (changing the local variables, etc.) ...only to be _able_ to write a
"stack
> call trace" (unique for every implementation, I suspect) to get some
> debugging information.
>
I see. This exactly what were are looking for. It's just that your
statements about the non-resumption model confused me.

> [snipped]
>

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com