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 Path: g2news2.google.com!news1.google.com!news.glorb.com!news2!solaris.cc.vt.edu!news.vt.edu!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 19:01:03 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <36d5b92c-e28d-4aae-8495-8d3f0cc6defc@13g2000yql.googlegroups.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: pcls4.std.com 1227398464 15778 192.74.137.71 (23 Nov 2008 00:01:04 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Sun, 23 Nov 2008 00:01:04 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:11ujPpRZ1l5Ie/vffft2Cm8k1lM= Xref: g2news2.google.com comp.lang.ada:3728 Date: 2008-11-22T19:01:03-05:00 List-Id: Maciej Sobczak writes: > 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. Perhaps, but I still find that wiki page confusing. When you have an access to unconstrained array, the implementation has to arrange some way to find the bounds -- e.g. if the program says X.all'Last. Fat pointers are one way to do that, but not the only one. GNAT can use either fat pointers or thin pointers (for access to unconstrained array) -- it's a programmer choice. And (I claim) this has no place in a description of the semantics of the language. It's an implementation detail. >> 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. >> 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. Right. You have to use Local'Unchecked_Access, and take care to avoid dangling pointers. > 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,... Don't use Unrestricted_Access here (which is not standard Ada). Use Unchecked_Access. Yes, it's dangerous -- you need to ensure that Scatter_Input_Data doesn't save pointers to locals into globals, along with comments explaining what clients can do. There's no better solution. >... but I know from Rationale that > anonymous access types were supposed to solve some of that mess. "Supposed to", maybe. But they don't. I suggest you stay away from them. They are confusing, and don't help here. >...The > problem is that I cannot find any way to benefit from them. Right. Neither can I. [snipped discussion of failed attempts to use anonymous access types] By the way, ARG is discussing some ideas for improving anonymous access types. My own opinion is that this will not work out, but others do not agree with me. - Bob