Jump to page: 1 2
Thread overview
Is there anyway to make opApply @nogc?
Jun 20, 2016
Gary Willoughby
Jun 20, 2016
Mathias Lang
Jun 20, 2016
Gary Willoughby
Jun 20, 2016
Adam D. Ruppe
Jun 20, 2016
Gary Willoughby
Jun 20, 2016
Gary Willoughby
Jun 21, 2016
Gary Willoughby
Jun 21, 2016
Adam D. Ruppe
Jun 21, 2016
Gary Willoughby
Jun 22, 2016
Marc Schütz
Jun 22, 2016
Gary Willoughby
June 20, 2016
Is there any way to make opApply @nogc? or provide the same foreach functionality without implementing a range interface?

I want to iterate over a piece of memory using a pointer. I thought about using opSlice but that doesn't provide information for an index in a foreach loop.

auto opSlice()
{
    return this._pointer[0 .. size];
}

Anyone got any ideas?
June 20, 2016
On Monday, 20 June 2016 at 14:08:58 UTC, Gary Willoughby wrote:
> Is there any way to make opApply @nogc? or provide the same foreach functionality without implementing a range interface?
>
> I want to iterate over a piece of memory using a pointer. I thought about using opSlice but that doesn't provide information for an index in a foreach loop.
>
> auto opSlice()
> {
>     return this._pointer[0 .. size];
> }
>
> Anyone got any ideas?

Can't `opApply` with `auto` return type works since it infers attributes ?
June 20, 2016
On Monday, 20 June 2016 at 14:34:33 UTC, Mathias Lang wrote:
> Can't `opApply` with `auto` return type works since it infers attributes ?

I think the problem is that the delegate which is required by opApply is allocated using the GC.
June 20, 2016
On Monday, 20 June 2016 at 15:13:53 UTC, Gary Willoughby wrote:
> I think the problem is that the delegate which is required by opApply is allocated using the GC.

make the delegate in opApply scope

int opApply(scope int delegate(whatever) dg)
June 20, 2016
On Monday, 20 June 2016 at 15:27:32 UTC, Adam D. Ruppe wrote:
> On Monday, 20 June 2016 at 15:13:53 UTC, Gary Willoughby wrote:
>> I think the problem is that the delegate which is required by opApply is allocated using the GC.
>
> make the delegate in opApply scope
>
> int opApply(scope int delegate(whatever) dg)

What effect does this have? and how does it beat the GC?
June 20, 2016
On Monday, 20 June 2016 at 15:47:44 UTC, Gary Willoughby wrote:
> On Monday, 20 June 2016 at 15:27:32 UTC, Adam D. Ruppe wrote:
>> On Monday, 20 June 2016 at 15:13:53 UTC, Gary Willoughby wrote:
>>> I think the problem is that the delegate which is required by opApply is allocated using the GC.
>>
>> make the delegate in opApply scope
>>
>> int opApply(scope int delegate(whatever) dg)
>
> What effect does this have? and how does it beat the GC?

Found the explanation here:

http://stackoverflow.com/questions/4711309/meaning-of-scope-in-d-for-a-parameter

I give it a go. Thanks.
June 21, 2016
On Monday, 20 June 2016 at 15:27:32 UTC, Adam D. Ruppe wrote:
> On Monday, 20 June 2016 at 15:13:53 UTC, Gary Willoughby wrote:
>> I think the problem is that the delegate which is required by opApply is allocated using the GC.
>
> make the delegate in opApply scope
>
> int opApply(scope int delegate(whatever) dg)

I'm still not sure what this achieves. The description on the stackoverflow question reads: "And when the compiler sees this on delegates, it will avoid allocating a closure when taking the address of a local function. This is essential in opApply loops."

I have no idea what that means. Can anyone shed more light on this, please?
June 21, 2016
On Tuesday, 21 June 2016 at 12:48:04 UTC, Gary Willoughby wrote:
> I have no idea what that means. Can anyone shed more light on this, please?

So when you use local variables in a delegate, the compiler usually makes a copy of them just in case the delegate gets saved for later.

When you mark it scope, you promise that you won't save it for later, so the compiler skips making the copy.
June 21, 2016
On Tuesday, 21 June 2016 at 12:53:11 UTC, Adam D. Ruppe wrote:
> On Tuesday, 21 June 2016 at 12:48:04 UTC, Gary Willoughby wrote:
>> I have no idea what that means. Can anyone shed more light on this, please?
>
> So when you use local variables in a delegate, the compiler usually makes a copy of them just in case the delegate gets saved for later.
>
> When you mark it scope, you promise that you won't save it for later, so the compiler skips making the copy.

Right ok, thanks! It doesn't seem to help though as the compiler complains about it being not @nogc.
June 22, 2016
On Tuesday, 21 June 2016 at 19:21:01 UTC, Gary Willoughby wrote:
> Right ok, thanks! It doesn't seem to help though as the compiler complains about it being not @nogc.

You probably need to declare the delegate and opApply() itself as @nogc, too:

int opApply(scope int delegate(int) @nogc dg) @nogc { }
« First   ‹ Prev
1 2