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,7bcba1db9ed24fa7 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-07-07 13:20:18 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!iad-peer.news.verio.net!news.verio.net!iad-read.news.verio.net.POSTED!kilgallen From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) Newsgroups: comp.lang.ada Subject: String support (was: is Ada dead?) Message-ID: References: <3B460DA9.C2965042@ix.netcom.com> <9ff447f2.0107061757.34ca0723@posting.google.com> <9i6lak$bqi$1@geraldo.cc.utexas.edu> <3B475916.E4548A5D@worldnet.att.net> Organization: LJK Software Date: 7 Jul 2001 16:19:52 -0500 NNTP-Posting-Host: 216.44.122.34 X-Complaints-To: abuse@verio.net X-Trace: iad-read.news.verio.net 994537208 216.44.122.34 (Sat, 07 Jul 2001 20:20:08 GMT) NNTP-Posting-Date: Sat, 07 Jul 2001 20:20:08 GMT Xref: archiver1.google.com comp.lang.ada:9610 Date: 2001-07-07T16:19:52-05:00 List-Id: In article <3B475916.E4548A5D@worldnet.att.net>, James Rogers writes: > Larry Kilgallen wrote: >> >> In article <9i6lak$bqi$1@geraldo.cc.utexas.edu>, "Bobby D. Bryant" writes: >> > It looks to me that the family C, C++, Java, and C# show a teleological >> > evolutionary trend toward becoming an Ada clone. >> >> I don't think they will ever forsake their null-terminated strings. > > That may be true for C, but C++ now has a String class, which is not > just a wrapper for the more primitive C strings. Let me know when they drop all support for the C-style strings :-) > Of course, the Java String suffers from the same inefficiencies as > an Ada Unbounded string. For instance, you cannot edit a Java String. > There are Java methods to change the value of a character at a > specified position. The result, however, is not strictly an edited > string. It is an entirely new string, with all the characters copied > and the edited character replacing the original. In other words, if > you want to loop through all the characters in an existing 1024 > character String, replacing each one, you will require the creation > and garbage collection of 1024 1024 character strings. Since Java > characters are all 16 bits, this means that you need to chew up > over 2 Megabytes of data to edit a 1024 character String. That seems like an implementation detail that could be done in a more efficient fashion. from your description, I see no reason why some implementor could not do better.