Are values of non-limited actual type for a limited formal type built in place?

Are values of non-limited actual type for a limited formal type built in place?

[Natasha Kerensikova]

Hello,

I have been writing an application that happens to manipulate large
Stream_Element_Arrays, so I had the idea of re-using my
reference-counter generic package, that operate on a limited formal
type, under the assumption that there would be no copying.

To create the reference-counted objects, I use an anonymous access to
function, to let the client create the limited object. So I end up with
something like

   function Create_Reference
     (Create : not null access function return Held_Data)
   is
      ...
   begin
      Returned_Reference.Internal_Access := new Held_Data'(Create.all)
      ...

As far as I understand, if Held_Data is actually a limited type, that
requires that somehow Create builds in place.

However, a little experiment seemed to hint that when the actual type
for Held_Data is Stream_Element_Array, which is not limited, the snipped
above involves the allocation of two arrays and copying from one to the
other.

Is there anything in the RM about the build-in-place (or lack of
thereof) of value of limited formal type but non-limited actual type?


Assuming the copying there is unavoidable, I have found two leads to
prevent it :

  1. using a limited wrapper record, like
   type Limited_SEA (Size : Stream_Element_Count) is limited record
      Data : Stream_Element_Array (1 .. Size);
   end record;
and instantiate the reference-counting package with this
actually-limited type.

  2. expose the internal access type, and provide a new function
   function Create_Reference
     (Create : not null access function return Internal_Access_Type)
and assign directly the returned value to the returned reference.


I'm not fond of 1 because of how deep is the change to convert code
dealing with references to normal-sized SEA into code dealing with
non-copied SEA.

And I'm a bit afraid of 2, because it involves exposing a
meant-to-be-internal access type. But think a bit more about it, I don't
really understand the risk of exposing it. Would you enlighten me?

Considering values of Internal_Access_Type are only used as input, and
never output, the only risk would be when a client stores an
Internal_Access_Type value it provides to the reference-counting
package, which should be easy to spot.

Is there a way to defend against it?

Is there another workaround to prevent the copy of large SEA?

In case it's relevant, the full code of the involved reference-counting
package is available at
https://github.com/faelys/natools/blob/trunk/src/natools-references.ads



Thanks for your help,
Natasha

Re: Are values of non-limited actual type for a limited formal type built in place?

[Adam Beneschan]

On Wednesday, April 30, 2014 8:07:05 AM UTC-7, Natasha Kerensikova wrote:

> 
> Is there anything in the RM about the build-in-place (or lack of
> thereof) of value of limited formal type but non-limited actual type?

The language rules about build-in-place refer to the "full type", so I would assume that the non-limited actual type is what matters here, not the limited formal type.  RM 7.6(17.2/3).

There's a similar situation that doesn't involve generics; it's possible for a type to be declared as "limited private" in a package specification but then be non-limited in the private part.  (This allows the body of the package to use := of the type, while preventing other packages from using the := operator.)  Here, since the rules refer to the "full type", build-in-place is not required, even in other packages whose [partial] view of the type is limited.

                               -- Adam