Unbuffered range interface

[Dmitry Olshansky]

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