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: Fri, 1 Oct 2021 10:25:52 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <1d2551f4-8189-44ec-a54d-4a56a672bedcn@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: gioia.aioe.org; logging-data="56375"; 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:62913 List-Id: On 2021-10-01 02:04, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:sj3r92$pla$3@gioia.aioe.org... >> On 2021-09-30 02:16, Randy Brukardt wrote: >>> "Dmitry A. Kazakov" wrote in message >>> news:sj2008$1cmo$1@gioia.aioe.org... >>> ... >>>> Random = unrelated to the object's life time. >>> >>> All objects have to disappear before their type disappears, so the object >>> *cannot* live longer than the access type for which it is allocated from. >> >> The type of the access type /= the type of object. Only access objects >> must disappear and they do. > > ?? type T is range 1..2; type P is access T; T /= P > There is nothing in a pool except unorganized memory. "Objects" only > exist outside of the pool for some access type. No the objects exist in the pool and are *accessible* via one or more access types, some of them could even be anonymous, BTW. > There has to be some > organizing type, else you would never know where/when things are finalized. Yes, and that is up to the programmer. >>> It's probably a lousy idea to share pool objects (as opposed to pool >>> types) >>> amongst access types. >> >> You need these for access discriminants. > > Those (coextensions) are one of Ada's worst ideas; they have tremendous > overhead without any value. Almost everything has to take them into account. > Yuck. Access discriminants of existing objects are OK but really don't add > anything over a component of an access type. Discriminants add safety when creating objects because the language requires initialization of. For components one have to use an aggregate which turns extremely difficult in practical cases or even impossible. >>> If you do have a longer lived pool and a shorter lived access type, you >>> will >>> end up with a bunch of zombie objects in the pool that cannot be used in >>> any >>> way (as any access is erroneous). All that can happen is a memory leak. >>> Don't do that. >> >> 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. > 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. > 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. > Allocated objects can only be deallocated from > the same type as they were allocated. You can perfectly deallocate any object by erasing its pool and you can finalize the object before doing that too. Furthermore you can use a local access type and instantiate Unchecked_Deallocation with it. There are many ways to skin the cat. The language must do no baseless assumptions about programmer's intentions. > 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! (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de