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!mx02.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!reality.xs3.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: Why is the destructor called multiple times after I declare an
 object?
Date: Mon, 11 Jan 2016 17:44:41 -0600
Organization: JSA Research & Innovation
Message-ID: <n71epa$b1h$1@loke.gir.dk>
References: <293c58ac-4ebd-488a-abcc-b6e88811eec8@googlegroups.com>
 <n6v39b$efq$1@dont-email.me> <n70l9o$ecn$3@dont-email.me>
 <871t9ogevj.fsf@theworld.com> <n715oq$fae$1@gioia.aioe.org>
NNTP-Posting-Host: rrsoftware.com
X-Trace: loke.gir.dk 1452555882 11313 24.196.82.226 (11 Jan 2016 23:44:42 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Mon, 11 Jan 2016 23:44:42 +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:29094
Date: 2016-01-11T17:44:41-06:00
List-Id: <comp.lang.ada>

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:n715oq$fae$1@gioia.aioe.org...
> On 2016-01-11 19:17, Bob Duff wrote:
>> Brian Drummond <brian@shapes.demon.co.uk> writes:
>>
>>> Somehow I expected "extended return" to allocate space and "build in
>>> place" during the execution of the return statement.
>>
>> Build-in-place is done for return of immutably-limited types,
>> whether or not the extended return syntax is used.
>
> But you can leave one return statement on an exception, catch the 
> exception, and then return through another return statement, with other 
> discriminants and even other type of the result (if it is class-wide).
>
> Therefore the result can be potentially allocated and reallocated any 
> number of times. In which sense is this behavior 'in-place'?

"Build-in-place" means simply that there is no temporary object, the object 
is created directly in its final resting place (that is the memory where it 
will live during its existence).

Whatever amount of effort it takes to figure out that final resting place is 
not part of the equation.

For many situations (and implementation models), the size of the result 
object will not change regardless of discriminants chosen, so the sort of 
thing you describe above cannot happen. For assignments to most existing 
objects, the discriminants/tag cannot be changed, and 6.5(24/3) allows the 
Constraint_Error exception to be raised early in scenarios like the one you 
lay out. (Such an exception cannot be handled within the function, as it 
happens at the call-site.) If the discriminants are mutable, the compiler 
already has to have some mechanism for changing them [either by using 
allocate-to-the-max or reallocation], and build-in-place uses that same 
mechanism, without the temporary. You'd get the same behavior when assigning 
some other object as with a build-in-place function.)

                                                 Randy.