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: Sun, 9 Aug 2020 19:39:31 -0500 Organization: JSA Research & Innovation Message-ID: References: <94a54092-a56f-4a99-aaec-08dd611c8fd8@googlegroups.com> <8a502b6c-4609-4cd8-b292-5797fe6421e1n@googlegroups.com> Injection-Date: Mon, 10 Aug 2020 00:39:32 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="4588"; 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:59695 List-Id: "Dmitry A. Kazakov" wrote in message news:rfv3gf$1bbo$1@gioia.aioe.org... > 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 The compiler is buggy IMHO if this breaks something. Any compiler has to be able to deal with objects that exceed the maximum stack frame, and move those to somewhere that they will fit (or reject completely). Yes, most compilers are buggy this way (including mine in a few cases). So what? > 2. Lock-free code starting using heap lock when moved from the stack. Expecting a compiler not to use the heap is silly in any case (outside of the No_Heap restriction - use that in Janus/Ada and the compiler refuses to do anything outside of elementary types). The compiler is supposed to be making the programmer's life easier, not adding new hurdles. > 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. That's the idea of such mechanisms. If you really need control, you do not use these abstractions and instead write the stuff yourself explicitly using access types and the like. Otherwise, you use containers and unbounded strings, and they do what they do. There's no free lunch. But the need to be explicit should be very rare - the main problem is programmers with insufficient trust that a compiler will do the right thing. Randy.