Allocators for anonymous access return types

Allocators for anonymous access return types

[Florian Weimer]

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.

Re: Allocators for anonymous access return types

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

I said "I guess", because few people (even in the ARG!) really
understand accessibility levels. Moreover, there is no way to
unchecked-deallocate anonymous access types.

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

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a d�m�nag� / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: Allocators for anonymous access return types

[Florian Weimer]

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

Re: Allocators for anonymous access return types

[J-P. Rosen]

Le 31/10/2010 14:23, Florian Weimer a �crit :
>> 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;
My first reaction would be to define here:
     type Variadic access is access Variadic;

But you mention:
> (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.)
I don't know what you mean by Unchecked_* types. I guess you mean no use
of Unchecked_Conversion? Better use a restriction then.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a d�m�nag� / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: Allocators for anonymous access return types

[Florian Weimer]

* J-P. Rosen:

>>    type Variadic is tagged limited private;
> My first reaction would be to define here:
>      type Variadic access is access Variadic;

"type Variadic_Access is access Variadic;"?

It's difficult to get exception-safe code that way.  Deallocating the
parameters in Print is not sufficient because you leak memory when
constructing one of the arguments raises an exception.

> But you mention:
>> (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.)

> I don't know what you mean by Unchecked_* types. I guess you mean no use
> of Unchecked_Conversion? Better use a restriction then.

Oops, I was referring to the Ref type in
<87fwvn51mz.fsf@mid.deneb.enyo.de> (it's called
Unchecked_Parameter_Reference in the actual code, and for good
reason).