On Thursday, 21 April 2016 at 19:54:10 UTC, via
Digitalmars-d-learn wrote:
I'm on mobile so I will be brief now and expand later
On Thu, Apr 21, 2016 at 07:37:59PM +0000, QAston via
Digitalmars-d-learn wrote:
Just like classes - when closure expression is executed.
Heap closures are actually allocated on declaration. The
compiler looks to see if it will need to be copied and if so,
avoids it by just using the heap to begin with.
Ok... I make slices of them, carefully avoiding to make copies...
Instead of using a delegate you can use a Struct with opCall.
Indeed, though delegates do not necessarily allocate. If they
come from &obj.member, they never do. If the usage point calls
them scope, they never do. If the usage is an alias arg and it
can be inlined, it might not.
Huh? I think, this is the place, where I lack some background...
So, I bind my delegates via
auto initDelegates(uint delegatesAmount)
{
return iota(delegatesAmount).map!(a => (MM p) =>
.dDelegate(a, p));
}
and in a class constructor I call this method
.delegates = .initDelegates(delegateAmount);
and
.dDelegate = &this.delegateDefinition;
where delegateDefinition is a member function of an uint and the
MM type.
However, if you do &obj.member you do need to be sure obj stays
alive while
the delegate is in use, so struct w/ opCall may make lifetime
management easier.
Yes. I'm sure the object is alive till the very end. As mentioned
above, do you think it is worth to make a struct to save a result
from iota?
Nevertheless, my intention here is speed, so a fast solution is
much better, then any slow one, even if the speed gain is 10%
only... But the construction effort is almost negligible.
