From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Why is the destructor called multiple times after I declare an object? Date: Wed, 13 Jan 2016 20:59:06 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <293c58ac-4ebd-488a-abcc-b6e88811eec8@googlegroups.com> <871t9ogevj.fsf@theworld.com> NNTP-Posting-Host: LNA1TkTuMxfwTHzeJdi6nA.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:29117 Date: 2016-01-13T20:59:06+01:00 List-Id: On 2016-01-13 17:03, Robert A Duff wrote: > "Dmitry A. Kazakov" 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