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:n72hag$bjq$1@gioia.aioe.org...
> On 12/01/2016 00:44, Randy Brukardt wrote:
>> "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.
>
> Yes, but you said 'no temporary object' which is untrue because a return 
> statement creates exactly such an object. You could even use this object 
> in order to create another one:
>
>    return Candidate_1 : T (Size => 1) do
>       Size := Candidate_1.Get_Required_Size;
>       raise Try_Again;
>    end return;
> exception
>    when Try_Again =>
>       return Candidate_2 : T (Size => Size) do
>           ...
>       end return;
>
> Since Ada lacks proper user-defined constructors one cannot claim that 
> Candidate_1 was not fully constructed. Even its Initialize was through.

But this is *not* a temporary object. The final object might change identity 
in such a scenario, but Candidate_1 and Candidate_2 are the *same* object, 
with different properties. The various limitations on using a function call 
as the parent part of an extension aggregate exist specifically because of 
this effect.

For a inherently limited type (the kind that requires build-in-place), the 
location of the object is part of its identity, argubly the most important 
part.

(I realize that you might be defining "object" in your own way, which as 
always is irrelevant; I'm using the definition of "object" and "temporary 
object" as used in the Ada Standard.)

                                          Randy.