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: Thu, 30 Sep 2021 10:08:02 +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="26282"; 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:62885 List-Id: 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. > It's probably a lousy idea to share pool objects (as opposed to pool types) > amongst access types. You need these for access discriminants. > 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. >>>> 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? >>> Because these are the places that finalization (and >>> deallocation/destruction) are defined to happen. >> >> So? How exactly any of this implies that the place of Finalization can be >> in a place other than the place of deallocation? > > Deallocation is at most a convinience in Ada; it isn't even required to do > anything. So is Finialize. > OTOH, object destruction happens before the type goes away, and finalization > happens before that. That is the point here. See above, these are different objects of different types. The actual object type is alive and well (unless killed by some collection). -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de