Re: Initialization and Finalization of limited object "returned" by a function

[Adam Beneschan <adam@irvine.com>]

On Feb 12, 1:27 am, "Alex R. Mosteo" <alejan...@mosteo.com> wrote:

> 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.

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 := <blahblah>;
      Result.Component2 := <blahblah>;
      return Result;
   end;

   function Func2 return Rec is
   begin
      return Result : Rec do
         Result.Component1 := <blahblah>;
         Result.Component2 := <blahblah>;
      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