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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,6dcdd5b561500c28
X-Google-Attributes: gid103376,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news4.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Sat, 17 Jan 2009 20:07:33 +0100
From: Georg Bauhaus <see.reply.to@maps.futureapps.de>
Reply-To: rm.tsoh-bauhaus@maps.futureapps.de
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: smart pointer dangerous (no -> operator)
References: <gkpluq$vda$1@online.de>
 <a8go9gb0a60q.wypnft0gfg98$.dlg@40tude.net>
 	<49707299$0$32667$9b4e6d93@newsspool2.arcor-online.net>
 <c18df438-7a69-4c63-9015-d961a55c9144@v39g2000pro.googlegroups.com>
In-Reply-To: 
 <c18df438-7a69-4c63-9015-d961a55c9144@v39g2000pro.googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID: <49722c75$0$31341$9b4e6d93@newsspool4.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 17 Jan 2009 20:07:33 CET
NNTP-Posting-Host: bb08f0c6.newsspool4.arcor-online.net
X-Trace: 
 DXC=o@Km;B]HXkCWDmlTRbh@=I4IUK<Cl32<A4Fo<]lROoRA^YC2XCjHcbITV61TSH=0EOA:ho7QcPOVC^^6?m0T2kXGJcSTJC8?kGA
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.ada:4388
Date: 2009-01-17T20:07:33+01:00
List-Id: <comp.lang.ada>

Maciej Sobczak wrote:
> On 16 Sty, 12:42, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote:
> 
>> Frequently overlooked, I think, Ada has nested scopes, useful
>> in many ways here.
> [...]
> 
> The problem is that in the majority of cases the whole point of
> creating something dynamically (rather than on the stack) is to use it
> in some other scope - outside of where it was created.

Yes, local objects do not always work, even if the location
is spanning vast areas of the program. While you can have scopes
nested in scopes nested in scopes next to a neighboring nested scope,
nicely making types and objects local or global as
desired, this is not always a (satisfactory) solution.

> In your example the only motivation for allocating the object
> dynamically would be to trade off stack space for heap space. Are
> there any others?

None that I can think of. But being able to confine objects to
scopes and at the same time  control their lifetimes using scopes
can make some tricky pointer programming patterns unnecessary that
might otherwise be necessary, namely in case you use an allocator
of a library level pointer type. (GNAT makes us prefer allocators
for larger objects because of an implementation choice, AFAIK...)