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!postnews.google.com!q2g2000pre.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Initialization and Finalization of limited object "returned" by a function Date: Fri, 12 Feb 2010 08:43:06 -0800 (PST) Organization: http://groups.google.com Message-ID: References: <75a9f860-ad3c-49a0-b2a1-a8f1386e6ff6@x10g2000prk.googlegroups.com> <7tkl8mF2qbU1@mid.individual.net> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1265992986 28418 127.0.0.1 (12 Feb 2010 16:43:06 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 12 Feb 2010 16:43:06 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: q2g2000pre.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618),gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:9172 Date: 2010-02-12T08:43:06-08:00 List-Id: On Feb 12, 1:27=A0am, "Alex R. Mosteo" wrote: > I remember an old thread I started on return by reference. My question th= en > 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 t= he > 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. Maybe. Doing it this way could remove one copy, according to the language semantics. However, the compiler can of course generate any code it wants, if it has the effect that the language semantics demand. I did try this with one compiler: function Func1 return Rec is Result : Rec; begin Result.Component1 :=3D ; Result.Component2 :=3D ; return Result; end; function Func2 return Rec is begin return Result : Rec do Result.Component1 :=3D ; Result.Component2 :=3D ; end return; end Func2; With optimization turned off, Func2 did generate one less copy. However, the generated code passed the address of a "result object" as a parameter to the functions, and this means Func2 would be using indirection through this address to set the components, while Func1 would be setting them on the local stack frame. Whether this indirection adds any cycles, I don't know. I'd guess that it wouldn't, but this could depend on the processor. But, assuming that there are no controlled components, there's nothing preventing the compiler from generating the same code for Func1 as for Func2, and eliminating the extra copy. So I guess that using extended return might be worth a try---try it both ways, and see if the compiler generates faster code. If there are controlled components, then the semantics are different, because Func1 will have to assign Result to the "result object" (requiring an "adjust" operation) and then finalize Result (requiring a "finalize" operation). The language gives compilers permission to remove adjust/finalize pairs in some cases, but I don't know if this is one of those cases. If not, then this is a case where extended return will definitely benefit you. -- Adam