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:

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

If the implementation chooses to put My_List at a different location
than Result, and copy Result into My_List, it would have to update
those pointers, which is not easy.  The intended implementation is
to make sure that My_List and Result are at the same address.
My_List is of known size, so it is allocated at the declaration,
and its address is passed to Empty_List, so it knows where
to put Result.  If the size were not known at the call site,
things would be more complicated -- it passes information about
where to allocate (on the stack, on the global heap, in some
user-defined storage pool, ...), and the function would
do the allocation once it knows the size, and passes the
address back to the caller.

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.

> 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.  See example above.  QED.

>> The RM doesn't define "location".  And the rules about 'Address are
>> pretty loose.  And GNAT is correct here.
>
> I didn't doubt it. The example was for the sake of argument. If RM
> attempted to define "same" location in a useful way that would make
> reasonable implementations impossible.

Agreed.

>> Now, now, that's just sniping.
>
> Yes, yes, I fired back at an attempt to evade discussion by the game of
> definitions. (:-))

;-)

- Bob