Scope of temporaries as function arguments
monarch_dodra
monarchdodra at gmail.com
Fri Jun 28 01:08:16 PDT 2013
On Friday, 28 June 2013 at 06:15:26 UTC, Nick Sabalausky wrote:
> On Fri, 28 Jun 2013 07:11:05 +0200
> "Maxim Fomin" <maxim at 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.
More information about the Digitalmars-d-learn
mailing list