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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Received: by 2002:a0c:a0e6:: with SMTP id c93mr12068113qva.109.1567375953550; Sun, 01 Sep 2019 15:12:33 -0700 (PDT) X-Received: by 2002:aca:5c3:: with SMTP id 186mr16491668oif.37.1567375953147; Sun, 01 Sep 2019 15:12:33 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!o24no814270qtl.0!news-out.google.com!q13ni13qtn.0!nntp.google.com!o24no814255qtl.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 1 Sep 2019 15:12:32 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=109.136.87.156; posting-account=nuF4hQoAAADjc2KKS1rOkzxWWEmaDrvx NNTP-Posting-Host: 109.136.87.156 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <642d37c8-28f4-4a4f-8446-56a09d893e7c@googlegroups.com> Subject: Re: Question about finalization of local object returned from the function From: darkestkhan Injection-Date: Sun, 01 Sep 2019 22:12:33 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader01.eternal-september.org comp.lang.ada:57096 Date: 2019-09-01T15:12:32-07:00 List-Id: 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. Not to mention that extended return has some extra uses as well - I use it now and then for doing cleanup before return, i.e.: function Baz (...) return T is ... begin ... return Result : constant T := ... do ... -- and some cleanup code (free temporary variables / close files) end return; end Baz; Instead of declaring result in declare block and then cleaning up and returning it. I just find this way to be more... descriptive, of what is actually happening. Admittedly cleanup at the end of *function* is very infrequent. Thanks for confirming my understanding of this situation. -- darkestkhan