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