Streaming library

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Fri Oct 15 13:40:44 PDT 2010


On 10/15/10 14:54 CDT, Kagamin wrote:
> Denis Koroskin Wrote:
>
>>> I think, it's better to inherit Stream from InputStream and OutputStream.
>>> Do you even need endOfStream? From my experience, it's ok to
>>> blocked-read and determine end when 0 is read. Even if you read from
>>> network, is there a point in non-blocking read?
>>>
>>
>> Probably, I think I'll try both ways and see which one turns out to be
>> better.
>
> I should say, that implementation will be somewhat tricky, as different kinds of streams handle reads beyond end in different ways. Say, reading from a pipe whose write end is closed results in an error.
>
>> Either way is fine with me. But I agree yours is handy, too.
>> I was actually thinking about a plain ubyte[] read(); method:
>>
>> struct BufferedStream
>> {
>> 	ubyte[] read(); // just give me something
>> }
>
> Funny idea.
> Here we can also think about MemoryStream: when you have all the data in memory, you don't need user side buffer, and can just return direct slice to data as const(ubyte)[].

We've circled all the way back to ranges a la byChunk.

bool empty();
ubyte[] front();
void popFront();

Look ma, no copying, no fuss, no muss.

Whatever interface(s) we find work best for various kinds of streams, we 
should make them play nice with ranges. Burst streams (the kind that 
offer data in variable-size chunks) work great with a range interface.



Andrei


More information about the Digitalmars-d mailing list