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