Re: Custom Storage Pool questions

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

On 2021-10-03 06:33, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:sj9blb$1srp$1@gioia.aioe.org...
>> On 2021-10-02 11:06, Randy Brukardt wrote:
> ...
>>> 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.
>> 
>> Why compiler assisted bookkeeping is safe for subpools, but unsafe
>>  as a stand-alone mechanism?
> 
> There is no such stand-alone mechanism, and there cannot be one

Huh, collections are stand-alone and exist already. Just do them 
user-accessible and maintainable. The same is with the allocators. What 
is the problem adding a generic package

    generic
       type User_Type (<>) is private;
       type User_Pool is abstract new Root_Storage_Pool with private;
    package Generic_Parametrized_Pool is
       procedure User_Allocate
                 (  Pool            : in out User_Pool ;
                    Storage_Address : out Address;
                    Size            : Storage_Count;
                    Alignment       : Storage_Count;
                    Data            : in out User_Type
                 )  is abstract;
       ...

To handle "subpool" kludges:

    P := new (Parameter) T;

Not that Generic_Parametrized_Pool would be more usable than subpools. 
The problem with these is lack of Unchecked_Deallocation.

>> Sure, but again. there is a paramount use case that requires 
>> dynamic elaboration of tagged types, i.e. the relocatable 
>> libraries. You cannot ban them
> 
> I suppose, but you certainly don't have to use them.

I must. It is impossible to maintain production grade software without 
its components linked as relocatable libraries.

> That sort of 
> thing is nonsense that simply makes programs more fragile than they 
> have to be. I just had a problem with Debian where some older 
> programs compiled with GNAT refused to run because an update had 
> invalidated some library. Had to dig out the source code and 
> recompile.

Yes, but static monolithic linking is even more fragile. Typically a 
customer orders software off the shelf. It means that he says I need, 
e.g. HTTP client, ModBus master, CANOpen etc. It is simply impossible to 
re-link everything for each customer and run integration tests. So the 
software is organized as a set of plug-in relocatable libraries, each of 
them maintained, versioned and tested separately. You cannot turn clock 
20 years back.

> ...
>> you cannot forbid tagged extensions declared in a relocatable 
>> library.
> 
> Of course you can.

How? Ada does not determine the way you link an executable. If I put a
package in a library it is there. If the package derives from a tagged type

> The only thing you need to be compatible with is a C interface, which
> is the only thing you need to interface to existing libraries that
> you can't avoid.

That would kill most of Ada libraries.

>> So getting rid of nesting tagged types will ease nothing.
> 
> The problem is tagged types not declared at the library level. 
> Relocatable librarys are still library level (they have their own 
> global address space).

When the library is loaded dynamically, there is no way to know in the 
executable the tag of the extension or prepare an extension of the 
dispatching table. I think it is far worse than a nested declaration, 
when is you have some information.

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