Re: Allocators for anonymous access return types

[Florian Weimer <fw@deneb.enyo.de>]

* J-P. Rosen:

> Le 31/10/2010 13:18, Florian Weimer a �crit :
>> It seems that an allocator for an anonymous accesss return type of a
>> library-level function essentially leaks memory (unless you use
>> garbage collection, of course).  Is this really the case?  I would
>> expect such objects to be deallocated by the master for the expression
>> where the return type occurs.

> Yes, but I *guess* the master is library-level, therefore it's
> deallocated only when the problem terminates.

Actually, it seems to be unspecified.  It is curious because for
unconstrained objects not created by allocators, the life-time was
clarified (I think, see my other post).

> Conclusion: don't use them, especially with allocators. Use named
> types as much as possible.

I'm trying to write type-safe variadic function which does not heavily
use the free store.

With anonymous access types, it could look like this:

package Variadic is
   
   type Variadic is tagged limited private;
   
   Start : constant access Variadic'Class;
   function "&" 
     (Left : access Variadic'Class;
      Right : String)
     return access Variadic'Class;
   
   procedure Print (Arguments : access Variadic'Class);
   
private
   
   type Variadic is tagged limited record
      Data : access String;
      Next : access Variadic'Class;
   end record;
   
   Start : constant access Variadic'Class := null;
      
end Variadic;

with Ada.Text_IO;
package body Variadic is
   
   function "&" 
     (Left : access Variadic'Class;
      Right : String)
     return access Variadic'Class
   is
   begin
      return new Variadic'(Data => new String'(Right),
			   Next => Left);
   end "&";
   
   procedure Print (Arguments : access Variadic'Class) is
      Current : access Variadic'Class := Arguments;
   begin
      while Current /= null loop
	 Ada.Text_IO.Put_Line (Current.Data.all);
	 Current := Current.Next;
      end loop;
   end Print;
end Variadic;

In this example, the allocators could use the secondary stack, I
think, but they don't (with GNAT).  I'm not sure if it is possible to
elide the string copy, though, so this is probably not what I'm after.
(My other example avoids copying, and seems to be safe according to
the ARM rules, as long as you don't declare something involving the
Unchecked_* types.  A solution based on anonymous access types might
make this violation impossible, hence my interest in them.)