comp.lang.ada
 help / color / mirror / Atom feed
From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Proposal: Auto-allocation of Indefinite Objects
Date: Sun, 9 Aug 2020 19:39:31 -0500	[thread overview]
Message-ID: <rgq504$4fc$1@franka.jacob-sparre.dk> (raw)
In-Reply-To: rfv3gf$1bbo$1@gioia.aioe.org

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 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.


  reply	other threads:[~2020-08-10  0:39 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-03 22:48 Proposal: Auto-allocation of Indefinite Objects Stephen Davies
2020-04-03 23:45 ` Stephen Leake
2020-04-04 10:54   ` Jeffrey R. Carter
2020-04-04 20:55     ` Stephen Davies
2020-04-04  8:31 ` Dmitry A. Kazakov
2020-07-27  7:47 ` Yannick Moy
2020-07-27  9:21   ` J-P. Rosen
2020-07-27  9:49     ` Dmitry A. Kazakov
2020-07-27 17:48   ` Brian Drummond
2020-07-27 20:02     ` Dmitry A. Kazakov
2020-07-28 14:28       ` Brian Drummond
2020-07-28 14:59         ` Dmitry A. Kazakov
2020-07-29 15:33           ` Brian Drummond
2020-07-29 16:20             ` Dmitry A. Kazakov
2020-07-30 13:37               ` Stephen Davies
2020-07-30 14:23                 ` Dmitry A. Kazakov
2020-07-30 17:04               ` Brian Drummond
2020-07-30 18:28                 ` Dmitry A. Kazakov
2020-08-10  0:39                   ` Randy Brukardt [this message]
2020-08-10  8:57                     ` Dmitry A. Kazakov
2020-08-20  0:10                       ` Randy Brukardt
2020-08-20 17:49                         ` Dmitry A. Kazakov
2020-08-20 20:19                           ` Dennis Lee Bieber
2020-08-20 23:33                             ` Randy Brukardt
2020-08-21  6:45                               ` Dmitry A. Kazakov
2020-08-23  4:52                                 ` Randy Brukardt
2020-08-23 12:28                                   ` Dmitry A. Kazakov
2020-08-20 23:30                           ` Randy Brukardt
2020-08-21  6:46                             ` Dmitry A. Kazakov
2020-08-23  4:48                               ` Randy Brukardt
2020-08-23 12:29                                 ` Dmitry A. Kazakov
2020-08-10  0:31               ` Randy Brukardt
2020-08-10  8:58                 ` Dmitry A. Kazakov
2020-08-20  0:13                   ` Randy Brukardt
2020-08-20 17:49                     ` Dmitry A. Kazakov
2020-08-20 23:25                       ` Randy Brukardt
2020-08-21  7:08                         ` Dmitry A. Kazakov
2020-08-23  5:03                           ` Randy Brukardt
2020-08-23 12:28                             ` Dmitry A. Kazakov
2020-07-27 20:31     ` Jeffrey R. Carter
2020-07-31  9:25 ` Stephen Davies
2020-07-31 10:20   ` Dmitry A. Kazakov
2020-08-01 11:22     ` Stephen Davies
2020-08-01 12:58       ` Dmitry A. Kazakov
2020-08-01 20:35         ` Stephen Davies
2020-08-01 20:56           ` Dmitry A. Kazakov
2020-09-03  4:30 ` linda white
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox