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: Thu, 30 Sep 2021 10:07:17 +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="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 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.9.2 Xref: reader02.eternal-september.org comp.lang.ada:62884 List-Id: On 2021-09-29 23:38, Simon Wright wrote: > "Dmitry A. Kazakov" writes: > >> On 2021-09-29 13:05, Simon Wright wrote: >>> "Dmitry A. Kazakov" writes: >>> >>>> type Item_Ptr is access all Item; >>>> function New_Item >>>> ( Pool : in out Root_Storage_Pool'Class; >>>> Text : String >>>> ) return Item_Ptr; >>> What I don't see is how you can implement this, never mind any other >>> problems. >> >> A naive, but wrong due to 7.6.1 (11.1/3) nonsense, implementation would be: >> >> function New_Item >> ( Pool : in out Root_Storage_Pool'Class; >> Text : String >> ) return Item_Ptr is >> type Ptr is access Item; >> for Ptr'Storage_Pool use Pool; >> Object : Ptr := new Item (Text'Length); >> begin >> Object.Text := Text; >> return Object.all'Unchecked_Access; >> end New_Item; > > OK, that code compiles. > > What you'd need to happen when the returned Item_Ptr is freed would be > for the mechanism of the actual pool to be invoked. But Item_Ptr was > declared without any pool specified, so uses the default, and when the > returned Item_Ptr is freed it uses the default pool's mechanism. That would be another language bug, if true, because 13.11.2 is silent about that. But the first bug is that New_Item is not implementable, well it actually is, but in a very clumsy way (see my answer to Randy). > But of course what actually happens with this code is that the returned > Item_Ptr is left dangling; my test > > with P; > with System.Pool_Local; -- GNAT special > with Ada.Text_IO; use Ada.Text_IO; > procedure Test is > use P; > Pool : System.Pool_Local.Unbounded_Reclaim_Pool; > Ptr : Item_Ptr := New_Item (Pool, "hello"); > begin > Put_Line (Ptr.Text); > Free (Ptr); > end Test; > > manages flukily to print "hello" before crashing at the Free (Ptr). It should print it twice, because Finalize must be called twice. Once inside New_Item, then in Free. > I don't see how what you want can be achieved without every access type > containing a reference to the pool the object was allocated from. 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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de