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=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed-00.mathworks.com!nntp.TheWorld.com!.POSTED!not-for-mail
From: Robert A Duff <bobduff@shell01.TheWorld.com>
Newsgroups: comp.lang.ada
Subject: Re: Mission-Critical Design: Ada.Unchecked_Deallocation vs Garbage
 Collection
Date: Wed, 23 Jul 2014 18:07:10 -0400
Organization: The World Public Access UNIX, Brookline, MA
Message-ID: <wccppgv3f1t.fsf@shell01.TheWorld.com>
References: <de300b26-804d-4c9a-8aea-e840160b735d@googlegroups.com>
 <755is9pqec24if5ecnatvc05uindaphd40@4ax.com>
NNTP-Posting-Host: shell01.theworld.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: pcls7.std.com 1406153198 4860 192.74.137.71 (23 Jul 2014 22:06:38
 GMT)
X-Complaints-To: abuse@TheWorld.com
NNTP-Posting-Date: Wed, 23 Jul 2014 22:06:38 +0000 (UTC)
User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix)
Cancel-Lock: sha1:gpcSStmS9l0bBtW1qEyhK06KAgs=
Xref: news.eternal-september.org comp.lang.ada:21167
Date: 2014-07-23T18:07:10-04:00
List-Id: <comp.lang.ada>

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

> On Thu, 17 Jul 2014 23:17:48 -0700 (PDT), NiGHTS <nights@unku.us> declaimed
> the following:
>
>>In mission-critical design applications, do they favor garbage collectors or the unchecked deallocation?
>>
> 	Based upon the examples I've seen at work (flight management systems):
> NEITHER...
>
> 	Any dynamic memory gets allocated during the initialization step (based
> on some configuration "file" to identify how much of each component to
> create), and once that completes the only "dynamic" memory is the stack
> (and not even the secondary stack used in some operations -- like run-time
> string concatenation; no: put("string " & integer'image(val) & " more"); )

That particular example can be done without using the secondary stack in
the latest version of GNAT.  All the temps are allocated on the primary
stack, with compile-time-known size.  The length of X&Y is equal to the
sum of the lengths of X and Y.  The maximum length of the 'Image result is 11.

Take a look at the output of -gnatD if you want to see how that works.

- Bob