std.stream replacement
Steven Schveighoffer
schveiguy at yahoo.com
Tue Mar 5 08:12:24 PST 2013
On Tue, 05 Mar 2013 03:22:00 -0500, Jonathan M Davis <jmdavisProg at gmx.com>
wrote:
> On Tuesday, March 05, 2013 09:14:16 BLM768 wrote:
>> While working on a project, I've started to realize that I miss
>> streams. If someone's not already working on bringing std.stream
>> up to snuff, I think that we should start thinking about to do
>> that.
>> Of course, with ranges being so popular (with very good reason),
>> the new stream interface would probably just be a range wrapper
>> around a file; in fact, a decent amount of functionality could be
>> implemented by just adding a byChars range to the standard File
>> struct and leaving the parsing functionality to std.conv.parse.
>> Of course, there's no reason to stop there; we could also add
>> socket streams, compressed streams, and just about any other type
>> of stream, all without an especially large amount of effort.
>> Unless someone already wants to tackle the project (or has
>> already started), I'd be willing to work out at least a basic
>> design and implementation.
>
> In general, a stream _is_ a range, making a lot of "stream" stuff
> basically
> irrelevant. What's needed then is a solid, efficient range interface on
> top of
> I/O (which we're lacking at the moment).
This is not correct. A stream is a good low-level representation of i/o.
A range is a good high-level abstraction of that i/o. We need both.
Ranges make terrible streams for two reasons:
1. r.front does not have room for 'read n bytes'. Making it do that is
awkward (e.g. r.nextRead = 20; r.front; // read 20 bytes)
2. ranges have separate operations for getting data and progressing data.
Streams by their very nature combine the two in one operation (i.e. read)
Now, ranges ARE a very good interface for a high level abstraction. But
we need a good low-level type to perform the buffering necessary to make
ranges functional. std.io is a design that hopefully will fit within the
existing File type, be compatible with C's printf, and also provides a
replacement for C's antiquated FILE * buffering stream. With tests I have
done, std.io is more efficient and more flexible/powerful than C's version.
>
> Steven Schveighoffer was working on std.io (which would be a replacement
> for
> std.stdio), and I believe that streams were supposed to be part of that,
> but
> I'm not sure. And I don't know quite what std.io's status is at this
> point, so
> I have no idea when it'll be ready for review. Steven seems to be very
> busy
> these days, so I suspect that it's been a while since much progress was
> made
> on it.
Yes, very busy :) I had taken a break from D for about 3-4 months, had to
work on my side business. Still working like mad there, but I'm carving
out as much time as I can for D.
std.io has not had pretty much any progress since I last went through the
ringer (and how!) on the forums. It is not dead, but it will take me some
time to be able to kick start it again (read: understand what the hell I
was doing there). I do plan to try in the coming months.
-Steve
More information about the Digitalmars-d
mailing list