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