From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED.2uCIJahv+a4XEBqttj5Vkw.user.gioia.aioe.org!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Proposal: Auto-allocation of Indefinite Objects Date: Thu, 30 Jul 2020 20:28:32 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <94a54092-a56f-4a99-aaec-08dd611c8fd8@googlegroups.com> <8a502b6c-4609-4cd8-b292-5797fe6421e1n@googlegroups.com> NNTP-Posting-Host: 2uCIJahv+a4XEBqttj5Vkw.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 X-Notice: Filtered by postfilter v. 0.9.2 Content-Language: en-US Xref: reader01.eternal-september.org comp.lang.ada:59603 List-Id: On 30/07/2020 19:04, Brian Drummond wrote: > On Wed, 29 Jul 2020 18:20:24 +0200, Dmitry A. Kazakov wrote: > >> On 29/07/2020 17:33, Brian Drummond wrote: >>> On Tue, 28 Jul 2020 16:59:09 +0200, Dmitry A. Kazakov wrote: >> >>>>> A constant String := "done"; >>>>> Q : indefinite String; >>>>> ... >>>>> loop >>>>> Q := Get_Line; exit when Q = A; >>>>> end loop; >>>> >>>> I am not comfortable with the semantics of this and with possible >>>> implications too. I would keep it simple. >>> >>> Interesting. Can you pin down some of that discomfort? It looks simple >>> to me : >>> >>> "indefinite" indicates the size can vary (and the compiler knows >>> whether it used the heap or stack), and in the absence of "aliased" we >>> know there are no copies of the pointer (if heap). >> >> I don't like compiler relocating objects. If the pool is a stack (or >> heap organized as a stack) it might be unable to do this. > > Ah OK, I see it. > > The compiler should be able to determine if (as in the loop above) the > use of Q (the indefinite type) is equivalent to a Declare block (i.e. can > be on the stack; new stack frame in each iteration; no relocation ever > required) or not. I don't want the compiler deciding where Q is allocated, especially because this could break things: 1. Large object moved to the stack 2. Lock-free code starting using heap lock when moved from the stack. The mechanism should be transparent. I do not like Unbounded_String for many reasons. Fiddling with the heap is one of them. I do not know which heuristic it uses to reduce reallocation and how much extra memory it takes under which circumstances. >> In general, there are two close but not equivalent objectives one is >> handling indefinite components of records another is a transparent >> holder object integrated into the language (without generic mess). >> >> Your use case is about the latter. My is rather the former. > > If a record with even one indefinite component is an indefinite record, > and therefore embedded in a transparent holder (I like that term), aren't > they equivalent? I don't understand this question. >>> Honest question : Inconsistent with what? >>> I suggested shallow copy just for simplicity, and for no (ahh) deeper >>> reason. But again, I'm probably missing something. >> >> If you make a shallow copy of >> >> type Node_Type is record >> Item : new Element_Type; >> Prev : Node_Ptr_Type; Next : Node_Ptr_Type; >> end record; >> >> you create a dangling pointer should the original node disappear. A deep >> copy would create a new target for new Item. > > You are using "new" to signify Item is indefinite, I think? > > But the problem is that Prev,Next are copies of the original Prev,Next > pointers, so if the original Node_Type is then freed, they are dangling? They are supposed to be handled by the doubly-linked list infrastructure, e.g. Prev and Next pointing to the node itself is a precondition for freeing the node. The problem is with the node contents. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de