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!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: API design problem - buffer scatter I/O Date: Sat, 22 Nov 2008 17:16:01 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls6.std.com 1227392162 32276 192.74.137.71 (22 Nov 2008 22:16:02 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Sat, 22 Nov 2008 22:16:02 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:Td6ICiWlJZFRkfdcnYU0V4QuRx8= Xref: g2news2.google.com comp.lang.ada:3725 Date: 2008-11-22T17:16:01-05:00 List-Id: Maciej Sobczak writes: > My initial idea: > > type Buffer_Ptr is access Ada.Streams.Stream_Element_Array; > type Buffers is array (Positive range <>) of Buffer_Ptr; > > procedure Scatter_Input_Data (B : in Buffers); This looks like a reasonable design, except you probably want "access all" instead of "access". > What is bothering me is Types/access> and the discussion on designated vs. nominal subtypes in > the "Fat pointers" paragraph. I didn't read the whole wikibook, but the particular part you point to above has quite a bit of misinformation. Also, the early focus on "fat pointers" vs. "thin pointers" is confusing. There's no reason to talk about such implementation details in an introductory tutorial. Especially if the details are wrong. There is no such concept as "fat pointer" or "thin pointer" in Ada! 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 Another workaround is to wrap the Stream_Element_Array in a record, with a discriminant Length used to constrain the array. If that record is called Buffer, you could then do: This_Buf : aliased Buffer (Length => 100); That_Buf : aliased Buffer (Length => 10_000); Scatter_Input_Data ((This_Buf'Access, That_Buf'Access)); This has the advantage that you can fix the lower bound of the array at 1 (or 0, whichever makes sense for your application). You don't have to worry about weird array bounds like 30..40. - Bob