Re: A simple question about the "new" allocator

[Adam Beneschan <adambeneschan@gmail.com>]

On Tuesday, August 12, 2014 4:14:16 PM UTC-7, sbelm...@gmail.com wrote:
> On Tuesday, August 12, 2014 6:34:14 PM UTC-4, Adam Beneschan wrote:
> 
> > 
> 
> > However, if Storage_Size is specified for an access type, I think that the program does have to allocate a pool just for that type, and the storage for the pool does get reclaimed when the block is left.  (13.11(18))  The difference is that when Storage_Size is specified, the expectation is that the program will allocate a contiguous block of memory of that size to be used for allocations for that access type, and that storage block can simply be reclaimed all at once.  If Storage_Size is not specified, there won't be any such contiguous block. 
> 
> > 
> 
> 
> 
> 
> 
> Since we are already lawyering up, is it not true that
> 
> 
> 
> procedure main is 
> 
> begin 
> 
>   loop 
> 
>     declare 
> 
>       Test : access Positive := new Positive; 
> 
>     begin 
> 
>       null; 
> 
>     end; 
> 
>   end loop; 
> 
> end main;
> 
> 
> 
> is (advised to be) equivalent to this:
> 
> 
> 
> procedure main is 
> 
> begin 
> 
>   loop 
> 
>     declare
> 
>       p : Some_Default_Pool;
> 
>       type T is access Positive;
> 
>       for T'Storage_Pool use p;
> 
>       Test : T := new Positive; 
> 
>     begin 
> 
>       null; 
> 
>     end; 
> 
>   end loop; 
> 
> end main;
> 
> 
> 
> based on 13.11~25.4/2 ("Otherwise, a default storage pool should be created at the point where the anonymous access type is elaborated") and then consequently reclaimed when p goes out of scope?

There's nothing that says *any* storage pool has to have its memory reclaimed, ever.  Suppose you declare your own:

    declare
        type My_Storage_Pool (Size : Storage_Count) is new Root_Storage_Pool
            with record ... end record;
        ... override Allocate, Deallocate, Storage_Size, Initialize, Finalize
        Pool : My_Storage_Pool;
        type T is access Positive;
        for T'Storage_Pool use Pool;
    begin
        ...
    end;

So when Pool goes out of scope, you'd think the memory used by Pool will be reclaimed, right?

Not necessarily.  Nothing says Pool has to have the memory used for allocation as part of the object.  The Initialize routine could allocate a byte array on the normal heap.  If this byte array isn't deallocated by My_Storage_Pool's Finalize routine, then the storage won't be reclaimed.

This isn't really relevant to the real world, since hopefully nobody would write My_Storage_Pool like that.  The point, here, is that you and others seem to be trying to infer an RM requirement (or "Implementation Advice"-type strong suggestion) based on some passages here and there, but in this case you're basing it on an assumption that isn't true.  That is, you're assuming that a "storage pool" that's declared in a local scope will have its storage reclaimed when the scope is exited.  I'm trying to demonstrate that this assumption is false, and thus your logic rests on a false assumption.

None of this says that you shouldn't expect the storage to be reclaimed, and you're certainly within your rights to complain to your compiler vendor if it isn't.  But I just don't see an RM requirement.  To me, the situation is what it's always been, since Ada 83: a program that does its own allocation is responsible for deallocating things itself; and, with the exception of specifying Storage_Size, in which case the program is expected to reserve a block of memory, there's no magic trick to get Ada to deallocate things for you.  At least, there's no guaranteed, portable magic trick.

                              -- Adam