Hurray, it works! :-)
https://run.dlang.io/is/2GMq34
I have to use classes to avoid copying when arguments are passed
to a function. (And yes, there should of course be much more
checks, especially when there are to few elements in the original
range. And it could be speed improved and so
On Sunday, 7 July 2019 at 21:55:17 UTC, Jonathan M Davis wrote:
Having one range know about the other isn't enough. That just
means that the take range would tell the other range that it
had popped an element off, and then the other would know that
it had to pop an element off. That still
On Sunday, July 7, 2019 12:36:42 PM MDT berni via Digitalmars-d-learn wrote:
> On Sunday, 7 July 2019 at 09:01:53 UTC, Jonathan M Davis wrote:
> > Without slicing, that's impossible without iterating over the
> > elements multiple times.
>
> That's what I thought too, but meanwhile I think it is
On Sunday, 7 July 2019 at 09:01:53 UTC, Jonathan M Davis wrote:
Without slicing, that's impossible without iterating over the
elements multiple times.
That's what I thought too, but meanwhile I think it is possible.
To get it working, the second range needs to know about the first
one and
On Saturday, July 6, 2019 12:58:52 PM MDT Adam D. Ruppe via Digitalmars-d-
learn wrote:
> On Saturday, 6 July 2019 at 18:17:26 UTC, Jonathan M Davis wrote:
> > take _always_ consumes the range that it's given
>
> not if it hasSlicing. see
>
On Saturday, July 6, 2019 11:02:15 PM MDT berni via Digitalmars-d-learn
wrote:
> Or better: I'd like to hand in my voucher and get back two
> vouchers, one for the first 5 bytes and one for the rest. That's
> actually, what I thought, take() is doing...
Without slicing, that's impossible without
I start to understand: A (lazy) range is something like a
voucher: byChunk() does not provide the data immediately, but
only a voucher to hand you a chunk (an array of 2 bytes in my
example above) a time. This voucher is passed to joiner(), which
keeps that voucher and hands me out a new
On Saturday, 6 July 2019 at 18:17:26 UTC, Jonathan M Davis wrote:
take _always_ consumes the range that it's given
not if it hasSlicing. see
http://dpldocs.info/experimental-docs/source/std.range.d.html#L2015
but yeah otherwise i agree with you
On Saturday, July 6, 2019 12:17:26 PM MDT Jonathan M Davis via Digitalmars-
d-learn wrote:
> On Saturday, July 6, 2019 8:12:36 AM MDT berni via Digitalmars-d-learn
>
> wrote:
> > Now it's getting weird. Meanwhile I encountered, that take()
> > sometimes consumes and sometimes not. Where can I
On Saturday, July 6, 2019 8:12:36 AM MDT berni via Digitalmars-d-learn
wrote:
> Now it's getting weird. Meanwhile I encountered, that take()
> sometimes consumes and sometimes not. Where can I learn, what is
> the reason behind this behavior? And how can I handle this?
take _always_ consumes the
On Saturday, 6 July 2019 at 14:48:04 UTC, Adam D. Ruppe wrote:
[...]
So this is a case of input range behavior - always consuming
the underlying file - combined with buffering of two elements
at once, leaving 5,6 behind, and the reuse of the buffer
meaning you see that 5,6 again on the next
On Saturday, 6 July 2019 at 14:40:23 UTC, berni wrote:
.byChunk(BUFFER_SIZE)
byChunk is defined to reuse its buffer between calls.
http://dpldocs.info/experimental-docs/std.stdio.byChunk.1.html#examples
This means previous contents are overwritten when you advance.
When I now
On Saturday, 6 July 2019 at 14:12:36 UTC, berni wrote:
Meanwhile I encountered, that take() sometimes consumes and
sometimes not.
It depends on what you're passing.
So take is defined as just getting the first N elements from the
given range. So what happens next depends on what it is
A small example showing this strange behaviour:
import std.stdio;
import std.algorithm.iteration;
import std.range;
enum BUFFER_SIZE = 1024;
void main(string[] args)
{
auto a = (new File(args[1]))
.byChunk(BUFFER_SIZE)
.joiner;
writeln(a.take(5));
writeln(a);
}
Using
Now it's getting weird. Meanwhile I encountered, that take()
sometimes consumes and sometimes not. Where can I learn, what is
the reason behind this behavior? And how can I handle this?
On Saturday, 6 July 2019 at 12:10:13 UTC, berni wrote:
On Saturday, 6 July 2019 at 11:48:51 UTC, a11e99z wrote:
Maybe I need to explain, what I dislike with this approach:
take() calls popFront n times and drop() calls popFront another
n times giving a total of 2n times (depending on the
On Saturday, 6 July 2019 at 11:48:51 UTC, a11e99z wrote:
sure
auto take_consuming( R )( ref R r, int cnt ) {
auto tmp = r.take( cnt ).array;
r = r.drop( cnt );
return tmp;
}
don't thank
Doesn't look like what I'm looking for, as it is exactly the same
I allready found.
Maybe I
On Saturday, 6 July 2019 at 11:20:50 UTC, berni wrote:
I want to copy the first n items of a range to an array, I came
up with this now:
data = r.take(n).array;
This works partly, because the values of r are not consumed. So
I have to call afterwards:
r = r.drop(n);
Now I wonder, if it is
I want to copy the first n items of a range to an array, removing
these items from the range.
This works:
foreach (i;0..n)
{
data ~= r.front;
r.popFront();
}
but looks a little bit arkward.
I came up with this now:
data = r.take(n).array;
This works partly, because the values of
19 matches
Mail list logo
