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=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.66.7.41 with SMTP id g9mr3088965paa.127.1474734355509; Sat, 24 Sep 2016 09:25:55 -0700 (PDT) X-Received: by 10.157.34.41 with SMTP id o38mr1134542ota.6.1474734355447; Sat, 24 Sep 2016 09:25:55 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!u18no3963929ita.0!news-out.google.com!b4ni11029iti.0!nntp.google.com!x192no4091854itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 24 Sep 2016 09:25:55 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=50.250.26.106; posting-account=AvekzAoAAABj-TclKcOWQmXwA49MFPGX NNTP-Posting-Host: 50.250.26.106 References: <11ee98f5-d373-4c72-8562-c310cc76817d@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Question on bounded / unbounded strings From: John Smith Injection-Date: Sat, 24 Sep 2016 16:25:55 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:31872 Date: 2016-09-24T09:25:55-07:00 List-Id: On Saturday, September 24, 2016 at 3:52:54 AM UTC-4, Dmitry A. Kazakov wrot= e: > On 2016-09-24 01:58, John Smith wrote: > > On Thursday, September 22, 2016 at 3:25:18 AM UTC-4, Dmitry A. Kazakov = wrote: > >> On 22/09/2016 04:10, John Smith wrote: > >> > >>> I've found the ease with which you can append or manipulate unbounded > >>> strings to be very convenient. > >> > >> 1. There is no need to append to a string in no less than 90% of cases= . > > > > The percentage in this case depends on what application you are > > developing. Sometimes you will need to do this more often, sometimes > > less often. >=20 > Yes, this "sometimes" is 10% of all "sometimes", or less. 10 percent of all string operations? Again, I stand by what I said about t= his being dependent on the application that is being developed. >=20 > > If anything, a fixed string is less convenient since you need to > > walk on eggshells and cannot simply assign a new value to the existing= string. >=20 > Which I never have to. If you assign strings reconsider the algorithm,=20 > there is certainly something wrong with it. Strings may be rearranged,=20 > never assigned. >=20 Again, this depends on the application being developed and how the informat= ion is flowing inside it. >=20 > > If you need to separate a large string into a bunch smaller ones > > that do not have a pre-determined size, using a fixed string does not = make > > any sense. >=20 > I *never* need that. It was discussed already. If a file is read in (the format is non-standard) and you now need to sift = through the details of the file, you will need this. >=20 > > When you do need to build a string, it is far easier to have one > > unbounded string that is added on to and then written out. >=20 > No, it is easier with fixed strings. How? I've tried going to the example on your website, but it seems that that is = down. >=20 > > Having a > > fixed string means that I woul need something along the lines of a > > recursive solution, since I can't extent the size of the string after > > it's been instantiated. >=20 > The output length for formatted output is always known. Normally the=20 > parts of a composite string are statically known, that precludes=20 > iteration or recursion. In other cases, like building a directory path=20 > from some structure, I first calculate the length and then declare the=20 > result string. No, it is almost always unknown in my experience :-). If I'm putting toget= her a report that needs to be e-mailed out, I have no idea how long it will= be. I would first need to do my thing, get the string returned from it, a= ppend it to an accumulator string and after all of that was done, I can now= know its length. If I were to first run my analysis, get the length of the string (which is = the result that will go out), then keep doing this until I'm finished (at w= hich point I will be able to figure out how big my accumulator is supposed = to be.) Now, I would have to re-run my analysis again and then copy in the= results into the my newly allocated accumulator string. That would make f= or some needlessly complex logic in my application (as opposed to just dump= everything to an unbounded string.) If there is ever a need to go through the entire string character by charac= ter -- something that I never have to do -- I can always use the element fu= nction. >=20 > >> The idea of using Unbounded_String as an accumulator, e.g. for some > >> messages log, is just awful. It won't work and at the end you will nee= d > >> to have a special data structure (text buffer) for this (with plain > >> strings as building blocks). > > > > Why won't it work? >=20 > Because it is a very inefficient data structure for this purpose.=20 > Unbounded_String aren't meant to be efficient for expansion=20 > specifically. They give an overall balanced performance for *all* string= =20 > operations. Therefore the implementation will likely use a single buffer= =20 > reallocated in some chunks, if you are lucky, or each time, when you are= =20 > not, and then copied as a whole. Data structures designed specifically=20 > for accumulation never reallocate anything and certainly never copy the= =20 > contents from the beginning. They don't have other string operations=20 > efficient or don't have them at all, which is exactly the point. If you= =20 > need accumulator use stream, file, text buffer. You need not strings for= =20 > that. >=20 How would you use a stream? Again, I can't get to your site, so I don't kn= ow if you have an example there or not. And I agree with you. It does make sense to flush out logging information = to a file as soon as possible. I also agree that there is a performance hi= t when it comes to using Unbounded strings when compared to fixed ones (as = to how much depends on various factors that I'm unwilling to jump into.) However, if I ever need string functionality that I'm used to in Python or = C++, Unbounded strings are the only reasonable solution. Yes, I can work h= ave fixed size strings do the same, but then I will have to craft needlessl= y complex logic to accomplish the same thing. If someone else (or me) need= s to spend more time than is necessary in order to understand what I'm doin= g in my source, then it is an indication -- usually -- that either my desig= n or implementation is flawed (and as we know, perception is reality, espec= ially to humans.)