Duncan@rcp.co.uk (Duncan Booth) writes:

>a) cleanup nested inside cleanup. (I don't think there is any problem
>with that, the code just gets executed at the end of the block).

Yes.  The execution of a cleanup statement schedules that statement
for execution.  At the end of the enclosing block, the code is executed.
So for example in

 {
  f1();
  cleanup {
   f2();
   cleanup {
    f3();
   }
   f4();
  }
  f5();
 }

we call f1(), schedule the outer cleanup block, and then call f5().
At the end of the block, we execute the outer cleanup block.
This involves calling f2(), scheduling the inner cleanup block,
calling f4(), and then executing the inner cleanup block.
So the sequence is f1(), f5(), f2(), f4(), f3().

>b) return nested inside cleanup. Would this be legal sometimes always
>or never?

I think never.  Any transfer of control (via goto, case, break, return, etc.)
in or out of a cleanup shoud be illegal.

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

In article <32au9l$fou@ritz.cec.wustl.edu>,
jaf3@ritz.cec.wustl.edu (John Andrew Fingerhut) wrote:
> [Code example deleted]
>
> Given this if cond1 is true:
>  no cleanups are executed.
> if cond2 is true:
>  i.seekg(pos); delete a; are executed.
> if cond3 is true then
>  if cond4 is true
>   i.seekg(pos); delete a; delete b; will be exected before the
>    return -4;
>  else
>   delete b; will be executed at the end of the if block
> if cond3 is false or cond4 is false then
>  i.seekg(pos); delete a; are executed before the return 0;
>
Except that you of course meant to say that the cleanup statements
are all executed in the reverse of the order they were encountered, I
could live with this, but would you care to comment on:

a) cleanup nested inside cleanup. (I don't think there is any problem
with that, the code just gets executed at the end of the block).

b) return nested inside cleanup. Would this be legal sometimes always
or never? Think about the following:

        int f()
        {
                cleanup return 0;
                [ lots of code ... ]
                if (cond)
                        return 1;
        }

You now have a magic way of specifying a default return value if you
fall off the end of the function! But if you don't just fall off the
end what do you do? My first thought is that you should allow
multiple returns, but actually return the result of the first return
statement encountered and evaluate but otherwise ignore any
subsequent return statements, but I'm not sure.

Don't forget too that any cleanup block must be evaluated AFTER the
expression in the return statement so as to allow:
        int f()
        {
                T *p = do_something();
                cleanup delete p;
                [ ... ]
                return p.value;
        }


Also what happens to code that follows a return statement
encountered inside a cleanup. Do you skip the rest of that particular
cleanup block or execute it? Say you skip it then you still have to
execute the other cleanup blocks (backwards).

        int f()
        {
                T *q = do_something(); cleanup delete q;
                T *p = do_something(); cleanup delete p;
                cleanup {
                        T *r = do_something(); cleanup delete r;
                        if (cond1) return p.value;
                        if (cond2) return q.value;
                        do_something_else();
                        return r.value;
                }
                some_more_code();
                if (cond3) return 0;
        }

What a lovely bit of spaghetti. Any bets as to the possible order of
execution and flow of control for this code?

Duncan Booth

>>>>> Duncan Booth <Duncan@rcp.co.uk> writes:

> a) cleanup nested inside cleanup. (I don't think there is any problem
> with that, the code just gets executed at the end of the block).

I suppose.

> b) return nested inside cleanup. Would this be legal sometimes always
> or never?

I vote for never; I would disallow jumping into or out of a cleanup block.

Jason

In article <k6UIkaN0YCVO069yn@rcp.co.uk>,
Duncan Booth <Duncan@rcp.co.uk> wrote:
>In article <32au9l$fou@ritz.cec.wustl.edu>,
>jaf3@ritz.cec.wustl.edu (John Andrew Fingerhut) wrote:
>> [Code example deleted]
>>
>> Given this if cond1 is true:
>>  no cleanups are executed.
>> if cond2 is true:
>>  i.seekg(pos); delete a; are executed.
>> if cond3 is true then
>>  if cond4 is true
>>   i.seekg(pos); delete a; delete b; will be exected before the
>>    return -4;
>>  else
>>   delete b; will be executed at the end of the if block
>> if cond3 is false or cond4 is false then
>>  i.seekg(pos); delete a; are executed before the return 0;
>>
>Except that you of course meant to say that the cleanup statements
>are all executed in the reverse of the order they were encountered, I

Of course that's what I meant ;-).  That's obvious now, but I was
concentrating on other features that weren't so obvious.

>could live with this, but would you care to comment on:
>
>a) cleanup nested inside cleanup. (I don't think there is any problem
>with that, the code just gets executed at the end of the block).

I don't think that I have a problem with this either.

>
>b) return nested inside cleanup. Would this be legal sometimes always
>or never?

I don't think that I like return being legal inside cleanup.  I would
allow break to jump to the end of the cleanup block and execute the proper
destructors.  break would apply to the cleanup block in the same way that
applies to a while loop...in otherwords, if there is a while loop in the
cleanup block containing a break...it applies to the while, not the cleanup.

I would assume also that the cleanup statements would be executed intermixed
with destructors of local objects in the reverse order in which they were
declared.  That would allow the cleanup blocks to have access to local objects
that were declared prior to the cleanup block.  Finally, as you stated, the
return would have to be executed prior to any cleanup in order to preserve the
return value.  That is already true of how destructors work.

I don't think that there is much chance of this becoming part of the language,
but it's a good exercise in that it shows what the committee goes through to
determine a language enhancement.

>
>Duncan Booth

Stephen Gevers
sg3235@shelob.sbc.com