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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,8ab6ed0f71c479cd X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!postnews.google.com!13g2000yql.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: API design problem - buffer scatter I/O Date: Sat, 22 Nov 2008 15:34:34 -0800 (PST) Organization: http://groups.google.com Message-ID: <36d5b92c-e28d-4aae-8495-8d3f0cc6defc@13g2000yql.googlegroups.com> References: NNTP-Posting-Host: 85.1.244.80 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1227396875 9315 127.0.0.1 (22 Nov 2008 23:34:35 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 22 Nov 2008 23:34:35 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: 13g2000yql.googlegroups.com; posting-host=85.1.244.80; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.3) Gecko/2008092414 Firefox/3.0.3,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:2756 Date: 2008-11-22T15:34:34-08:00 List-Id: On 22 Lis, 23:16, Robert A Duff wrote: > There is no such concept as "fat pointer" or "thin pointer" in Ada! I understand that the distinction is to make the reader aware that some access values need to carry over the bounds whereas some other don't. > It does point to a real problem, though. =A0Given your above declarations= , > you might want to say: > > =A0 =A0 This_Buf : aliased Stream_Element_Array (1..10); > =A0 =A0 That_Buf : aliased Stream_Element_Array (1..10_000); > > =A0 =A0 Scatter_Input_Data ((This_Buf'Access, That_Buf'Access)); -- wrong= ! > > but that's illegal. =A0You can do this instead: > > =A0 =A0 This_Buf : aliased Stream_Element_Array :=3D (1..10 =3D> <>); > =A0 =A0 That_Buf : aliased Stream_Element_Array :=3D (1..10_000 =3D> <>); > > =A0 =A0 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. > Another workaround is to wrap the Stream_Element_Array in a record Good idea. Still, in both of these solutions, there is a problem of scope - the type of access value is defined by the library API (well, at the library level), whereas user-provided buffers are likely to be defined locally. This brings the old problem of having an access value of global type pointing to local object (GNAT says: "non-local pointer cannot point to local object"). Unrestricted_Access hides the issue, but I know from Rationale that anonymous access types were supposed to solve some of that mess. The problem is that I cannot find any way to benefit from them. Let's say: type Buffer (Size : Ada.Streams.Stream_Element_Count) is record B : Ada.Streams.Stream_Element_Array (1 .. Size); end record; type Buffer_List is array (Positive range <>) of access Buffer; Buffer_List looks like an array of *anonymous* access values (and they don't have to be "all"!), but is not helping with the scope mismatch: declare My_Buf : aliased Buffer (Some_Size); -- local buffer Buffers : Buffer_List (1 .. 1); begin Buffers (1) :=3D My_Buf'Access; -- error! scope mismatch Scatter_Input_Data (Buffers); end; Again - Unrestricted_Access hides the mess under the carpet, but does not look nice. Any idea how to solve that? Except for this, everything seems to work like a charm, thank you all for your feedback. -- Maciej Sobczak * www.msobczak.com * www.inspirel.com Database Access Library for Ada: www.inspirel.com/soci-ada