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=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,57f8540942f8e060 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news2.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!nx01.iad01.newshosting.com!newshosting.com!198.186.194.249.MISMATCH!transit3.readnews.com!news-xxxfer.readnews.com!news-out.readnews.com!transit4.readnews.com!panix!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Initialization and Finalization of limited object "returned" by a function Date: Thu, 11 Feb 2010 17:53:13 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <75a9f860-ad3c-49a0-b2a1-a8f1386e6ff6@x10g2000prk.googlegroups.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: pcls6.std.com 1265928781 31231 192.74.137.71 (11 Feb 2010 22:53:01 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Thu, 11 Feb 2010 22:53:01 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:zDn4wxUc28gEKvPyNjTTQroWFCw= Xref: g2news1.google.com comp.lang.ada:9120 Date: 2010-02-11T17:53:13-05:00 List-Id: Adam Beneschan writes: > On Feb 11, 11:10�am, Robert A Duff > wrote: >> Adam Beneschan writes: >> > But more simply, as I understand it: (1) When you have an extended >> > return, the return object is used as the anonymous object that holds >> > the function result at the point of the function call, so it's not >> > finalized until the caller is done with the anonymous object; and (2) >> > when the object is built in place, the anonymous object "mutates into" >> > the new object and is not finalized (7.6(17.7/3)). �So yes, no >> > finalization should be done until X goes out of scope. >> >> Just to be clear: There's nothing particularly special about >> extended return statements, other than the fact that they >> provide a name for the result. � > > That last is an important distinction, however. A function call > involves (conceptually) an anonymous object. For a normal return (for > a non-limited type): > > return Some_Expression; > > Some_Expression is computed and then assigned into the anonymous > object. This assignment involves an Adjust. Then, at some point, > whatever objects went into creating Some_Expression will get finalized > when the function exits. If Some_Expression is a local variable, for > instance, that variable will get finalized. If some other temporary > needs to be created in order to hold the value of Some_Expression, > that temporary will be finalized. That's right for nonlimited types, but my point is that it is not right for limited types. For limited types, "return Some_Expression;" and "return Result : constant T := Some_Expression;" have identical effect. Adjust is not called (there is no Adjust in the limited case), and the result object is not finalized when leaving the function. Note that in the limited case, Some_Expression cannot be the name of a local variable -- it can be a function call or an aggregate. So we can have a whole chain of calls. E.g.: X : T := A(...); -- T is limited and A says "return B(...);", and B says "return C(...);" and C says "return T'(agg, reg, ate);" -- there's only one result object. The aggregate inside C is built directly in variable X. It is not finalized when leaving C, B, or A. > For an extended return, > > return R : T; > R is not a local variable, and it isn't "assigned" into the anonymous > object; thus, there's no Adjust, and R is not finalized when the > function returns (but the anonymous object will be finalized later, > except when it mutates into some other object). I think that's the > point of the nasty language in 3.10.2(10.1). Which is another way of > saying that R is a name for the result (as you said), not a distinct > object that gets copied to the result. It doesn't matter whether the result object has a name or not. What matters is whether it's limited -- in the limited case, the result object is NOT finalized when leaving the function. >...I thought it would be helpful > to point it out---not to you, but to other readers. It's hardly a > trivial difference, and it's an important one to understand when > adjusts and finalizations are involved. Anyway, I hope this helps > someone. Well, umm... ;-) - Bob