Google Code Jam 2011 Language Usage

[Timon Gehr]

Andrei Alexandrescu wrote:
> On 5/8/11 3:04 PM, Timon Gehr wrote:
>> However I agree that Phobos has to provide some better input handling, since using
>> possibly unsafe C functions is the best way to do it by now. (I think readf is
>> severely crippled) I may try to implement a meaningful "read" function.
>
> Looking forward to detailed feedback about readf. It was implemented in
> a hurry so definitely it has a long way to go.
>
> Andrei

What I consider the most important points about readf:

1. Whitespace handling is different than scanf. It is much stricter and even feels
inconsistent, Eg:

int a,b;

readf("%s %s",&a,&b);//input "1 2\n" read.
readf("%s %s",&a,&b);//input "1  2\n" read (and a==1 && b==2).

readf("%s",&a);//input "1\n" read. yay.
readf("%s",&a);//input " 1\n" skipped. All subsequent input is skipped too.

readf("%s ",&a);//input "1 \n" read.
readf("%s ",&a);//input "1\n" skipped, presumably because the trailing space (!)
is missing.

readf(" %s",&a);//input "1\n" read.
readf("\t%s",&a);//input "1\n": exception is thrown.

readf("%s\n",&a);//input "1\n" read.
readf("%s\n",&a);//input "1 \n": exception is thrown.

readf("%s\t\n",&a);//input "1\t\n" read.
readf("%s \n",&a);//input "1 \n" skipped. readf throws an exception after any
further input.

And some more, I do not remember all of them. Exceptions are most of the time only
as useful as "Enforcement failed".


You (almost?) never want this behavior, even at the points it marginally makes
sense. It would be nice to have an optional whitespace-enforcing version that
_really_ enforces it
(as opposed to the current implementation), but that should not be the default.
And then it should be consistent (also on skipping or exception throwing).

2. readf takes pointers. Ugly, end of story. I even like C++ cin with all its '>>'
more.
   scanf has that problem too, but it is a C function, you _cannot_ expect it to
do any better than that.
   D has variadic template functions that may take ref parameters. It can be done
entirely pointer-free.

3. nonsense like readf("mooh",&a); cannot be caught at compile time. When/Why did
you throw away the idea of static overloads? It would have been a powerful feature,
   and very useful for this case. scanf in C/C++ does not have this problem,
because most modern compilers generate warnings for this. But that is making some
functions
   "more equal than the others"

4. readf is slow. It is about 3-4 times slower than scanf (not 2-3, as I
mistakenly claimed before). I think this is just a quality of implementation
issue, but it is important.
   Especially for programming competitions where there are time limits, you do not
want IO to unnecessarily become a mayor bottleneck. (Input files can be huge)
   Other than that, D is WAY the most convenient language I have ever tried to
solve small algorithmic tasks in.

5. Not really readf related: There's writef(ln) and there is write(ln). And then
there is readf. I will provide a proof-of-concept for the read function soon.


Timon