I think ideally we'd separate the notion of opening/closing/buffering
streams from fetching their data or writing to them. Data communication
should be done via ranges. So instead of having types File and class
BufferedFile, we should have File and then ranges that are buffered or
not etc.
That won't play great with C's stdio which sets buffers at FILE* level,
but I think we can come up with a good design. I've been very happy with
using File.byLine and File.byChunk as two efficient methods of reading
data from files.
Andrei
Lars Tandle Kyllingstad wrote:
Hehe.. std.stdio.File is actually one of the new parts of Phobos,
introduced with DMD 2.029 less than a year ago. (std.stream, on the
other hand, seems to be a relic from D1. It doesn't look like it's seen
major updates since 2005...)
Though the underlying code of std.stdio.File may be suboptimal, I have
taken a liking to its interface. But then again, the notion of any
input/output stream being a 'file' may not be natural for many users.
-Lars
Steve Schveighoffer wrote:
Will there be an unbuffered interface to file handles? std.stdio.File
wraps a FILE* which I find substandard. I don't think D should be
relying on C buffering for D-only constructs.
I actually find the whole notion of relying on libc a little suspect,
even for the standard handles.
Is there a document somewhere which lists which parts of phobos will
be trimmed? I am not very familiar with the library, and I'd like to
know what parts to avoid when contributing.
-Steve
----- Original Message ----
From: Andrei Alexandrescu <[email protected]>
I plan to throw away all of std.stream.
Andrei
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
