Re: Reading the while standard input into a String

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

On Mon, 6 Jun 2011 10:46:20 +0000 (UTC), Natasha Kerensikova wrote:

> Hello,
> 
> On 2011-06-06, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On Sun, 5 Jun 2011 16:20:39 +0000 (UTC), Natasha Kerensikova wrote:
>>
>>> However I still read
>>> character by character
>>
>> You have to, because the definition of line end is language/OS/encoding
>> dependent, so in order to detect line ends properly you need to scan
>> characters one by one, maybe recoding them into the encoding used by the
>> parser (e.g. UTF-8). It does not make much sense to read input by arbitrary
>> size chunks. Read it line by line. If parser needs returns over the line
>> margin (unlikely), then keep read lines cached.
> 
> The line end detection problem is exactly why I wanted unprocessed input
> bytes.

There is no such thing as unprocessed input.

>>>  into a temporary buffer,
>>
>> Read it into the destination buffer.
> 
> Well the destination buffer for the processed text is a very inefficient
> place to store input text, because the processing involves a lot of
> insertions.

A temporary buffer makes it only slower.

> Moreover, because of the forward reference issue I detailed in another
> post, I cannot see how I can escape the schema:
> input stream --> temporary buffer --> output stream/buffer/storage

Input stream ---recoding---> Line buffer

(The line buffer could be bounded from above as Ludovic suggested.)

>> Don't use Unbounded_String; that is a
>> bad idea in almost all cases, this one included.
> 
> Would you explain why?

Because they are inefficient and do not have array view (lack indexing,
slicing, constraining).

> Unless there is a way to predict the left of the input, I need some
> text container able to grow as much as needed while reading.

String is such a container.

> But I guess you weren't calling using Unbounded_String a
> bad idea only because of performance, were you?

Yes, missing array view is the problem. In all cases you know the size in
advance or when the size incrementally grows use String allocated in the
heap. Unbounded_Strings can be used, for example, as members of
non-controlled records.

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