On Sunday, 31 May 2015 at 17:50:41 UTC, Dmitry Olshansky wrote:
On 31-May-2015 18:58, Andrei Alexandrescu wrote:
On 5/31/15 8:44 AM, Nick Sabalausky wrote:
On 05/30/2015 07:06 AM, short2cave wrote:
Do the classic streams still make sense when we have Ranges ?
I've been thinking the same thing lately. In fact, I'd been
meaning to
make a post regarding that.
Phobos's std.stream has been slated for an overhaul for
awhile now, but
it seems to me that ranges are already 90% of the way to
BEING a total
std.stream replacement:
Output Streams: AFAICT, 100% covered by output ranges. Output
streams
exist as a place for sticking arbitrary amounts of sequential
data.
Output range's "put" does exactly that.
Input Streams: Input ranges are very nearly a match for this.
AFAICT,
The only thing missing here is the ability to "read" not just
the one
"front" value, but to read the front N values as a chunk,
without an
O(n) sequence of front/popFront. So we'd just need another
"optional"
range characteristic: hasFrontN (or some such).
Given that it seems Design by Introspection has been working
well for us
and we're continuing to enhance its use in Phobos, it seems to
me that
optional methods for ranges are the way to go.
An optional method for any range is
size_t bulkRead(T[] target);
which fills as much as possible from target and returns the
number of
items copied.
Another good candidate for optional methods is lookahead.
Hardly. In fact, I've spent quite some time trying to figure
this out.
Doing bulk read to some array is the pushing burden of
maintaining some buffer on the user and adding the overhead of
extra copy on buffered streams. Not to mention that the more
methods we put in range API the more if/else forests we produce
in our algorithms.
LinearBuffer tries to address this problem in:
https://github.com/D-Programming-Language/phobos/pull/2928
This simply extends the existing std.array.Appender with
popFrontN operations.
The use case would be like this:
1. accumulate data in the LiniearBuffer by appending to the buffer
2. try to identify the next token
3. if a token is identified popFontN the length of the token
4. otherwise acumulate some more (go to 1.)
I was also thinking about adding a new method:
ptrdiff_t putFrom(ptrdiff_t delegate(T[]) read);
meant to be used together with file read or socket receive
functions. In this way the read/recv system functions can write
directly into the input buffer without intermediate copies.
Dragos
