Re: Why is the destructor called multiple times after I declare an object?

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:n715oq$fae$1@gioia.aioe.org...
> On 2016-01-11 19:17, Bob Duff wrote:
>> Brian Drummond <brian@shapes.demon.co.uk> writes:
>>
>>> Somehow I expected "extended return" to allocate space and "build in
>>> place" during the execution of the return statement.
>>
>> Build-in-place is done for return of immutably-limited types,
>> whether or not the extended return syntax is used.
>
> But you can leave one return statement on an exception, catch the 
> exception, and then return through another return statement, with other 
> discriminants and even other type of the result (if it is class-wide).
>
> Therefore the result can be potentially allocated and reallocated any 
> number of times. In which sense is this behavior 'in-place'?

"Build-in-place" means simply that there is no temporary object, the object 
is created directly in its final resting place (that is the memory where it 
will live during its existence).

Whatever amount of effort it takes to figure out that final resting place is 
not part of the equation.

For many situations (and implementation models), the size of the result 
object will not change regardless of discriminants chosen, so the sort of 
thing you describe above cannot happen. For assignments to most existing 
objects, the discriminants/tag cannot be changed, and 6.5(24/3) allows the 
Constraint_Error exception to be raised early in scenarios like the one you 
lay out. (Such an exception cannot be handled within the function, as it 
happens at the call-site.) If the discriminants are mutable, the compiler 
already has to have some mechanism for changing them [either by using 
allocate-to-the-max or reallocation], and build-in-place uses that same 
mechanism, without the temporary. You'd get the same behavior when assigning 
some other object as with a build-in-place function.)

                                                 Randy.