* Question about finalization of local object returned from the function @ 2019-08-28 22:36 darkestkhan 2019-08-29 1:45 ` Brad Moore 0 siblings, 1 reply; 5+ messages in thread From: darkestkhan @ 2019-08-28 22:36 UTC (permalink / raw) 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? As far as I can understand from the standard - yes, Foo would get finalized. Also if Foo was just a normal record type with controlled components those components would be finalized as well. But I am not fully confident that my understanding of this is correct... Thanks, darkestkhan ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Question about finalization of local object returned from the function 2019-08-28 22:36 Question about finalization of local object returned from the function darkestkhan @ 2019-08-29 1:45 ` Brad Moore 2019-09-01 18:34 ` Stephen Leake 0 siblings, 1 reply; 5+ messages in thread From: Brad Moore @ 2019-08-29 1:45 UTC (permalink / raw) 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? > > As far as I can understand from the standard - yes, Foo would get finalized. Also if Foo was just a normal record type with controlled components those components would be finalized as well. > > But I am not fully confident that my understanding of this is correct... > > Thanks, > darkestkhan 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. Note if the object is a Limited_Controlled type, and the extended return syntax is used, then the result object is said to be "built-in-place" directly into the result variable. The object is not finalized until the result variable is finalized. This allows a function returning a limited type to, for example, initialize a variable of a limited type. Brad ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Question about finalization of local object returned from the function 2019-08-29 1:45 ` Brad Moore @ 2019-09-01 18:34 ` Stephen Leake 2019-09-01 22:12 ` darkestkhan 0 siblings, 1 reply; 5+ messages in thread From: Stephen Leake @ 2019-09-01 18:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Question about finalization of local object returned from the function 2019-09-01 18:34 ` Stephen Leake @ 2019-09-01 22:12 ` darkestkhan 2019-09-02 17:14 ` Jeffrey R. Carter 0 siblings, 1 reply; 5+ messages in thread From: darkestkhan @ 2019-09-01 22:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Question about finalization of local object returned from the function 2019-09-01 22:12 ` darkestkhan @ 2019-09-02 17:14 ` Jeffrey R. Carter 0 siblings, 0 replies; 5+ messages in thread From: Jeffrey R. Carter @ 2019-09-02 17:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-09-02 17:14 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-08-28 22:36 Question about finalization of local object returned from the function darkestkhan 2019-08-29 1:45 ` Brad Moore 2019-09-01 18:34 ` Stephen Leake 2019-09-01 22:12 ` darkestkhan 2019-09-02 17:14 ` Jeffrey R. Carter
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox