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" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Custom Storage Pool questions
Date: Tue, 28 Sep 2021 17:04:05 -0500
Organization: JSA Research & Innovation
Message-ID: <sj03gm$7j9$1@franka.jacob-sparre.dk>
References: <e3c5c553-4a7f-408a-aaa7-60ec0b70202dn@googlegroups.com> <ly5yv1bxgy.fsf@pushface.org> <shtg99$tgd$1@gioia.aioe.org> <lywnnha7y1.fsf@pushface.org> <1d2551f4-8189-44ec-a54d-4a56a672bedcn@googlegroups.com> <c2d59417-398f-42a0-ab4b-b4f947325be0n@googlegroups.com> <si26q3$13l1$1@gioia.aioe.org> <lyo88r9e99.fsf@pushface.org> <si2ud7$fv2$1@gioia.aioe.org> <iqkevvFr27rU1@mid.individual.net> <si45ls$1goa$1@gioia.aioe.org> <iqloa8F3sptU1@mid.individual.net> <si4ell$1b25$1@gioia.aioe.org> <sib8rc$nda$1@franka.jacob-sparre.dk> <sibvcr$1ico$1@gioia.aioe.org> <siu5r7$st6$1@franka.jacob-sparre.dk> <siueba$efk$1@gioia.aioe.org> <lymtnxb0hs.fsf@pushface.org> <siuigp$bqs$1@gioia.aioe.org>
Injection-Date: Tue, 28 Sep 2021 22:04:07 -0000 (UTC)
Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226";
	logging-data="7785"; 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:62856
List-Id: <comp.lang.ada>

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:siuigp$bqs$1@gioia.aioe.org...
> On 2021-09-28 09:52, Simon Wright wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>>> And no object may be destroyed unless deallocated.
>>
>> Well, if it's important that an allocated object not be destroyed, don't
>> allocate it from a storage pool that can go out of scope!
>
> That was never the case.
>
> The case is that an object allocated in a pool gets finalized because the 
> access type (not the pool!) used to allocate the object goes out of the 
> scope.
>
> This makes no sense whatsoever.
>
> Again, finalization must be tied with [logical] deallocation. Just like 
> initialization is with allocation.

But it is. All of the objects allocated from an access type are logically 
deallocated when the access type goes out of scope (and the memory can be 
recovered). Remember that Ada was designed so that one never needs to use 
Unchecked_Deallocation.

I could see an unsafe language (like C) doing the sort of thing you suggest, 
but not Ada. Every object in Ada has a specific declaration point, 
initialization point, finalization point, and destruction point. There are 
no exceptions.

                                    Randy.