From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,b1a1671673a84c5e
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII
Path: 
 g2news1.google.com!news2.google.com!news3.google.com!feeder.news-service.com!tudelft.nl!txtfeed1.tudelft.nl!news.buerger.net!LF.net!news.enyo.de!not-for-mail
From: Florian Weimer <fw@deneb.enyo.de>
Newsgroups: comp.lang.ada
Subject: Re: Allocators for anonymous access return types
Date: Sun, 31 Oct 2010 14:23:50 +0100
Message-ID: <87d3qq1ont.fsf@mid.deneb.enyo.de>
References: <87ocaa1rph.fsf@mid.deneb.enyo.de>
	<iajof0$fqn$1@news.eternal-september.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: idssi.enyo.de 1288531430 1411 172.17.135.6 (31 Oct 2010 13:23:50 GMT)
X-Complaints-To: news@enyo.de
Cancel-Lock: sha1:JwHUi7eydgxfHiRmN2nLgpvdfDA=
Xref: g2news1.google.com comp.lang.ada:15041
Date: 2010-10-31T14:23:50+01:00
List-Id: <comp.lang.ada>

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