Re: API design problem - buffer scatter I/O

["Randy Brukardt" <randy@rrsoftware.com>]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcciqqcki2r.fsf@shell01.TheWorld.com...
>>> It does point to a real problem, though.  Given your above declarations,
>>> you might want to say:

>>>     This_Buf : aliased Stream_Element_Array (1..10);
>>>     That_Buf : aliased Stream_Element_Array (1..10_000);


>>>     Scatter_Input_Data ((This_Buf'Access, That_Buf'Access)); -- wrong!


>>> but that's illegal.  You can do this instead:


>>>     This_Buf : aliased Stream_Element_Array := (1..10 => <>);
>>>     That_Buf : aliased Stream_Element_Array := (1..10_000 => <>);


>>>     Scatter_Input_Data ((This_Buf'Access, That_Buf'Access)); -- OK


>> Yes, I have noticed that. Not a big issue for the user (all bounds can
>> be still variable at run-time), but highlights some part of the
>> language that is maybe unnecessarily rigid.



>Perhaps.  If the above "wrong!" thing were allowed, there would be a
>slight efficiency hit.  That (efficiency) is the _only_ reason for
>this rule.  Maybe it was a mistake.

I don't think that the efficiency hit is *slight*, although it matters on 
whether you use access-to-constrained-array much.

The problem is that if you don't have the bounds for the array currently, 
you have to add them somewhere. But at the point of the conversion/'Access, 
you don't know how long the bounds will be needed, so you pretty much have 
to allocate them globally and that is a storage leak (they'll never be 
recovered during the life of the program).

Alternatively, you can just forget the optimization of removing the bounds, 
and put the bounds on all (aliased) array objects, which includes all 
allocated objects of access-to-constrained. Since this is likely the same 
mechanism as used for passing array bounds as parameters (it surely is in 
Janus/Ada), it also could have a cost on slicing. (Bounds can't be 
contiguous with the rest of the object in general, because of slicing.) 
Optimization can remove some of that cost, but not most of it.

The unoptimizable case occurs when converting access-to-constrained to 
access-to-unconstrained. The result is that the bounds have to be passed 
with all access-to-array types, because they can't be created out of thin 
air (else they'll leak memory). As such, access-to-constrained-array end up 
with a run-time penalty (either a fat pointer or an extra level of 
indirection) that they otherwise would not have.

The problem of course is that you need overhead (space and time) in other 
parts of the language whether or not you take advantage of this particular 
feature. Generally, we try to avoid overhead that occurs whether or not you 
use something.

                         Randy.

P.S. And I didn't even have to mention shared generics! :-)