Re: Question on bounded / unbounded strings

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2016-09-24 18:25, John Smith wrote:
> 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?

10% of *applications*.

The type String does not have operation "append". There is only 
concatenation operation "&".

> Again, I stand by what I said
> about this being dependent on the application that is being developed.

Yes. In all applications I developed Unbounded_String was used in far 
less than 10% of the cases when strings were involved.

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

Sure. I never assign strings as a whole except for initialization purpose.

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

Searching for a pattern / skipping irrelevant parts of the input do not 
require that. No need to split anything.

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

Hmm, it is not down:

http://www.dmitry-kazakov.de/ada/strings_edit.htm
http://www.dmitry-kazakov.de/ada/components.htm#Parsers_etc

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

But a mail body is not a string! If you send a MIME attachment the 
natural way to do it is to use a stream as the source. String can be 
used, but for short text mails only.

I believe AWS takes streams for attachment. My implementation of SMTP 
certainly does:

http://www.dmitry-kazakov.de/ada/components.htm#GNAT.Sockets.SMTP.Client.Attach_Stream

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

I would use a stream on top of a segmented buffer, e.g.

http://www.dmitry-kazakov.de/ada/components.htm#Storage_Streams

Or a FIFO if the producer of the content and the SMTP client are run by 
different tasks.

You don't need to build all attachment in the memory in order to be able 
to send it.

It is a pity that nobody cares about proper organization of text 
processing in these days, even here in c.l.a.

If you like me have 2GB+ of text trace and text editors written by 
people believing in "splitting strings", then you have to wait 20 
minutes before the editor shows the file contents, 40 first lines. If it 
does not crash before and take the OS with. Guess why?

> However, if I ever need string functionality that I'm used to in
> Python or C++, Unbounded strings are the only reasonable solution.

You used to use dynamic strings. But there is no evidence they really 
simpler to use. In my code which varies from network protocols to 
compiler developing tools and AI you will find almost no 
Unbounded_Strings. Would it be simpler with Unbounded_Strings? I doubt it.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de