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: On absurdity of collections 7.6.1 (11.1/3) Date: Fri, 1 Oct 2021 09:57:35 +0200 Organization: Aioe.org NNTP Server Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: gioia.aioe.org; logging-data="30393"; 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:62911 List-Id: On 2021-10-01 03:37, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:sj3r7l$pla$2@gioia.aioe.org... > ... >> Yes, every general access type that permits instantiation of >> Unchecked_Dellocation must indicate the target object's pool, directly, >> e.g. per fat pointer, or indirectly by some other schema. I see nothing in >> RM that allows a different implementation. But it is could be a bug by >> omission and I am not a language lawyer anyway. > > Each access type has only one pool, and all allocations and deallocations > for that access type use that pool. You can see at RM 13.11(13) that you can > retrieve the storage pool of T, that wouldn't be possible if it could have > multiple pools. Allocation for T uses T'Storage_Pool (RM 13.11(16)), and > deallocation for T also uses T'Storage_Pool (13.11.2(9/3) - I see this > wording isn't as clear as it could be, but "the storage_pool" here is the > one for the type T. It is clear, however, from 13.11.2(16/3) that it is > erroneous to deallocate an object for some other pool than the pool of the > access type passed to the instance of Unchecked_Deallocation. At least instantiations of Unchecked_Deallocation should be illegal with general access. > Surely no one would expect the pool to be associated with the object -- it > would be impossible to interface to C or most other languages that way. Note > that GNAT insists that all access types are C-compatible. Normally you cannot allocate C objects intended to be freed from C using Ada allocator. This is a common mistake of binding designers which promptly crashes the program. But I see no problem here, especially because the access type must have C convention anyway. > As I've said repeatedly, if you want the behavior of multiple pools with a > single access type, you have to use the subpool mechanism somehow. Honestly I still try to find a useful case for subpools. It is nothing that could not be easily implemented using existing pools or might help fighting off collections etc. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de