From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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.6 Path: eternal-september.org!reader02.eternal-september.org!aioe.org!x6YkKUCkj2qHLwbKnVEeag.user.46.165.242.91.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Custom Storage Pool questions Date: Sun, 3 Oct 2021 10:40:05 +0200 Organization: Aioe.org NNTP Server Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: gioia.aioe.org; logging-data="3477"; posting-host="x6YkKUCkj2qHLwbKnVEeag.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org"; User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 X-Notice: Filtered by postfilter v. 0.9.2 Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:62928 List-Id: On 2021-10-03 06:33, Randy Brukardt wrote: > "Dmitry A. Kazakov" 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