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

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

On 2016-01-13 17:03, Robert A Duff wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> It is rather a useless definition, because it would apply to the objects
>> returned by-copy as well. At some point *some* object created as a
>> result of a call to the callee becomes the object of the caller.
>
> No, nonlimited objects work differently.  Consider:
>
>    package P is
>
>       type Doubly_Linked_List;
>       type Node_Ptr is access all Doubly_Linked_List;
>       type Doubly_Linked_List is limited record
>          Next, Prev: Node_Ptr;
>          Payload: Integer;
>       end record;
>
>       function Empty_List return Doubly_Linked_List;
>
>       Global: Node_Ptr;
>
>    end P;
>
>    package body P is
>
>       function Empty_List return Doubly_Linked_List is
>       begin
>          return Result: aliased Doubly_Linked_List do
>             Result.Next := Result'Unchecked_Access;
>             Result.Prev := Result'Unchecked_Access;
>             Global := Result'Unchecked_Access;
>          end return;
>       end Empty_List;
>
>    end P;
>
>    with Text_IO; use Text_IO;
>    procedure P.Main is
>       My_List: aliased Doubly_Linked_List := Empty_List;
>    begin
>       Put_Line(Boolean'(Global = My_List'Unchecked_Access)'Img);
>       Put_Line(Boolean'(My_List.Next = My_List'Unchecked_Access)'Img);
>       Put_Line(Boolean'(My_List.Prev = My_List'Unchecked_Access)'Img);
>    end P.Main;
>
> The example must print TRUE three times.  In Empty_List, we set three
> pointers pointing to Result.  After the call they point to My_List.
> That's because My_List and Result are the same object.

Yes, but your definition still apply to all types. Some object must 
travel across the callee-caller border. That last object remains same 
regardless limited or not.

> If we erase "limited", then the example is illegal -- Result can't be
> aliased.  If that were allowed, then all three pointers would be
> dangling pointers, and the Put_Lines would all be erroneous.
> That's because Result and My_List are NOT the same object
> in the nonlimited case, and Result is gone by the time the
> Put_Lines are executed.

You could make it Controlled and fix pointers in Adjust. Your program 
will not notice a difference.

>> To my understanding Randy's definition tried to address this by claiming
>> absence of intermediate objects (as a generalization of the notion of
>> copying).
>>
>>> Note that this point has nothing to do with extended_return syntax.
>>
>> Right. Also neither and no definition will work ever. Whichever syntax
>> "same" object cannot be "returned".
>
> Two access values are "=" if and only if they designate the same
> object.

You can have different access values pointing same object (e.g. of two 
different access types) and, possibly, same access values pointing 
different objects (I believe Ada permits "near" access values for a 
segmented memory machine, then there is Unchecked_Union etc)

> See example above.  QED.

Sure, some object is always returned and every object is always same to 
itself. This is not sufficient to define useful "in-place". In my view a 
definition must have the place known at the caller's context. E.g. to 
have the object:

1. Allocated at a specific machine address
2. Allocated by an allocator in the specific memory pool
3. Allocated as a specific component of a container object
4. Allocated as a parent of a derived type object

The problem of returned object is that it conflates allocation with 
initialization.

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