Re: Proposal: Auto-allocation of Indefinite Objects

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 20/08/2020 02:13, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:rgr27b$1o1n$2@gioia.aioe.org...
>> On 10/08/2020 02:31, Randy Brukardt wrote:

>>> 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.

OK, but then you are back to the problem that you do not know how that 
pool works. The user pool might require a certain order of objects 
inside it and your interference with relocation will break it.

>>> 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).

No, I meant that if you used a pool behind the scenes for local objects 
you could do that task-specific eliminating interlocking.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de