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: Wed, 29 Sep 2021 09:57:32 +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="65168"; 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 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.9.2 Xref: reader02.eternal-september.org comp.lang.ada:62857 List-Id: On 2021-09-29 00:04, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:siuigp$bqs$1@gioia.aioe.org... >> On 2021-09-28 09:52, Simon Wright wrote: >>> "Dmitry A. Kazakov" 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). Really? And where is the call to the pool's Deallocate in that case? You cannot have it both ways. > Remember that Ada was designed so that one never needs to use > Unchecked_Deallocation. Come on. There never existed Ada compiler with GC. And nobody could even implement GC with the meaningless semantics of "collections" in the way, killing objects at random. Either with GC or without it, there must be no such thing as "collections." > I could see an unsafe language (like C) doing the sort of thing you suggest, > but not Ada. How random finalizing user-allocated and user-freed objects is safe? And I suggest doing exactly nothing as opposed to *unsafe*, costly and meaningless behavior mandated by the standard now. > Every object in Ada has a specific declaration point, > initialization point, finalization point, and destruction point. There are > no exceptions. Yes, and how it that related to the issue? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de