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,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Thread: 103376,4fe0da28a190b761
X-Google-Attributes: gid103376,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII
Path: 
 g2news1.google.com!postnews.google.com!p31g2000prf.googlegroups.com!not-for-mail
From: sjw <simon.j.wright@mac.com>
Newsgroups: comp.lang.ada
Subject: Re: Storage management
Date: Sat, 1 Nov 2008 15:36:49 -0700 (PDT)
Organization: http://groups.google.com
Message-ID: 
 <e7a52e20-16e1-4810-b13f-59dc63183cdf@p31g2000prf.googlegroups.com>
References: <87fxmbog1u.fsf@mid.deneb.enyo.de>
NNTP-Posting-Host: 62.49.19.209
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Trace: posting.google.com 1225579009 17602 127.0.0.1 (1 Nov 2008 22:36:49
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Sat, 1 Nov 2008 22:36:49 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: p31g2000prf.googlegroups.com; posting-host=62.49.19.209;
	posting-account=_RXWmAoAAADQS3ojtLFDmTNJCT0N2R4U
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_5; en-us)
	AppleWebKit/525.18 (KHTML,
 like Gecko) Version/3.1.2 Safari/525.20.1,gzip(gfe),gzip(gfe)
Xref: g2news1.google.com comp.lang.ada:2553
Date: 2008-11-01T15:36:49-07:00
List-Id: <comp.lang.ada>

On Nov 1, 11:13=A0am, Florian Weimer <f...@deneb.enyo.de> wrote:
> What is the current state of the art with regard to programmer support
> for storage management?
>
> With GNAT, Ada.Finalization adds tons of run-time calls to deal with
> abort deferral (even with pragma Restrictions (No_Abort_Statements)),
> puts the object on some sort of list, and does some secondary stack
> allocations which I don't understand. =A0Clearly, this is not supposed
> to be used in performance-critical code, so I doubt it can be used for
> a generic smart pointer implementation. =A0(Object allocation in inner
> loops is generally a bad idea, but this overhead is also incurred when
> copying smart pointers around.)

It has to depend on how fast a processor you can afford to buy for
your application. Here (2.4 GHz Macbook Pro, GCC 4.3.0) it takes 150
ns to allocate/free a character vs 1050 ns for the (rough) equivalent
using a BC smart pointer.