Phobos file input (Was: Re: List of issues PVS-Studio statically analyzes for )

[Walter Bright]

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.