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,FREEMAIL_FROM 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 22:29:25 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newshub2.home.com!news.home.com!news1.rdc1.bc.home.com.POSTED!not-for-mail Sender: stephen@anakin Newsgroups: comp.lang.ada Subject: Re: is ada dead? References: <3B460DA9.C2965042@ix.netcom.com> <9ff447f2.0107061757.34ca0723@posting.google.com> <9i6lak$bqi$1@geraldo.cc.utexas.edu> <3B475916.E4548A5D@worldnet.att.net> <3B47D830.830E4E31@worldnet.att.net> From: stephen_bevan@yahoo.com (Stephen J. Bevan) Message-ID: Organization: just me at home X-Newsreader: Gnus v5.7/Emacs 20.7 Date: Sun, 08 Jul 2001 05:29:25 GMT NNTP-Posting-Host: 24.77.89.252 X-Complaints-To: abuse@home.net X-Trace: news1.rdc1.bc.home.com 994570165 24.77.89.252 (Sat, 07 Jul 2001 22:29:25 PDT) NNTP-Posting-Date: Sat, 07 Jul 2001 22:29:25 PDT Xref: archiver1.google.com comp.lang.ada:9628 Date: 2001-07-08T05:29:25+00:00 List-Id: James Rogers writes: > Yes. The Stringbuffer class is much more efficient than the String > class for editing purposes. It is still terribly inefficient > compared to, for instance, Ada strings. Do you mean String or an Unbounded_String? IMHO a Java StringBuffer has very similar properties to an Ada Unbounded_String. If you want an equivalent of an Ada String, then the best approximation would be char[] in Java. > Remember the extra processing overhead needed to use a StringBuffer > also. Consider the StringBuffer a linked list of characters. > I say this because the StringBuffer is resizable, while the String > class, and Java arrays are not. This means that the StringBuffer > cannot be implemented using an array. Actually it is implemented as an char[] -- at least in Sun's implementation anyway. If you turn a String into a StringBuffer then it allocates an array large enough for the string plus some slop space (16 characters). If you append enough characters to fill the slop space then a new array is created with a size 2* the current one and all the characters are copied over. This has bad worst-case properties, especially for appending, but it seems to suffice on average (I've certainly used it on quite a few occasions and it didn't show up in profiling). If you need something with better worst-case properties then you can build it based on a char[]. > by garbage collection. Some Java garbage collectors do not > defragment memory after collection. Heavy use of a StringBuffer > can result in highly fragmented memory. This may not be a memory > leak, but it can result in the eventual inability to allocate > a needed block of memory. Agreed, its a quality of implementation issue. But then so is the quality of the memory allocation routines you get with an Ada implementation. In both cases if you are not happy you can either write your own pooling code or try a different implementation. > The StringBuffer is still highly inefficient compared to the > ability to edit characters in place in a string. I agree. However, if you know you want to edit a String then the best thing is to avoid making it a String in the first place and either keep it as a char[] or wrapped in a StringBuffer.