From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,8ab6ed0f71c479cd X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!proxad.net!feeder1-2.proxad.net!newsfeed.straub-nv.de!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: API design problem - buffer scatter I/O Date: Tue, 25 Nov 2008 16:20:06 -0600 Organization: Jacob Sparre Andersen Message-ID: References: <1b06d68d-a6d8-4af3-8464-92e44224dcd6@20g2000yqt.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1227651713 26456 69.95.181.76 (25 Nov 2008 22:21:53 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 25 Nov 2008 22:21:53 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5512 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Xref: g2news2.google.com comp.lang.ada:3759 Date: 2008-11-25T16:20:06-06:00 List-Id: "Robert A Duff" 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! :-)