GC allocation

[Alex via Digitalmars-d-learn]

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.