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