Re: Efficiency of returning big objects

["Alex R. Mosteo" <devnull@mailinator.com>]

Georg Bauhaus wrote:

> On Mon, 2006-09-25 at 14:14 +0200, Alex R. Mosteo wrote:
> 
>> Some_Map.Element (Key).Method_Or_Member
> 
> Could you consider using Query_Element as an efficient
> alternative? Or Update_Element if Method modifies.

I use these when common sense indicates that extracting a copy is too
heavyweight (and of course Update_Element is necessary for in-place
modifications).

I've once used Update_Element to make a function returning an access to the
actual copy in the container. This has required using 'Unrestricted_Access
inside Update_Element, so I'm not comfortable with it (though it worked).

It's maybe a problem of personal taste, but I find that
[Query/Update]_Element breaks algorithm flow, and being that Ada mainly
follows the imperative paradigm it is a bit awkward for me. Usually I
simply want to call a method of an stored object and instead I must insert
a "huge" declare block with the Query/Update procedure stub that simply
calls the object method, and after the fact call to Query/Update. For
example, for a querying, instead of

if Collection.Element (Cursor).Some_Function then ...

I must do

declare
   Ok : Bool;
   procedure Query_Stub ...
begin
   Some_Package.Query_Element (Cursor, Query_Stub'Access);
   if Ok then ...
end;

Even if all of this tends to be hidden in bodies of opaque types, it is
still a bore when writing these types. If there is some gain (in clarity or
reuse) in encapsulating all this in a proper function, it is still overhead
(in calls and in writing). As I say, maybe it is simply a matter of
personal likings. Still, I find myself musing in a compulsive way about
these things every time :)

>> 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?
> 
> Making T limited reveals a few things:
> 
> Compiling: ref.adb (source file time stamp: 2006-09-25 15:22:05)
> 
>     23.       return Borg;
>                      |
>         >>> (Ada 2005) cannot copy object of a limited type (RM-2005
>         >>> 6.5(5.5/2)) return by reference not permitted in Ada 2005
>         >>> consider switching to return of access type
>     51.       if Create.X /= 0 then
>                  |
>         >>> (Ada 2005) limited function call in this context is not yet
>         >>> implemented

If I'm not mistaken, these are both sides of the coin: you can't return
limited types, because this implies a copy, unless (second case) this is a
new object being created in-place. 

Conceptually, it's clear that returning an object implies obtaining a copy.
I was hoping for the kind of optimization that also allows the omission of
some temporary copies (for example I think there are some rules about this
in controlled types).