stream interfaces - with ranges
Mehrdad
wfunction at hotmail.com
Fri May 18 00:52:51 PDT 2012
On Thursday, 17 May 2012 at 14:02:09 UTC, Steven Schveighoffer
wrote:
> 2. I realized, buffering input stream of type T is actually an
> input range of type T[].
The trouble is, why a slice? Why not an std.array.Array? Why not
some other data source?
(Check/egg problem....)
Another problem I've noticed is the following:
Say you're tokenizing some input range, and it happens to just be
a huge, gigantic string.
It *should* be possible to turn it into tokens with slices
referring to the ORIGINAL string, which is VERY efficient because
it doesn't require *any* heap allocations whatsoever. (You just
tokenize with opApply() as you go, without every requiring a heap
allocation...)
However, this is *only* possible if you don't use the concept of
an input range!
Since you can't slice an input range, you'd be forced to use the
front() and popFront() properties. But, as soon as you do that,
you're gonna have to store the data somewhere... so your
next-best option is to append it to some new gigantic array
(instead of a bunch of small arrays, which require a lot of heap
allocations), but even then, it's not as efficient as possible,
because there's O(n) extra memory involved -- which defeats the
whole purpose of working on small chunks at a time with no heap
allocations.
(If you're going to do that, after all, you might as well read
the entire thing into a giant string at the beginning, and work
with an array anyway, discarding the whole idea of a range while
doing your tokenization.)
Any ideas on how to solve this problem?
More information about the Digitalmars-d
mailing list