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,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Thread: 103376,4e04f7888d82ca71
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news3.google.com!news2.volia.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: "Alex R. Mosteo" <devnull@mailinator.com>
Newsgroups: comp.lang.ada
Subject: Re: Efficiency of returning big objects
Date: Tue, 26 Sep 2006 09:43:32 +0200
Message-ID: <4ns40eFbqlnqU1@individual.net>
References: <4npvh0FbgbuhU1@individual.net>
 <1159230803.296443.27880@m7g2000cwm.googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
X-Trace: individual.net DkkrZcl7cr+p4Uy4AbNbfA1ZkkCWI5kG7WyModijQsyR6vfBk=
User-Agent: KNode/0.10.4
Xref: g2news2.google.com comp.lang.ada:6745
Date: 2006-09-26T09:43:32+02:00
List-Id: <comp.lang.ada>

Adam Beneschan wrote:

> Alex R. Mosteo wrote:
>> Hello,
>>
>> I had a concern over the efficiency of returning big (tagged) types......
> 
>> Now, in C++ I would force this behavior explicitly returning references
>> (I guess this is the usual practice, but I'm not sure). In Ada, I have no
>> idea how to match this efficient behavior.
>>
>> So, what do you think? Is there some error in my reasoning or testbed? Is
>> this a particular shortcoming of this compiler (gnat gpl 2006), or I'm
>> overlooking something that makes this very non-trivial to implement?
> 
> If I'm understanding you correctly, in your original program, you'd
> like it if Create simply returned a pointer to Borg, and then the
> parameter to Check used the pointer to Borg, and no copying would be
> done.  But then the following program wouldn't work right.  Note that
> according to the Ada rules, since the function Create is *not*
> return-by-reference, the Ada semantics indicate that the result of
> Create is an anonymous object (6.5(21)); therefore, Borg and Y are not
> supposed to denote the same object, and the rule about distinct access
> paths (6.2(12)) doesn't apply to the example below.  I think that
> expecting a compiler to figure out what's going on, so that it wouldn't
> optimize the copy away in my example but *would* optimize it away in
> yours, may well be too much to ask.

Yep, the more I think about it and coupled with the rules you and others
have mentioned are convincing me that this is no way so obvious as I had
thought in principle.

Now that you name it I was once bitten by the distinct access path
details... there was no error in the compiler but in my code, but it didn't
do the realization of it less painful :( Alas, learning the hard way. It
never ceases to amaze me how many things are explicitly considered and
determined in the ARM.

> 
>                               -- Adam
> 
> 
> with Ada.Calendar; use Ada.Calendar;
> with Ada.Text_Io;  use Ada.Text_Io;
> procedure Ref is
> 
>    type Big_Thing is array (1 .. 64_000) of Character;
> 
>    type T is tagged record
>       Dummy : Big_Thing := (others => 'c');
>       X     : Integer   := 0;
>    end record;
> 
>    Borg : T;
> 
>    procedure Check (Y : T) is
>    begin
>       Borg.X := 1133;  --- We can't let this modify Y!!!
>       if Y.X /= 0 then
>          raise Constraint_Error;
>       end if;
>    end Check;
> 
>    function Create return T is
>    begin
>       return Borg;
>    end Create;
> 
>    Start : Time;
>    Iters : Natural;
> 
> begin
>    --  Pass - how?
>    Iters := 0;
>    Start := Clock;
>    while Clock - Start < 1.0 loop
>       Check (Create);
>       Iters := Iters + 1;
>    end loop;
>    Put_line ("Pass value:" & Natural'Image (Iters));
> end Ref;