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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d8aa0b11d3c79b63 X-Google-Attributes: gid103376,public From: Tucker Taft Subject: Re: Access to strings and string subtypes? Date: 2000/03/20 Message-ID: <38D684B2.8B16F58C@averstar.com>#1/1 X-Deja-AN: 600070449 Content-Transfer-Encoding: 7bit References: <38d10a7b.91796987@news.rrds.co.uk> <38d11f2a.97092271@news.rrds.co.uk> <2000Mar17.070235.1@eisner> <8atgul$i7l$1@nnrp1.deja.com> <8b0pu2$b80$1@nnrp1.deja.com> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@inmet2.burl.averstar.com X-Trace: inmet2.burl.averstar.com 953582771 2201 141.199.8.164 (20 Mar 2000 20:06:11 GMT) Organization: AverStar (formerly Intermetrics) Burlington, MA USA Mime-Version: 1.0 NNTP-Posting-Date: 20 Mar 2000 20:06:11 GMT Newsgroups: comp.lang.ada Date: 2000-03-20T20:06:11+00:00 List-Id: Robert Dewar wrote: > > In article , > Robert A Duff wrote: > > > I don't think it was purely an efficiency issue. > > I really think you are wrong here. I remember these discussions > very well, since I was opposed to this kludge. > > > I think we were > > concerned that existing Ada 83 implementations were already > > doing that optimization, and would have difficulty changing > > the way they represent arrays. > > If anyone was concerned about this, they never voiced this > concern at any meeting I was at. Perhaps I have forgotten, > but my memory was that this PURELY an efficiency concern. > > Really I can't imagine any Ada 83 compiler making this > distinction (the ones that I am familiar with certainly > did not). You should at least be able to come up with one > example to back up your conjecture :-) The problem was not so much with the objects as it was with the access values. For many compilers, access-to-unconstrained expects the object to have dope contiguous with the object, whereas with access-to-constrained, there is no dope associated with the object. If the same type of access value could point to either, then both would require contiguous dope. This is not much of a hardship for stand-alone objects. However, for record or array components, adding dope as a side effect of adding the word "aliased" to the component seemed undesirable at the time (at least to some of us). So it was a space efficiency issue primarily. In retrospect, I guess having "aliased" cause the addition of contiguous dope might have been the better approach, but as usual, hindsight is 20-20 (or wears rose-colored glasses, or something like that ;-). These concerns all presume the "thin pointer" representation for access-to-unconstrained types. For the "fat pointer" representation, where there is a separate pointer to the dope, this problem disappears. But of course that interacts in tricky ways with access-to-deferred-incomplete, etc. > Part of the reason I remember is that there were VERY few cases > where we compromised the language for the benefit of existing > implementations in very specific terms (we did have some general > concerns about scope of change). As indicated above, it wasn't so much about difficulty of implementation, as about space overhead. -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA