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: Tue, 21 Sep 2021 08:28:13 +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="35260"; 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:62801 List-Id: On 2021-09-21 02:37, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:si77kd$rka$1@gioia.aioe.org... > ... >> 1. It is a massive overhead in both memory and performance terms with no >> purpose whatsoever. I fail to see where that sort of thing might be even >> marginally useful. > > The classic example of Finalization is file management on a simple kernel (I > use CP/M as the example in my head). CP/M did not try to recover any > resources on program exit, it was the programs responsibility to recover > them all (or reboot after every run). If you had holes in finalization, you > would easily leak files and since you could only open a limited number of > them at a time, you could easily make a system non-responsive. This is why system resources are handled by the OS rather than by the application. But I do not see how this justifies "collections." >> 2. What is worse that a collection is not bound to the pool. It is to an >> access type, which may have a narrower scope. So the user could declare an >> unfortunate access type, which would corrupt objects in the pool and the >> pool designer has no means to prevent that. > > Pools are extremely low-level things that cannot be safe in any sense of the > word. A badly designed pool will corrupt everything. Using a pool with the > "wrong" access type generally has to be programmed for (as I answered > earlier, if I assume anything about allocations, I check for violations and > do something else.) And a pool can be used with many access types; many > useful ones are. This is also true, but again unrelated to the point that tying finalization *without* deallocation to a pointer type is just wrong, semantically on any abstraction level. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de