Re: Question on bounded / unbounded strings

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

On 2016-09-22 16:51, Maciej Sobczak wrote:
>>> I don't know about you, but I seem to be surrounded by bounded strings.
>>
>> Do you use Ada bounded strings?
>
> I don't use Ada for such applications. :-)
> (in a sense, bounded strings in Ada are useless for the majority of programmers...)
>
> Yes, I have used char[N] in "other languages" on various occasions.
> These are bounded strings.

How char[N] is? It is compatible with char[M].

>>> Splitting strings is inefficient for you? It is very efficient for
>>> me  to split the string and pass its individual parts to separate tasks for
>>> parallel processing. If you are doing the string splitting by traversing
>>> the string and storing the tokens aside,
>>
>> Why would you store them? In the example you gave, I would pass them
>> straight to a worker task as soon as I get one.
>
> This is a secondary issue. You are still splitting the string.

No. Splitting is an operation resulting in a set of strings, as a 
compound object. Scanning does not produce such objects, though it could 
if necessary. The point is that this object is almost never necessary.

> And no, I would rather store them in a job queue.

Job queue is not a set of strings.

>> Not if substrings get processed,
>
> Yes if they are not processed.

They are, as you said, the result is a job queue not a set of strings.

> Please do not invent artificial argument extensions only to "prove" your point.

Just defining terms. If you consider scanning, translating, etc same as 
tokenizing because the application in the end does the same, there is 
nothing to discuss. Then Ada is C and C is Ada.

>> The point
>> is that the operation of splitting as such is pointless because its
>> result has no value of its own
>
> No, the result of splitting has a real value of its own. Get the
> spreadsheet and split it into individual cells - they are still real
> values. They might even be still useful in another spreadsheet.

String is not spreadsheet and conversely.

>> it is an intermediate which can and must
>> be dropped for the sake of simplicity and efficiency.
>
> There is no reason to drop a data value that is needed for further processing.

Nobody dropped values required processing. Values of tokens /= Value of 
a set of tokens. Values are processed without explicit construction of a 
set of.

>>> Unbounded_String? Can be very useful as a sink for generated data in
>>> whatever format.
>>
>> Nope. That thing is called stream.
>
> Nope. Stream is a high-level I/O abstraction that is not needed
> here.

You argue for a poor implementation (Unbounded_String) of this abstraction.

> Progressive accumulation of value is called "append" and
> Unbounded_String has the right interface for this.

Yes, "Append" could implements stream's "Write". So what? If the output 
is generated in a raw form that is stream. Not frequently used, but 
Unbounded_String would be a poor choice, as always. There is no much use 
of Unbounded_String. One is passing in-out parameters for a procedure. 
Another is having arrays and records with string components.

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