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=-0.9 required=3.0 tests=BAYES_00,XPRIO autolearn=no autolearn_force=no version=3.4.6 Path: eternal-september.org!reader02.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Custom Storage Pool questions Date: Sat, 2 Oct 2021 04:06:24 -0500 Organization: JSA Research & Innovation Message-ID: References: <1d2551f4-8189-44ec-a54d-4a56a672bedcn@googlegroups.com> Injection-Date: Sat, 2 Oct 2021 09:06:26 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="29566"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:62921 List-Id: "Dmitry A. Kazakov" 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.