[cfe-dev] [LLVMdev] [LLVMDev] Object in a try-catch block not being destroyed even after an exception

[John McCall]

On Jun 19, 2012, at 6:30 PM, Jordan Rose wrote:
> On Jun 19, 2012, at 18:25 , Richard Smith <richard at metafoo.co.uk> wrote:
>>> I believe the intent of the standard is quite clearly to have the local
>>> variable destroyed in reverse order of construction w.r.t. the temporaries,
>>> much like a return value must be.
>> 
>> That does not match my expectation, which is that in:
>> 
>>  S s(T(), T());
>> 
>> the T temporaries should *always* be destroyed before the S object is.
> 
> To take this a step further, if the code looked like this:
> 
> {
>   S s(T(), T());
>   doSomethingElse();
> }
> 
> …the S object should not be destroyed until doSomethingElse() finishes. The T objects, OTOH, will be destroyed at the end of the S object's decl statement (or thereabouts).
> 
> But if I /remove/ the call to doSomethingElse(), suddenly the S object is destroyed first?

Along normal control flow, there's no debate this we always see this:
  temp1.T();
  temp2.T();
  s(temp1, temp2); // assuming left-to-right evaluation for sake of argument
  temp2.~T();
  temp1.~T();
  doSomethingElse(); // if present
  s.~S();

Annotating this with exceptional edges, we would have:
  temp1.T(); // resume
  temp2.T(); // temp1.~T(); resume
  s(temp1, temp2); // temp2.~T(); temp1.~T(); resume
  temp2.~T(); // ??
  temp1.~T(); // s.~S(); resume
  doSomethingElse(); // s.~S(); resume
  s.~S(); // resume
  
The presence of doSomethingElse does not affect the ordering here, and I'm not sure why you're suggesting that my interpretation would make it so.  The only question is what the ordering of destructors is out of temp2.~T().

I'll respond to Richard in more detail.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120619/d9a143e0/attachment.html>