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!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Proposal: Auto-allocation of Indefinite Objects Date: Wed, 19 Aug 2020 19:13:15 -0500 Organization: JSA Research & Innovation Message-ID: References: <94a54092-a56f-4a99-aaec-08dd611c8fd8@googlegroups.com> <8a502b6c-4609-4cd8-b292-5797fe6421e1n@googlegroups.com> Injection-Date: Thu, 20 Aug 2020 00:13:17 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="7985"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader01.eternal-september.org comp.lang.ada:59754 List-Id: "Dmitry A. Kazakov" wrote in message news:rgr27b$1o1n$2@gioia.aioe.org... > 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? The whole object goes in that pool. The entire mechanism in Janus/Ada is built around pools - the stack is represented by a pool object as well as various other pools to support the mechanism. >> 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. At the cost of using explicit allocators and effectively leaking memory (most tasks are fairly long-lived, much longer than the majority of objects). Randy.