stdio performance in tango, stdlib, and perl

[Andrei Alexandrescu (See Website For Email)]

Derek Parnell wrote:
> Actually you said "stdio also offers a readln() that creates a new line on
> every call" and so does my fictious "io.readln(line)".  It can not
> overwrite its buffer because it creates the buffer. 
> 
>   io.Status readln(out char[] pBuffer)
>   {
>      pBuffer.length = io.FirstGuessLength;
>      
>      // Note: This routine expand/contracts the buffer as required.
>      fill_the_buffer_with_chars_until_EOL_or_EOF(pBuffer);
> 
>      // If I get this far then the low-level I/O system didn't fail me.
>      return io.Success;
>   }

Fine. It's just not clear what readln does from its signature. In 
contrast, stdio offers size_t readln(char[]) and char[] readln(), with 
clear semantics.

>> It should be pointed out that my point generalizes to more than 
>> newlines. I plan to add to phobos two routines that efficiently and 
>> atomically implement the following:
>>
>> read_delim(FILE*, char[] buf, dchar delim);
>>
>> and
>>
>> read_delim(FILE*, char[] buf, char delim[]);
>>
>> For such functions, particularly the last one, it is vital that the 
>> delimiter is KEPT in the resulting buffer.
> 
> And that would be because it stops at the leftmost 'delim' that is
> contained in "char[] delim" so the caller needs to know which one stopped
> the input stream? I presume that this would support Unicode characters too?

It's the other way around: you read til the _last_ character of the 
delimiter, and you look back in the buffer. If the buffer has the 
delimiter as suffix, you're done. Otherwise, repeat (while appending to 
the buffer). This should work with Unicode streams too, although I'm not 
an expert in the matter.

My point is that at end-of-file you may want to know whether the 
delimiter was correctly present, as is required in certain protocols.


Andrei