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!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx02.iad01.newshosting.com!newshosting.com!69.16.185.11.MISMATCH!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!nntp.club.cc.cmu.edu!micro-heart-of-gold.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 19:22:16 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <75a9f860-ad3c-49a0-b2a1-a8f1386e6ff6@x10g2000prk.googlegroups.com> <22770615-78cf-43eb-a817-0af52ddece6a@w27g2000pre.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: pcls4.std.com 1265934133 16832 192.74.137.71 (12 Feb 2010 00:22:13 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Fri, 12 Feb 2010 00:22:13 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:yQ4yQsREIEHZn+V9XEFSO6wzAiI= Xref: g2news1.google.com comp.lang.ada:9134 Date: 2010-02-11T19:22:16-05:00 List-Id: Adam Beneschan writes: > On Feb 11, 2:53�pm, Robert A Duff > wrote: > >> 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. > > But that's true even if it's nonlimited, right? Well, sort of. In the nonlimited case, the result object is copied somewhere, with adjust, and then finalized. Except that the compiler is allowed to optimize that away in some cases. In the limited case, it must not finalize the result object. >...If NLT is non- > limited, and you say (inside function NLT_Func) > > return X : NLT do > X.Component := ... > end return; > > X, which is now another name for the "anonymous result object" created > for the function call, is not finalized "when leaving the function". > It's finalized later. If you say > > Y : NLT := NLT_Func(...); > > it's finalized after being copied to Y (assuming it is not built in > place). Yeah, OK, but "when leaving the function" and "after copying to Y" are pretty much the same time. And "when Y is finalized" is a very-much-later time. The finalization rules would be the same if the above return were return X : NLT := (Component => ..., others => <>); or: return (Component => ..., others => <>); My point was just that the "build in place" requirement is invoked by limitedness, not by the syntax of the return statement. By the way, I have on my "to do" list to implement build-in-place in GNAT for NON-limited types, when possible. That's just an optimization. >...If you pass the result to some other function(s): > > Z : Type2 := Func2 (Func3 (NLT_Func (...))); > > then I believe the result object (of NLT_Func) is not finalized until > after the entire expression is evaluated, right? I don't remember the exact rules in this case. As you say, they're "nasty". ;-) - Bob