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!.POSTED!not-for-mail From: "Jeffrey R. Carter" Newsgroups: comp.lang.ada Subject: Re: Question about finalization of local object returned from the function Date: Mon, 2 Sep 2019 19:14:24 +0200 Organization: Also freenews.netfront.net; news.tornevall.net; news.eternal-september.org Message-ID: References: <642d37c8-28f4-4a4f-8446-56a09d893e7c@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Mon, 2 Sep 2019 17:14:24 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="ef20cad3b665086301dbe642272197d2"; logging-data="14025"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/7VIoefinzhOpoljHXl0lA0CEibaCQBRo=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 Cancel-Lock: sha1:kTYZeMpE+FpSVw/2EamcZkAL+L0= In-Reply-To: <642d37c8-28f4-4a4f-8446-56a09d893e7c@googlegroups.com> Content-Language: en-US Xref: reader01.eternal-september.org comp.lang.ada:57097 Date: 2019-09-02T19:14:24+02:00 List-Id: On 9/2/19 12:12 AM, darkestkhan wrote: > On Sunday, September 1, 2019 at 6:34:07 PM UTC, Stephen Leake wrote: >> On Wednesday, August 28, 2019 at 6:45:16 PM UTC-7, Brad Moore wrote: >>> On Wednesday, August 28, 2019 at 4:36:38 PM UTC-6, darkestkhan wrote: >>>> Given a function returning controlled type: >>>> >>>> function Bar return T is >>>> Foo : T; >>>> begin >>>> ... >>>> return Foo; >>>> end Bar; >>>> >>>> would Foo be finalized upon end of the function? >>>> >>> >>> Yes Foo is finalized upon end of the function, but not before copying the >>> object to a temporary result object which is returned to the caller. The temporary is finalized also after being assigned to the result object. >>> In other words, the expected result is returned to the caller, and the Foo object on the stack is also properly finalized. >>> >> >> However, the compiler is free to optimize away any of these steps, as long as the net effect is preserved. >> >> To expand on Brad's comment about the extended return statement, consider: >> >> function Bar return T is >> begin >> return Foo : T do >> ... >> end return; >> end Bar; >> >> then 'Foo' is actually the object that the client has declared/allocated. For example: >> >> declare >> A : T := Bar; >> begin >> ... >> >> "Foo" is actually "A", so no temporary objects are required. >> >> I don't think Limited_Controlled is required for this to happen; ARM 6.5 (24/3) mentions "built in place", but not Limited_Controlled. Also ARM 7.6 (17.1/3) gives the conditions where "built in place" is required. >> >> -- Stephe > > That is correct - "built in place" semantics has more uses than just > for limited types, although it does make working with limited types > far simpler. Maybe I'm misreading this, but it sounds to me as if those posting after Moore are saying that the language requires build in place when an extended return statement is used. It doesn't. The language only requires that "immutably limited" types and aggregates of controlled types be built in place. Note that aggregates of non-limited controlled types are returned without using extended return, but still require build in place. Other types may be returned through assignment, as Moore described, even if an extended return is used. A compiler is free to do build in place for other types, but not required to. -- Jeff Carter "The competent programmer is fully aware of the limited size of his own skull." Edsger Dijkstra 159