Thread overview
Prevent copy of range in foreach
Aug 30, 2016
Yuxuan Shui
Aug 30, 2016
Ali Çehreli
Aug 31, 2016
Yuxuan Shui
Aug 31, 2016
pineapple
Aug 31, 2016
Ali Çehreli
Aug 31, 2016
Yuxuan Shui
Sep 01, 2016
Mike Parker
Aug 31, 2016
mogu
August 30, 2016
Is there a way to use a range defined with disabled post-blit in foreach? In other words, is there a way to prevent foreach from copying the range?

Should I use move()?
August 30, 2016
On 08/30/2016 12:06 PM, Yuxuan Shui wrote:
> Is there a way to use a range defined with disabled post-blit in
> foreach? In other words, is there a way to prevent foreach from copying
> the range?

It's not possible. You can't do much with such a range anyway. For example, even r.take(10) requires to copy.

Why do you want to prevent copying? There may be other ways around the issue.

> Should I use move()?

I don't know but I guess you can have a member function to do that.

Ali

August 31, 2016
On Tuesday, 30 August 2016 at 19:06:46 UTC, Yuxuan Shui wrote:
> Is there a way to use a range defined with disabled post-blit in foreach? In other words, is there a way to prevent foreach from copying the range?
>
> Should I use move()?
国人?望加群:531010036 谢谢
August 31, 2016
On Tuesday, 30 August 2016 at 20:30:12 UTC, Ali Çehreli wrote:
> On 08/30/2016 12:06 PM, Yuxuan Shui wrote:
>> Is there a way to use a range defined with disabled post-blit in
>> foreach? In other words, is there a way to prevent foreach from copying
>> the range?
>
> It's not possible. You can't do much with such a range anyway. For example, even r.take(10) requires to copy.
>
> Why do you want to prevent copying? There may be other ways around the issue.

I want to make a hash table that uses std.experiment.allocator. The bucket is allocated from an allocator, and freed in ~this(). I don't want to copy the whole bucket in this(this).

Maybe I should use a reference counter or something?

>
>> Should I use move()?
>
> I don't know but I guess you can have a member function to do that.
>
> Ali


August 31, 2016
On Wednesday, 31 August 2016 at 14:03:20 UTC, Yuxuan Shui wrote:
> I want to make a hash table that uses std.experiment.allocator. The bucket is allocated from an allocator, and freed in ~this(). I don't want to copy the whole bucket in this(this).
>
> Maybe I should use a reference counter or something?
>

A reference counter should solve the problem, but there's also the option of just making it a class instead of a struct
August 31, 2016
On 08/31/2016 07:03 AM, Yuxuan Shui wrote:

> I want to make a hash table that uses
> std.experiment.allocator. The bucket is allocated from an
> allocator, and freed in ~this(). I don't want to copy the whole
> bucket in this(this).

It sounds like you are conflating the concept of a container with the concept of a range. The range should be separate from the container and should be cheap to copy.

Ali

August 31, 2016
On Wednesday, 31 August 2016 at 18:28:20 UTC, Ali Çehreli wrote:
> On 08/31/2016 07:03 AM, Yuxuan Shui wrote:
>
> > I want to make a hash table that uses
> > std.experiment.allocator. The bucket is allocated from an
> > allocator, and freed in ~this(). I don't want to copy the
> whole
> > bucket in this(this).
>
> It sounds like you are conflating the concept of a container with the concept of a range. The range should be separate from the container and should be cheap to copy.
>
> Ali

OK, this would work for cases like containers. But what if I represent buffered network input as a range (like File.byLine), and I don't want to copy the buffer all the time? Any suggestion on how to do that correctly?
September 01, 2016
On Wednesday, 31 August 2016 at 23:38:21 UTC, Yuxuan Shui wrote:

>
> OK, this would work for cases like containers. But what if I represent buffered network input as a range (like File.byLine), and I don't want to copy the buffer all the time? Any suggestion on how to do that correctly?

Then the range should be constructed with a slice of the buffer if it's an array or with something pointer-based if it isn't (which requires a bit of bookkeeping). Ranges should be lightweight and should never require copying of the underlying data.