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.1 required=5.0 tests=BAYES_00,
	PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: If not Ada, what else...
Date: Wed, 29 Jul 2015 14:42:43 -0500
Organization: Jacob Sparre Andersen Research & Innovation
Message-ID: <mpbabk$v80$1@loke.gir.dk>
References: <iomd56$c1s$1@dont-email.me>
	<7a29d3e9-d1bd-4f4a-b1a6-14d3e1a83a4d@googlegroups.com>
	<87mvz36fen.fsf@jester.gateway.sonic.net>
	<2215b44f-8a89-47c6-a4c4-52b74d2dac45@googlegroups.com>
	<f5b22bff-4191-4478-82ed-181e024c5bcd@googlegroups.com>
	<mnqs6l$mdm$2@dont-email.me>
	<9e492c82-868d-43d3-a18a-38274400e337@googlegroups.com>
	<c5e815ac-8987-44cf-b66c-c25403887e39@googlegroups.com>
	<40184feb-4053-4ac3-8eaa-c3bd9cd8a77c@googlegroups.com>
	<10272577-945f-4682-85bc-8ad47f3653ae@googlegroups.com>
	<87si8i81k2.fsf@atmarama.net>
	<e3023a92-0087-490c-8d51-daccf89a309d@googlegroups.com>
	<d17drnF4b0qU1@mid.individual.net>
 <lymvypjqdq.fsf@pushface.org>	<8076cbd0-2655-4c98-b70e-cb5f0c32e4ba@googlegroups.com>
	<e8521a43-2bbf-4970-a17b-b585d021f235@googlegroups.com>
	<mp6d4a$22n$1@loke.gir.dk>
	<5e6cb30b-5f8c-4fed-969e-3941315ecba0@googlegroups.com>
	<87si87nf8k.fsf@jester.gateway.sonic.net> <mpb0nh$9c3$1@dont-email.me>
 <877fpiom3q.fsf@jester.gateway.sonic.net> <mpb8r3$a2i$1@dont-email.me>
NNTP-Posting-Host: rrsoftware.com
X-Trace: loke.gir.dk 1438198965 32000 24.196.82.226 (29 Jul 2015 19:42:45 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Wed, 29 Jul 2015 19:42:45 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Xref: news.eternal-september.org comp.lang.ada:27145
Date: 2015-07-29T14:42:43-05:00
List-Id: <comp.lang.ada>

"Georg Bauhaus" <bauhaus@futureapps.invalid> wrote in message 
news:mpb8r3$a2i$1@dont-email.me...
> On 29.07.15 20:27, Paul Rubin wrote:
>> Björn Lundin<b.f.lundin@gmail.com>  writes:
>>> >See Ada.Containers.*
>> Will look there, but those kinds of containers are more useful with GC.
>
> See Randy Brukardt's repeated admonishment to use Ada.Containers
> precisely because they handle storage.

I'll repeat it so he doesn't have to look it up: the whole point of using 
such containers is that they handle all of the storage management for you. 
When using the containers, you don't have to (and shouldn't, IMHO) use any 
access types at all. The container element can be any non-limited type, 
which of course includes other containers.

Ada 2012 added tree and queue containers, as well as adding syntactic sugar 
for iterators and indexing, such that containers usage can look pretty much 
like using a built-in array type. (It's more complex under the covers, of 
course, but the whole idea is to hide complexity.) And the bounded forms of 
the containers gives memory certainty for applications that need that.

It would be completely unnecessary to use any GC with the Ada containers. 
You (arguably) need it when you use raw access types, and can't use subpools 
or a custom storage pool to manage the storage sensibly. That comes up 
rather rarely in Ada 2012 (unless, of course, you are writing a container 
implementation).

                                  Randy.