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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC 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-7-bit Path: g2news1.google.com!news1.google.com!news.glorb.com!wn11feed!worldnet.att.net!bgtnsc04-news.ops.worldnet.att.net.POSTED!53ab2750!not-for-mail Newsgroups: comp.lang.ada From: anon@anon.org (anon) Subject: Re: API design problem - buffer scatter I/O Reply-To: no to spamers (No@email.given.org) References: X-Newsreader: IBM NewsReader/2 2.0 Message-ID: Date: Sun, 23 Nov 2008 05:57:43 GMT NNTP-Posting-Host: 12.64.228.91 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc04-news.ops.worldnet.att.net 1227419863 12.64.228.91 (Sun, 23 Nov 2008 05:57:43 GMT) NNTP-Posting-Date: Sun, 23 Nov 2008 05:57:43 GMT Organization: AT&T Worldnet Xref: g2news1.google.com comp.lang.ada:2760 Date: 2008-11-23T05:57:43+00:00 List-Id: Even though Fat/Thin pointer are not in the true Ada specification they are use. In GNAT: Thin pointer are less efficient representation and not as flexibility as "Far pointer". And the bound value are storaged right behind the array Also, Thin pointers limit the use of "Unrestricted_Access" attribute by forcing the usage of non-aliased objects pointers. type X is access all String ; for X'Size use Standard'Address_Size ; In the case of unconstrained array type, the default is to use the "Far Pointer". Defined as a record with two pointers. One pointer is assigned to the array type, which translates to a System.Address. While the other pointer is assign to a bounds structure with the two fields one for the lower and the other the upper bounds. Something like this: type Bounds_Type is record -- hidden definition Lower : Natural ; Upper : Natural ; end record ; type Fat_Pointer is record -- hidden definition P_Array : System.Address ; P_Bound : Bounds_Type ; end record ; In , Maciej Sobczak writes: >I have a problem finding the best, from the Ada point of view, >interface for the scatter I/O API. > >The idea is that the library is able to read some bytes from somewhere >and put them in the buffers provided by user. The simplest, single- >buffer version of this idea is used in the standard library and in >many others - an example from GNAT.Sockets looks like here: > >procedure Receive_Socket > (Socket : Socket_Type; > Item : out Ada.Streams.Stream_Element_Array; > Last : out Ada.Streams.Stream_Element_Offset); > >In other words, user provides a single array and the library fills it >with data. > >The problem is that this is a single, continuous array. >How would you approach the design of API for multi-buffer I/O? Multi- >buffer means that the user can provide many arrays, probably of >different sizes, and the library will fill them from first to last. > >The following assumptions are true: >1. The user knows up-front how much data will be read. It will never >be less, so there is no need to give back any Last index, like above. >The user has to only ensure that the sum of buffer lengths is >appropriate for all the data that will be read. >2. Buffers don't need to have the same size. >3. Individual buffers are not necessarily related (they don't have to >be components of common bigger structure like record or array). >4. It really has to be a single operation, so no cheating with >repeated calls for separate buffers to get consecutive fragments. > >My initial idea was that the subprogram might have a parameter that is >an array of access values to separate buffers (actual buffers must be >therefore aliased). Are buffer bounds properly handled when only >access to array is given (didn't check that yet, sorry)? > >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); > >What is bothering me is Types/access> and the discussion on designated vs. nominal subtypes in >the "Fat pointers" paragraph. > >Have you seen an existing library that solves this problem is some >reasonable way? >Do you have other ideas or suggestions for how to design such API? > >-- >Maciej Sobczak * www.msobczak.com * www.inspirel.com > >Database Access Library for Ada: www.inspirel.com/soci-ada