From: Natasha Kerensikova <lithiumcat@instinctive.eu>
Subject: Are values of non-limited actual type for a limited formal type built in place?
Date: Wed, 30 Apr 2014 15:07:05 +0000 (UTC)
Date: 2014-04-30T15:07:05+00:00 [thread overview]
Message-ID: <slrnlm24co.i0l.lithiumcat@nat.rebma.instinctive.eu> (raw)
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
next reply other threads:[~2014-04-30 15:07 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-30 15:07 Natasha Kerensikova [this message]
2014-04-30 15:23 ` Are values of non-limited actual type for a limited formal type built in place? Adam Beneschan
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox