26-Mar-2014 04:55, Andrei Alexandrescu пишет:
The recent discussion initiated by Walter points to a problem known
since a long time ago: ranges are well modeled by objects in memory
(arrays, lists, other containers) but poorly by objects that need to
load or construct elements on the fly.
Here are some scenarios that we need to accommodate:
I've observed that ranges do mostly fine on top of buffering primitive.
Said primitive provides direct access to underlying array.
For cases listed below I've come to conclusion that we'd need a generic
sliding-window (over whatever is the true source of data) abstraction. I
call it a buffer, and a special range over said abstraction a buffer-range.
Key observation on the level of ranges is that we need something that
looks a lot like RA range, has slicing, but doesn't have length. There
must be a way to do queries like "is there X elements available" and
"please extend/move underlying window to have at least Y elements ahead
available".
1. Files and sockets
Fastest access is implemented at the OS level by means of read() that
takes a user-provided buffer.
Ranges would need at least buffering primitive below. It may or may not
be backed by file/socket descriptor down below (say MM-file easily
provides buffer interface by re-mapping different views of file).
2. Compression, decompression, encryption, decryption
This is much better addressed at the level of buffering itself, i.e.
making an adapter/filter for a buffer.
I think certain sizes would work better than others, but I'm not sure
how that all goes. A good case study.
3. Of course character encoding, decoding, and transcoding.
Also seems to be decently addressed as filter for buffers. Depending on
the kind of the trade-off between laziness vs throughput it may be
postponed to ranges.
--
Dmitry Olshansky
