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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1116ece181be1aea X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-09-28 19:46:03 PST Path: news1.google.com!newsfeed.stanford.edu!newsfeed.berkeley.edu!ucberkeley!cyclone-sf.pbi.net!216.218.192.242!news.he.net!newsfeed1.easynews.com!easynews.com!easynews!small1.nntp.aus1.giganews.com!border1.nntp.aus1.giganews.com!intern1.nntp.aus1.giganews.com!nntp.giganews.com!nntp.clear.net.nz!news.clear.net.nz.POSTED!not-for-mail NNTP-Posting-Date: Sun, 28 Sep 2003 21:46:01 -0500 From: Craig Carey Newsgroups: comp.lang.ada Subject: Re: Is the Writing on the Wall for Ada? Date: Mon, 29 Sep 2003 14:46:10 +1200 Message-ID: References: <1064527575.648809@master.nyc.kbcfp.com> <3F739C1D.4030907@attbi.com> X-Newsreader: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Customer of Mercury Telecommunications Ltd Cache-Post-Path: drone5.qsi.net.nz!unknown@tnt1-113.quicksilver.net.nz X-Cache: nntpcache 2.4.0b5 (see http://www.nntpcache.org/) X-Original-NNTP-Posting-Host: drone5-svc-skyt.qsi.net.nz X-Original-Trace: 29 Sep 2003 14:46:02 +1200, drone5-svc-skyt.qsi.net.nz NNTP-Posting-Host: 203.97.37.6 X-Trace: sv3-y8gpv3tFqe+31udglDAfFSs32QpSi4ALTpdoP8qPMBEVbi7hiacYj/Uw1Yv06/hpKr51QEIi6GFlCrk!nK88Jc+Zz9S7mMad8b0L0FcDwlQo3oCbbWVfj/CP6zoFLzGqR37DTd+NdVl7xybnoxrahEUWuFum!dlS7Miw= X-Complaints-To: Complaints to abuse@clear.net.nz X-DMCA-Complaints-To: Complaints to abuse@clear.net.nz X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Xref: news1.google.com comp.lang.ada:97 Date: 2003-09-29T14:46:10+12:00 List-Id: On Fri, 26 Sep 2003 02:31:52 GMT, Matthew Heaney wrote: >"Robert I. Eachus" writes: >> Hyman Rosen wrote: >> > Stephen Leake wrote: >> >> Ada.Strings.Unbounded. Way better than C++ Strings. >> > How? >> >> For one simple example, an Ada string of any flavor can always contain >> all possible character literals and control codes. > ... >The problem with Ada.Strings.Unbounded is that to do anything useful >with it requires a conversion to type String, which is grossly >inefficient, not to mention awkward. > Only if the string is large enough, e.g. 3KB or more, at least for GNAT (and ObjectAda) in Windows. The requirements of the oft revised RM 7.6 (user controlled finalization) guide vendors to get their Unbounded strings code to be slow. ---- Suppose there was a destructive Assign operator that is fast and efficient. It would do this: Tmp := Rhs.Ptr; Rhs.Ptr := Lhs.Ptr; Lhs.Ptr := Tmp; Lhs.valid := True Rhs.valid := False I vaguely recall these two arguments from persons...: * Variant fields mismatch * Run time crashes in the vendors compiler software and the exceptions coming out of Adjust or Finalize have to be correctly handled. Those feeble arguments are of no obvious importance in connection with the issue. I have not checked to see if GNAT has already got the "Assign(L,R);" extension that results in a fast ":=" assignment operator. With big customers requesting features all the time, it is pssible. >The ACT people added a Aux child (I think that's the name), which >provides a function to return the underlying String_Access. This is how >Ada.Strings.Unbounded should have been designed in the first place. > They could change the Aux package. E.g. produce rewritten Unbounded strings code. Also the Aux package exposes a limited implementation. E.g. there is no spare space in strings. User code might not run correctly if that changes. Also, it is not the case that the RM "should" describe something that is not known to be defined. >The C++ std::string also has a getline procedure to read from stdin >directly into a std::string. A similar function should have been >provided for Ada.Strings.Unbounded. GNAT's Get_Line lost the CP/M disk block padding char (in Windows 2000 [ASCI 26 if I recall right]). ASCII 13 is liable to go too. The RM allows some of that or all of it. Expanding the problem for that small purpose might not get voted for. Also the new Get_Line subroutine, returning a line of any length, would do unnecessary copying. Above this was written: "... The problem with Ada.Strings.Unbounded is that ... it requires a conversion to type String, ... which is inefficient..." That seems to be saying that unnecessary copying 'should' be avoided (i.e. it says "to type String" rather than: "from [the Ada String type]"). Craig Carey A replacement for Charles' Strings: http://www.ijs.co.nz/code/ada95_strings_pkg.zip Likel to be cmpatible with the ACT modified GPL.