Groups | Search | Server Info | Login | Register
Groups > comp.lang.ada > #49665
| From | "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> |
|---|---|
| Newsgroups | comp.lang.ada |
| Subject | Re: On absurdity of collections 7.6.1 (11.1/3) |
| Date | 2021-09-30 10:07 +0200 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <sj3r7l$pla$2@gioia.aioe.org> (permalink) |
| References | <sj1ah7$7kr$1@gioia.aioe.org> <lybl4bbq19.fsf@pushface.org> <sj1i6g$7hv$1@gioia.aioe.org> <ly35pnawpp.fsf@pushface.org> |
On 2021-09-29 23:38, Simon Wright wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> On 2021-09-29 13:05, Simon Wright wrote: >>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 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
Back to comp.lang.ada | Previous | Next — Previous in thread | Next in thread | Find similar
On absurdity of collections 7.6.1 (11.1/3) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2021-09-29 11:09 +0200
Re: On absurdity of collections 7.6.1 (11.1/3) Simon Wright <simon@pushface.org> - 2021-09-29 12:05 +0100
Re: On absurdity of collections 7.6.1 (11.1/3) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2021-09-29 13:20 +0200
Re: On absurdity of collections 7.6.1 (11.1/3) Simon Wright <simon@pushface.org> - 2021-09-29 22:38 +0100
Re: On absurdity of collections 7.6.1 (11.1/3) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2021-09-30 10:07 +0200
Re: On absurdity of collections 7.6.1 (11.1/3) Simon Wright <simon@pushface.org> - 2021-09-30 09:35 +0100
Re: On absurdity of collections 7.6.1 (11.1/3) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2021-09-30 10:49 +0200
Re: On absurdity of collections 7.6.1 (11.1/3) "Randy Brukardt" <randy@rrsoftware.com> - 2021-09-30 20:37 -0500
Re: On absurdity of collections 7.6.1 (11.1/3) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2021-10-01 09:57 +0200
Re: On absurdity of collections 7.6.1 (11.1/3) "Randy Brukardt" <randy@rrsoftware.com> - 2021-09-29 19:23 -0500
Re: On absurdity of collections 7.6.1 (11.1/3) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2021-09-30 10:06 +0200
Re: On absurdity of collections 7.6.1 (11.1/3) "G.B." <bauhaus@notmyhomepage.invalid> - 2021-09-30 20:23 +0200
Re: On absurdity of collections 7.6.1 (11.1/3) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2021-09-30 20:52 +0200
Re: On absurdity of collections 7.6.1 (11.1/3) "Randy Brukardt" <randy@rrsoftware.com> - 2021-09-30 20:40 -0500
Re: On absurdity of collections 7.6.1 (11.1/3) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2021-10-01 09:57 +0200
csiph-web