On Mon, 28 Nov 2011 08:18:38 -0500, so <s...@so.so> wrote:
On Mon, 28 Nov 2011 14:54:07 +0200, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
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
I was absent from range discussions, probably it has been said, sorry.
A ### range means, a structure which implements:
T front()
void popFront()
bool empty()
This matches with:
T peek()
void seek(1)
bool eof()
T is ubyte.
The task is not to see if a stream can implement a range, it's to see if a
range can implement a stream. The target interface is the read function I
mentioned.
Nobody wants to use the "one byte at a time" input range to interface with
streams. This just furthers my point.
I believe we are asking the wrong questions, first question should be
why someone would like this simple range interface (3 functions) for
streams?
Any use? Yes with these 3 we can do quite many things, not optimal but
we can. For the real use we need a new range.
T[] get(size_t)
bool put(size_t, T[])
bool seek(size_t)
...
Don't we need a range like this in any case? I doubt we can do much
without it.
Yes, but let's not call this a "range", since it does not work in
functions that use ranges or with foreach (this is Walter's goal).
Ranges on top of streams make sense. The most classic is byLine. But
byLine is not going to use a range interface to do it's underlying work.
IMO the layers from lowest to highest are:
device stream -> buffered stream -> range
In fact, that's *exactly* what phobos does today. buffered stream (and
the underlying device stream) is FILE *.
I'm working on a replacement for FILE * which allows much more
flexibility, performance, while std.stdio will maintain the exact same
interface.
-Steve
