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: 103376,68536605ede13a20
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.68.75.170 with SMTP id d10mr20749921pbw.6.1325029896690;
        Tue, 27 Dec 2011 15:51:36 -0800 (PST)
MIME-Version: 1.0
Path: 
 lh20ni71740pbb.0!nntp.google.com!news2.google.com!goblin1!goblin.stu.neva.ru!news.tornevall.net!news.jacob-sparre.dk!pnx.dk!jacob-sparre.dk!ada-dk.org!.POSTED!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: GNAT - return by anonymous access
Date: Tue, 27 Dec 2011 17:51:33 -0600
Organization: Jacob Sparre Andersen Research & Innovation
Message-ID: <jddlm7$euj$1@munin.nbi.dk>
References: 
 <784c67eb-a542-41b0-b23d-fca1234e56b2@n10g2000vbg.googlegroups.com>
 <jcoidj$lpr$1@munin.nbi.dk>
 <b896b012-1f49-494c-a585-3d37a7c0965a@q9g2000yqe.googlegroups.com>
 <jcr551$2jq$1@munin.nbi.dk>
 <95f3b0fc-af24-4ace-afc9-227e8893ea99@n6g2000vbg.googlegroups.com>
 <91845790-2447-4b2c-a6b5-1a52557c8c17@d10g2000vbk.googlegroups.com>
 <4f78ef9f-ca8d-43ef-ab71-0f775fbeebd9@z19g2000vbe.googlegroups.com>
 <6e5ee357-7409-4974-917c-d7236c782d31@h11g2000yqd.googlegroups.com>
 <8a7d4dc1-69e5-479f-84a3-5c9c7bdd9aae@j10g2000vbe.googlegroups.com>
 <jd0jj3$1t9$1@munin.nbi.dk>
 <bc9926b7-e35b-43a1-adf7-82a936141dd6@m7g2000vbc.googlegroups.com>
NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net
X-Trace: munin.nbi.dk 1325029895 15315 69.95.181.76 (27 Dec 2011 23:51:35 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Tue, 27 Dec 2011 23:51:35 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Date: 2011-12-27T17:51:33-06:00
List-Id: <comp.lang.ada>

"Simon Belmont" <sbelmont700@gmail.com> wrote in message 
news:bc9926b7-e35b-43a1-adf7-82a936141dd6@m7g2000vbc.googlegroups.com...
On Dec 22, 7:56 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
...
>However, it's good
>to know that using a 'coextension' has such counter-intuitive
>operation.  I assumed that it would be functionally equivilent to
>simply declaring the object previously and initializing it with the
>exiting object, and certainly not different to the extent of, if I
>understand you correctly, not even using the heap at all.

A 'coextension' is supposed to have the same lifetime as the enclosing 
object. That means that if the enclosing object is declared on the stack, 
then the coextension should be allocated (at least logically) on the stack. 
Adding to this brew is the fact that limited objects are built-in-place, so 
the return statement you wrote is really creating the new object somewhere 
else (quite possibly on the stack). This requires a lot of shuffling, so it 
is not surprising that it can get buggy.

Janus/Ada allocates some dynamically sized objects on the heap (even when 
they logically are on the stack) and cleans them up when the stack is 
popped. So it isn't quite as hard for us (but it still is a struggle to get 
such things on the right list, and not one that is too inner). But for 
implementations that use a secondary stack for all such objects, this must 
be a nightmare (either leaking memory or freeing it too soon seems to be 
required).

                                   Randy.