Re: Custom Storage Pool questions

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:sj6gmg$1n1n$1@gioia.aioe.org...
> On 2021-10-01 02:04, Randy Brukardt wrote:
...
>>> Nope, this is exactly how it works with most specialized pools, like
>>> arenas, stacks, reference counting pools etc.
>>
>> These things don't work as pools in Ada.
>
> Yes, they normally have Deallocate as a void operation or raise an 
> exception.

No, they don't, because they don't work with controlled types, tasks, etc. 
And there is no good way to enforce that the things you allocate into them 
don't have controlled or task components. So they are unsafe unless you use 
the subpool mechanism.

>> You need to use the subpool
>> mechanism to make them safe,
>
> I do not see how that could change anything without destroying the whole 
> purpose of such pools, namely nearly zero-cost allocation and 
> deallocation.

It ties any finalization to the subpool, so all of the contained objects get 
finalized when the subpool is freed. And lets the compiler know what's 
happening so it doesn't finalize the objects twice. Of course, if no 
finalization is involved, it doesn't do much of anything, but that's OK, 
you're prepared if any later maintenance adds finalization somewhere.

...
>> because otherwise the objects go away before
>> the type (given these sorts of mechanisms generally have some sort of 
>> block
>> deallocation).
>
> If controlled types need to be used, which rarely happens, a bookkeeping 
> is added to finalize them. Instead of IMO useless subpools, one could add 
> some allocation bookkeeping support etc.

That's again not safe in any sense. You shouldn't need to worry about 
whether some abstraction that you use uses finalization, especially as you 
can't know if someone adds it later.

...
>> Indeed, I now believe that any nested access type is evil and mainly is
>> useful to cause nasty cases for compilers. I'd ban them in an Ada-like
>> language (that would also simplify accessibility greatly).
>
> See where collections have led you! (:-))

No, that's mostly because of accessibility. I'd be happy if one banned doing 
any allocations with general access types (mixing global/stack allocated 
objects and allocated objects is pure evil IMHO), but that would be rather 
hard to enforce.

Note that nested tagged types also cause many implementation problems, 
adding a lot of unnecessary overhead. I'd probably go as far as banning all 
nested types (as opposed to subtypes), as types are supposed to live the 
entire life of the program (possibly anonymously) and that is weird when 
applied to things in nested scopes whose definition could depend on dynamic 
stuff.

                                         Randy.