stdio performance in tango, stdlib, and perl

Roberto Mariottini rmariottini at mail.com
Thu Mar 22 01:27:55 PDT 2007


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.

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

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

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

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

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

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

Ciao



More information about the Digitalmars-d mailing list