std.stream replacement

BLM768 blm768 at gmail.com
Tue Mar 5 15:24:22 PST 2013


On Tuesday, 5 March 2013 at 16:12:24 UTC, Steven Schveighoffer 
wrote:
> On Tue, 05 Mar 2013 03:22:00 -0500, Jonathan M Davis 
> <jmdavisProg at gmx.com> wrote:
>
>>
>> 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.

Ranges aren't necessarily higher- or lower-level than streams; 
they're completely orthogonal ways of looking at a data source. 
It's completely possible to build a stream interface on top of a 
range of characters, which is what I was suggesting. In that 
situation, the range is at a lower level of abstraction than the 
stream is.

> 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)

Create a range operation like "r.takeArray(n)". You can optimize 
it to take a slice of the buffer when possible.

> 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)

Range operations like std.conv.parse implicitly progress their 
source ranges. For example:

auto stream = file.byChars;
while(!stream.empty) {
     doSomethingWithInt(stream.parse!int);
}

Except for the extra ".byChars", it's just as concise as any 
other stream, and it's more flexible than something that *only* 
provides a stream interface. It also saves some duplication of 
effort; everything can lean on std.conv.parse.

Besides, streams don't necessarily progress the data; C++ 
iostreams have peek(), after all.

 From what I see, at least in terms of the interface, a stream is 
basically just a generalization of a range that supports more 
than one type as input/output. There's no reason that such a 
system couldn't be built on top of a range, especially when the 
internal representation is of a single type: characters.



More information about the Digitalmars-d mailing list