Re: Amount of copying on returned constant objects

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

"Alex R. Mosteo" <devnull@mailinator.com> writes:
> Hello,
>
> before I go digging into assembler listings I'd like to ask here in case
> someone has the answer ready.
>
> I know that some "in" arguments may be passed as copies or as references, at
> compiler discretion (this is one of these things that "programmers
> shouldn't care about", many times quoted).
>
> I wonder however about results of functions, that are not modified. Look for
> example at the Element function of the new Ada.Containers. They return the
> stored item, that may well be a quite large controlled tagged type, for
> example.

The "compiler discretion" does not apply to all cases. The compiler is
required to pass parameters of limited and tagged types by reference.
I'm not entirely sure that that also applies to the result of a
function call, but that would seem reasonable.  If the function
returns a class-wide or other unconstrained type, then the object will
have to be on the heap (in the region GNAT calls the "secondary
stack").

> Now, many times I want to query an element just for read-only purposes. I'm
> faced with two options:
>
> 1) Just call Element on the container Key/Index, and be done with it.

That would be my approach.

> 2) Do a Find+Query_Element, which requires defining an extra procedure and
> somewhat breaks the flow of control, but ensures no copying.
>
> I tend to go with 1) because of laziness and the "no premature optimization"
> rule. In C++ I could use constant references. Now, I wonder if 
>
> a) is there something in the ARM that prevents an equivalent transparent
> optimization in the Ada side (returning the reference when it is detected
> that the returned object is not modified)?
> 
> b) If not, do you know of compilers that do this in practice? (Specially
> interesting for me would be GNAT at -O2/-O3).

If you investigate GNAT, could you please post your findings here?

> Failing these, I guess I could define constant accesses for use in my own
> functions, but I find this not very Ada-like. Any other ideas?

-- 
Ludovic Brenta.