Re: Question on bounded / unbounded strings

[John Smith <yoursurrogategod@gmail.com>]

On Saturday, September 24, 2016 at 3:52:54 AM UTC-4, Dmitry A. Kazakov wrote:
> 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.
> 
> Yes, this "sometimes" is 10% of all "sometimes", or less.

10 percent of all string operations?  Again, I stand by what I said about this being dependent on the application that is being developed.

> 
> > 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.
> 
> Which I never have to. If you assign strings reconsider the algorithm, 
> there is certainly something wrong with it. Strings may be rearranged, 
> never assigned.
> 

Again, this depends on the application being developed and how the information is flowing inside it.

> 
> > 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.
> 
> 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.

> 
> > 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.
> 
> 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.

> 
> > 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.
> 
> The output length for formatted output is always known. Normally the 
> parts of a composite string are statically known, that precludes 
> iteration or recursion. In other cases, like building a directory path 
> from some structure, I first calculate the length and then declare the 
> result string.

No, it is almost always unknown in my experience :-).  If I'm putting together 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, append 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 which 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 for 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 character -- something that I never have to do -- I can always use the element function.

> 
> >> 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 need
> >> to have a special data structure (text buffer) for this (with plain
> >> strings as building blocks).
> >
> > Why won't it work?
> 
> Because it is a very inefficient data structure for this purpose. 
> Unbounded_String aren't meant to be efficient for expansion 
> specifically. They give an overall balanced performance for *all* string 
> operations. Therefore the implementation will likely use a single buffer 
> reallocated in some chunks, if you are lucky, or each time, when you are 
> not, and then copied as a whole. Data structures designed specifically 
> for accumulation never reallocate anything and certainly never copy the 
> contents from the beginning. They don't have other string operations 
> efficient or don't have them at all, which is exactly the point. If you 
> need accumulator use stream, file, text buffer. You need not strings for 
> that.
> 

How would you use a stream?  Again, I can't get to your site, so I don't know 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 hit 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 have fixed size strings do the same, but then I will have to craft needlessly complex logic to accomplish the same thing.  If someone else (or me) needs to spend more time than is necessary in order to understand what I'm doing in my source, then it is an indication -- usually -- that either my design or implementation is flawed (and as we know, perception is reality, especially to humans.)