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!news1.google.com!news.glorb.com!newsfeed2.telusplanet.net!newsfeed.telus.net!newspump.monmouth.com!newspeer.monmouth.com!newsswitch.lcs.mit.edu!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: API design problem - buffer scatter I/O Date: Mon, 24 Nov 2008 15:03:08 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <1b06d68d-a6d8-4af3-8464-92e44224dcd6@20g2000yqt.googlegroups.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls6.std.com 1227556988 20414 192.74.137.71 (24 Nov 2008 20:03:08 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Mon, 24 Nov 2008 20:03:08 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:FTNw3BiEu+ETogWteHXQ3bUVNw4= Xref: g2news2.google.com comp.lang.ada:3744 Date: 2008-11-24T15:03:08-05:00 List-Id: christoph.grein@eurocopter.com writes: > May be the nomenclature in wiki is wrong or confusing (and you always > have to be skeptical about the contents), but the incompatibilities > described there exist. And I remember a discussion with Robert Dewar > that Access_To_Address_Conversion does not work for access to > unconstrained just because of the bounds (in GNAT, this is just an > Unchecked_Conversion of the Address in either way). > > So, Bob, could you please elaborate about what is wrong in this > description. Well, the very first sentence starts talking about addresses, which is a confusing approach, IMHO. I have no objection to teaching people about implementation details (like thin and fat pointers), but that should come at the end. FIRST learn about the semantics of access types, which are pretty much the same as "pointers" or "references" in many other languages. (Access types do not allow address arithmetic, as C and C++ pointers do. But there are many other languages that are just like Ada in this regard.) It says, "objects of this category do not really point to objects": Of course they do. "Designate" is the Ada jargon, but "point to" is just fine as an informal term. It then introduces its own jargon "grant access", which is unhelpful. There's no "granting" going on here. It says, "Thin pointers grant access to constrained subtypes." No. In all Ada compilers I know of except GNAT, thin pointers are used in all cases -- there are no fat pointers. In GNAT, thin pointers are used for constrained subtypes, but also for unconstrained scalars, unconstrained records, unconstrained tasks, and so forth. The ONLY case where fat pointers are used is for unconstrained arrays -- and that's just the default (there is an option to use thin pointers in that case as well). It implies that constrained subtypes have a static size. That's not correct -- many constrained subtypes have dynamic size. It makes statements about Address_To_Access_Converions that are not necessarily true of Ada in general -- whether it's safe depends entirely on the implementation. And "thin safe, fat unsafe" isn't quite right anyway -- thin pointers don't always work with Address_To_Access_Converions, either. It implies that fat pointers are somehow required for unconstrained arrays. It's not true -- as I said, this is just one implementation approach. > And I disagree that this should not be in wiki, ... Sorry, I did not mean to imply it shouldn't be there. I just don't think it should be used in the explanation of access types semantics. Later, there could be some explanation of implementation strategies. And it should take care not to imply that any particular implementation strategy is required by the language rules. >... because programmers > inevitable will fall into this trap (as I did) ... Beginners have no business using Address_To_Access_Converions in the first place. This is an advanced, low-level, and dangerous feature. Normal use of access types doesn't involve Address_To_Access_Converions at all. Warning people about the traps of Address_To_Access_Converions is a good idea -- but it belongs in the section on Address_To_Access_Converions, not in the section on access types. >... and the corresponding > RM pages are very difficult to grok. Yes, I agree -- the RM is rather tough going! I'm not trying to denigrate the attempt to explain things in a more accessible way. >...This is not an implementation > detail. Sure it is. How a compiler represents data types (including access types) is an implementation detail. You don't need to know about it until you need to use some low-level chap-13-ish features (and I include interfacing to C in that category). > I do not know what a thin and a fat and a far pointer actually are, > I'm no Ada implementor. From my point of view as language user, a thin > pointer is simply an address, a fat pointer an address and the bounds. Almost right. Change "bounds" to "address of bounds". > So just the use of "thin" and "fat" is wrong, because it's an > implementation detail? It's not "wrong" to teach people about thin and fat pointers. But it's unhelpful to introduce those concepts to beginners up front. - Bob