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

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

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

Yes.  Or you can 'goto' or 'exit' out of an extended return.

>>>>> Therefore the result can be potentially allocated and reallocated any
>>>>> number of times. In which sense is this behavior 'in-place'?

"In place" means that the returned object created by the return
statement that actually returns is the same object as the one at the
call site.  If the return statement raises an exception, then it doesn't
actually return.

Note that this point has nothing to do with extended_return syntax.
An old fashioned "return <expression>;" can raise an exception,
and be handled, and then do a different return.  The syntax doesn't
matter; build-in-place is controlled by "immutably limited".

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

No, that's not right.  Candidate_1 is an object created by the first
return statement, and finalized during "raise Try_Again;".  It no
longer exists when Candidate_2 is created.  If Candidate_2 is returned
(there's no more raise/goto/whatever in there), then Candidate_2
is the same object as the one created at the call site.

> What makes two objects "same"? ...

The RM is clear on that point, and it is clear that the two candidates
are not the same object.

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

No, the RM says almost nothing about 'Address.  A garbage collector
could move objects around.  Access values are equal if and only if
they designate the same object (even in the presence of GC), but
Addresses are not (necessarily) so well behaved.

> 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

The RM doesn't define "location".  And the rules about 'Address are
pretty loose.  And GNAT is correct here.

I think what Randy meant to say is that X (declared in Test_Return)
is the same object as Candidate_2.  That is what is required by the
RM, and it's what "build in place" means.  In GNAT, if you printed
X'Address it would match Candidate_2'Address, but that's not required
by the RM.  The two candidates are not the same object, as you
correctly noted.

If you had said:

    type Acc is access P.T'Class;
    X : Acc := new P.T'Class'(Create);

then Candidate_1 would get allocated on the heap, then finalized and
deallocated, then Candidate_2 would get allocated on the heap, and
X.all would end up being the same object as Candidate_2.

But keep in mind that the above example is quite unusual.  The normal
case is to have exactly one extended return.  And the size of the thing
is known at compile time, or at least known at the call site, so
the caller can allocate the result (stack, heap, whatever), and
pass the address of that to the function.

> 4. The same object allocated at two different memory addresses?
>
> Finally, I know that you don't consider RM subject to mathematical
> logic, ...

Now, now, that's just sniping.  We try to make the RM correct,
but we make mistakes.

- Bob