On Friday, 28 June 2013 at 06:15:26 UTC, Nick Sabalausky wrote:
On Fri, 28 Jun 2013 07:11:05 +0200
"Maxim Fomin" <ma...@maxim-fomin.ru> wrote:

On Friday, 28 June 2013 at 04:54:56 UTC, Nick Sabalausky wrote:
> Probably a silly question, but I wanted to double-check...
>
> If you have this:
>
>     struct Foo {...}
>     bar(Foo());
>
> Then regardless of optimizations (aside from any optimizer > bugs, of > course) the Foo temporary can't go out of scope or have its > dtor called
> until bar finishes executing, right?

Struct dtor is always called in the end of the caller (bar in example).

This will be OK, but in general case no. Currently object is copied in caller side but destroyed in callee side, and if one of the arguments next to struct is passed by invoking function which throws, callee and respectively dtor will never be called.


Interesting.

BTW, for anyone else reading, I just searched bugzilla and it looks
like the relevant issue is #9704.

Kinda ugly as it means refcounted RAII structs can leek under this
condition:

func(refCountedStruct, thisThrows());

Ouch.

Just in case it wasn't clear from the original explanation, this is a bug, it *should* be perfectly safe to pass as many temps as you want, and expect the right amount of destructor called in case of a throw.

Reply via email to