On 7/24/2011 9:17 AM, Timon Gehr wrote:
Walter Bright wrote:On 7/23/2011 4:10 AM, bearophile wrote:D doesn't currently catch errors coming from [...] bad usage of core.stdc functions (like strlen, printf, etc).This isn't likely to happen. D's mission isn't to try and fix usage of C functions.Note that currently, unsafe cstdio functions are often faster than Phobos stdio functions by a factor large enough to force people to use the C functions for IO bound tasks.
Which ones?
I don't know how many people on this newsgroup are affected by this fact. What is important to note is: This issue is a blocker for using D as a teaching language at universities.
Why would using C functions be a blocker?
std.stdio is completely compatible with cstdio functions, but that is both a benefit and a drawback: - cstdio can be used at no extra cost, very nice if you need it. - Phobos input functionality (mainly readf) is slowed down, since it cannot use an internal buffer. -- This even applies when cstdio is not used at all! -- a large part of the inefficiency of readf may be caused by the range abstraction for files: std.stdio.LockingTextReader.empty looks like a bottleneck.
To get high efficiency with I/O, you need to lock the stream at the highest level possible. If you are doing lock/readchar/unlock in a loop, you will get incredibly bad performance.
-- C++ iostreams 'solves' it with ios::sync_with_cstdio(false);
C++ iostreams is very slow.
- Another more fundamental issue is that D IO cannot be atomic. There is no way
to
implement a function that leaves the input untouched if it is invalid, and still
is compatible to cstdio.
Eg:
try a = read!int(); // oops, input is actually "abc"
catch(...){s = read!string();} // get malformed input
There's no way to back up cstdio either (beyond a single character).
Currently in case of ill-formed input, formattedRead leaves the InputRange (which is real file input in the case of readf) in whatever position the error occured, and I'm not sure if this is even specified anywhere. It is almost useless for error handling. So, if D/Phobos basically forces usage of C functions then it's job would actually be to fix their usage. Otherwise, this is an open design issue. Any thoughts on how to improve the current situation? I think Phobos should get _input_ right eventually. (and output too, what is the state of the toString issue?)
We welcome any proposals for improvements.
