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!.POSTED!not-for-mail
From: Brian Drummond <brian@shapes.demon.co.uk>
Newsgroups: comp.lang.ada
Subject: Re: Why is the destructor called multiple times after I declare an
 object?
Date: Tue, 12 Jan 2016 12:41:35 -0000 (UTC)
Organization: A noiseless patient Spider
Message-ID: <n72s9v$gi4$1@dont-email.me>
References: <293c58ac-4ebd-488a-abcc-b6e88811eec8@googlegroups.com>
	<n6v39b$efq$1@dont-email.me> <n70l9o$ecn$3@dont-email.me>
	<871t9ogevj.fsf@theworld.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 12 Jan 2016 12:41:35 -0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="da745e888d4a5182b5fda6212bbb0a63";
	logging-data="16964"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1860HtcZ//3KVfCd8eMDnHIRjK8+8dIyM4="
User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508
 git://git.gnome.org/pan2)
Cancel-Lock: sha1:34KWELRheFs5O4pmasunXyyhzcY=
Xref: news.eternal-september.org comp.lang.ada:29100
Date: 2016-01-12T12:41:35+00:00
List-Id: <comp.lang.ada>

On Mon, 11 Jan 2016 13:17:20 -0500, 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.
> 
> For nonlimited types, the compiler is free to use build-in-place if it
> can prove that it's equivalent to return-by-copy.  It's often not
> equivalent.  For example:
> 
>     X := Init;
> 
> What if Init raises an exception after partly modifying the result? In
> that case X should not be modified, so the result object of Init and X
> had better not be at the same address.

Thank you (and Simon and Brad) for the clarification. 

I had not considered the ramifications in the case of exceptions, and the 
impracticability of rolling back a partially modified object...

-- Brian