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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2016-01-12 21:21, Randy Brukardt wrote:
> "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.

What makes two objects "same"? Especially if:

1. none of them exists at the same time as another
2. one of them is already finalized
3. they have different specific types, discriminats, components

If T were not limited would they be same too?

> 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.

What is "location"?

Does RM specifically require the implementation to have 
Candidate_1'Address = Candidate_2'Address?

The following program -------------------------->
with Ada.Text_IO; use Ada.Text_IO;
with System.Storage_Elements;  use System.Storage_Elements;

procedure Test_Return is
    package P is
       type T is tagged limited null record;
    end P;
    package Q is
       type S (L : Positive) is new P.T with record
          X : String (1..L);
       end record;
    end Q;
    function Create return P.T'Class is
    begin
       return Candidate_1 : P.T do
          Put_Line (Integer_Address'Image (To_Integer 
(Candidate_1'Address)));
          raise Constraint_Error;
       end return;
    exception
       when Constraint_Error =>
          return Candidate_2 : Q.S (1000) do
             Put_Line (Integer_Address'Image (To_Integer 
(Candidate_2'Address)));
          end return;
    end Create;	
    X : P.T'Class := Create;
begin
    null;
end Test_Return;
<----------------------------------------
prints:
 >test_return
  4454256
  4454272

Is GNAT at fault? Maybe "location" is not the memory address? And

4. The same object allocated at two different memory addresses?

Finally, I know that you don't consider RM subject to mathematical 
logic, but in logic partial identity is just meaningless. E.g. you may 
say that the highest order digit is the most important part of number, 
but that does not imply two numbers same when their highest order digits 
are same.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de