File Api [Was: [your code here]]

Brad Anderson eco at gnuk.net
Fri Feb 17 19:41:09 PST 2012


On Saturday, 18 February 2012 at 02:46:52 UTC, H. S. Teoh wrote:
> On Fri, Feb 17, 2012 at 09:20:59PM -0500, bearophile wrote:
>> H. S. Teoh:
>> 
>> > P.S.S. The .idup is a bit ugly, but necessary, since 
>> > apparently
>> > byLine() calls readln() with a static buffer, so choice will 
>> > be
>> > silently overwritten if the .idup is omitted.
>> 
>> An alternative File API that to me looks nice. This is a first 
>> part,
>> it's for scripting-like or not high performance purposes, it 
>> looks
>> essentially like Python code, every line is a newly allocated 
>> string:
>> 
>> import std.stdio;
>> void main() {
>>     string[] lines;
>>     foreach (line; File("data.dat")) {
>>         static assert(is(line == string));
>>         lines ~= line;
>>     }
>> }
>
> I don't think it's a good idea to have File() automatically 
> iterate by
> lines. What if data.dat is binary? I think it's still better to 
> have:
>
> 	foreach (line; File("...").lines()) { ... }
>
> where File.lines() is a lazy method that reads the file 
> line-by-line.
>
> For binary files, you could have File.byChunk!T() where T can 
> be any
> type, struct, etc., with the appropriate method for 
> construction on
> input.
>
>
>> If you don't want a new buffer every line you use something 
>> like this:
>> 
>> import std.stdio;
>> void main() {
>>     string[] lines;
>>     foreach (line; File("data.dat").fastLines()) {
>>         static assert(is(line == char[]));
>>         lines ~= line.idup;
>>     }
>> }
>> 
>> So on default it's handy, short and safe, and with a method 
>> you avoid
>> an allocation every line and get a mutable char[].
>
> Makes sense.
>
>
>> Maybe even this works, downloads a page and scans its lines, 
>> but maybe
>> it's better to add a bit of extra safety to this:
>> foreach (line; File("http://www.dlang.org/faq.html")) {}
> [...]
>
> I don't know about this, I would prefer downloading files to be 
> in
> another class, not File. As long as they provide a Range 
> interface it's
> good enough. Perhaps File and NetworkFile (or whatever you want 
> to call
> it) can implement the same interface, .lines() for safe 
> iteration,
> .fastLines() for buffered iteration.
>
> Anyway, is anyone working on a new file I/O interface? I'd like 
> to see
> std.stream and std.stdio combined, for one thing. Or replaced 
> with a
> range-based API.
>
>
> T

Steve Schveighoffer's work in progress on std.io:

https://github.com/schveiguy/phobos/blob/new-io/std/io.d

Regards,
Brad Anderson


More information about the Digitalmars-d mailing list