protocol for using InputRanges
w0rp
devw0rp at gmail.com
Fri Mar 28 10:22:26 PDT 2014
On Friday, 28 March 2014 at 16:59:05 UTC, Johannes Pfau wrote:
> It 'works' with streams but it's way too slow. You don't want
> to read
> byte-per-byte. Of course you can always implement ranges on top
> of
> streams. Usually these will not provide byte-per-byte access but
> efficient higher level abstractions (byLine, byChunk,
> decodeText).
>
> The point is you can implement ranges on streams easily, but
> you can't
> use ranges as the generic primitive for raw data. What's the
> element
> type of a data range?
> ubyte - performance sucks
> ubyte[n], ubyte[] now you have a range of ranges, most
> algorithms wont
> work as expected (find, count, ...).
>
> (the call empty/don't call empty discussion is completely
> unrelated to
> this, btw. You can implement ranges on streams either way, but
> again,
> using ranges for raw data streams is not a good idea.)
I think a key is to offer something with gives you chunks at a
time right at the top, and the use .joiner on that. I read files
this way currently.
auto fileByteRange = File("something").byChunk(chunkSize).joiner;
I believe this to be a very good way to get good performance
without losing the functionality of std.algorithm.
More information about the Digitalmars-d
mailing list