Groups | Search | Server Info | Login | Register


Groups > comp.lang.ada > #49665

Re: On absurdity of collections 7.6.1 (11.1/3)

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar


Thread

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