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-7-bit Path: g2news1.google.com!news4.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Alex R. Mosteo" Newsgroups: comp.lang.ada Subject: Re: Initialization and Finalization of limited object "returned" by a function Followup-To: comp.lang.ada Date: Fri, 12 Feb 2010 10:27:03 +0100 Message-ID: <7tkl8mF2qbU1@mid.individual.net> References: <75a9f860-ad3c-49a0-b2a1-a8f1386e6ff6@x10g2000prk.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Trace: individual.net EeMhB8sSwGMRCexw6gCjWwZxsMZ87qOwwWTUjcHyOpgQXkOEA= Cancel-Lock: sha1:p8ALMcUrukp1SI3qHa/8Q307YWM= User-Agent: KNode/4.4 Xref: g2news1.google.com comp.lang.ada:9163 Date: 2010-02-12T10:27:03+01:00 List-Id: Adam Beneschan wrote: > 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. > > 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. 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. I remember an old thread I started on return by reference. My question then was if gnat was clever enough to optimize away copies in returned values used as constants, specifically using the container library. The answer empirically found was that it wasn't. While not the same thing as a C++ return by constant reference, if I interpret you correctly, this kind of return X : T; removes one copy of the object in the returning machinery, by using the destination as in-place receptacle, right? If so, I wonder if it's worth the attempt to use this in some speed critical code.