Groups | Search | Server Info | Login | Register

Groups > comp.lang.ada > #49652

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

Show key headers only | View raw

"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.

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).

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.

Back to comp.lang.ada | Previous | Next — Previous 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