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.
