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: Mon, 10 Aug 2020 10:58:20 +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:59701 List-Id: On 10/08/2020 02:31, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:rfs7k4$c83$1@gioia.aioe.org... >> 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. > > This is not that hard to deal with. Janus/Ada handles discriminant-dependent > components of mutable objects this way: they are allocated on the stack, but > if they have to be reallocated they move to the heap. What you do if such an object is allocated via pool-specific access type? > I note that the original idea already exists for discriminant-dependent > components -- that's a bit more painful to use but hardly difficult. The > main issue is that most compilers fail to support these components properly, > using some sort of max-size implementation unconditionally rather than > switching to a pool-based implementation when the max size is too large. > I've never understood why Ada compilers were allowed to make such a > limitation (it becomes a major limitation when working on non-embedded > programs), while similar limitations on case statements and aggregates are > not allowed. I think a non-embedded target could use a task-local pool for the purpose. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de