On Sat, 26 Nov 2011 16:39:38 -0500, Walter Bright
<newshou...@digitalmars.com> wrote:
On 11/26/2011 5:46 AM, Steven Schveighoffer wrote:
Ranges are not good for reading N bytes from a file
descriptor.
Why not? Isn't that exactly what a range is supposed to be good for?
A range has a specific interface:
T front()
void popFront()
bool empty()
An input stream has a specific interface:
size_t read(ubyte[] buffer)
or alternatively:
ubyte[] read(ubyte[] buffer)
How does one map that interface into an input range? What is T? I
remember proposals where there was some extra function setFrontBytes, or
an additional parameter to front, that allows you to set the number of
bytes to read. This seems like trying to fit a square peg in a round hole.
Now, a range fits very well on top of an input stream with a given
context. That context defines *what* front() is going to return. For
example, the next line of text.
But you still need a well-designed buffered stream interface that a range
can use to do its work from. Streams are not going to be the main
interface for most users, but they will be the tools that range developers
use to create easily iterated streams. And when the user wants to read
data from a file that has no well-defined T that you can define a range
for, the stream should provide all the tools necessary to read that data.
Now, an output stream *does* fit quite well as a range, since an output
range's single put method coincides with an ouptut stream's write method.
-Steve
