stdio performance in tango, stdlib, and perl

[Andrei Alexandrescu (See Website For Email)]

Roberto Mariottini wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
> [...]
>  >
>>> Can you distill the benefits of retaining CR on a readline, please?
>>
>> I am pasting fragments from an email to Walter. He suggested this at a 
>> point, and I managed to persuade him to keep the newline in there.
> 
> I suspect Walter was thinking on something else at the time.
> 
>> Essentially it's about information. The naive loop:
>>
>> while (readln(line)) {
>>   write(line);
>> }
> 
> I'm completely against that awful mess of code.

What exactly would be bad about it?

>> is guaranteed 100% to produce an accurate copy of its input. The 
>> version that chops lines looks like:
>>
>> while (readln(line)) {
>>   writeln(line);
>> }
>>
>> This may or may not add a newline to the output, possibly creating a 
>> file larger by one byte.
> 
> Are you sure? Can you elaborate more on this?

Very simple. If the file ends with a newline, the code reproduces it. If 
not, the code gratuitously appends a newline.

>  > This is the kind of imprecision that makes the
>> difference between a well-designed API and an almost-good one. 
>> Moreover, with the automated chopping it is basically impossible to 
>> write a program that exactly reproduces its input because readln 
>> essentially loses information.
> 
> Same here.
> 
>> Also, stdio also offers a readln() that creates a new line on every 
>> call. That is useful if you want fresh lines every read:
>>
>> char[] line;
>> while ((line = readln()).length > 0) {
>>   ++dictionary[line];
>> }
> 
> This way you'll get two different dictionaries on Windows and on Unix.
> Wrong, very wrong.

Yes, wrong, very wrong. Except it's not me who's wrong :o).

>> The code _just works_ because an empty line means _precisely_ and 
>> without the shadow of a doubt that the file has ended. (An I/O error 
>> throws an exception, and does NOT return an empty line; that is 
>> another important point.) An API that uses automated chopping should 
>> not offer such a function because an empty line may mean that an empty 
>> line was read, or that it's eof time. So the API would force people to 
>> write convoluted code.
> 
> What is your definition of "convolute"?
> I find your code 'convolute', 'unclear', 'buggy' and 'unportable'.

You are objectively wrong. The code is portable. Newline translation 
takes care of it. Just try it.

>> In the couple of years I've used Perl I've thanked the Perl folks for 
>> their readline decision numerous times.
> 
> Per is something the world should get rid of, quickly.
> Per is wrong, Perl is evil, Perl is useless.
> You don't need Perl, try to cease using it.
> 
> The fact that this narrow-minded idea comes from Perl is not surprising.

What can I say? Thanks! I'm enlightened!

>> Ever tried to do cin or fscanf? You can't do any intelligent input 
>> with them because they skip whitespace and newlines like it's out of 
>> style. 
> 
> I use them, and I find them very comfortable.
> Again your definition of 'intelligent' is particular.
> If you find Perl 'intelligent', this say a lot.

To each their own :o). Oh, probably you could explain how I can read a 
string containing spaces, followed by ":" and a number with scanf. Takes 
one line in Perl and D's readfln (not yet distributed).

>> All of my C++ applications use getline() or fgets() (both of which 
>> thankfully do include the newline) and then process the line in-situ.
> 
> You obviously program only for one single platform.
> Being portable is way more complex than this.

Yep, I saw that :o).


Andrei