Feature Request: Change the delegate type to void[] data insteadofvoid *ptr.

BCS ao at pathlink.com
Thu Oct 4 08:08:24 PDT 2007


Reply to Downs,

> BCS wrote:
> 
>> Reply to Downs,
>> 
>>>> R delegate(T) close(R, T...)(R delegate(T) dg)
>>>> {
>>>> typeof(dg) res=dg;
>>>> res.data=res.data.dup; // eventually moves area of stack into RAM
>>>> return res;
>>>> }
>> how will that more stack data into ram? If the delegate gets an array
>> of pointers to stack frames (or objects) then what you get is a copy
>> of the pointers that still point into the stack (or objects).
>> 
> You misunderstand.
> void[] is not an array of void pointers, but a continuous segment of
> memory; that being, all the stack the method does access.
>> If what you have
>> is a slice of the stack, then what about the next function out? you
>> will
>> either still have a reference to another stack frame, or won't have
>> access to it at all.
> Not true.
> The compiler can determine at compile-time which stack frames the
> function does access. It can then use that data to calculate the
> pointer
> (as an offset to the SP) and length of the array.
>> You might get something with a void[][], but then
>> you need to do an alloc on each delegate creation, not to mention
>> Gregor's issue.
> Yeah, see above. A void[] is sufficient. And Gregor's issue is more of
> a caveat - I do not believe the cost overhead of delegate _creation_
> to be a significant problem.
> 
> Thanks for your feedback :)
> --downs


|class Bar { int opApply( int delegate(inout int) dg) {...} }
|
|void Fun(Bar b)
| {
|  int i;
|  foreach(inout j ; b)
|  {
|    i+=j;
|    h=0
|    int nest(inout int k)
|    {
|      i+=k;
|      h-=k;
|      return 0;
|    }
|    b.opApply(&nest)
|  }
|}


There are three nested function here.

Fun, the foreach body and the nest function

when the nest function is turned into a delegate in the opApply function, 
the stack looks like this

Fun
Bar.opApply  <<<<<
Fun.foreachBody_1

potentially, I could add code later that would put an even bigger (or smaller) 
chunk of data between the Fun stack frame and the foreach body stack frame. 
In general this can't be detected at compile time because I could do this 
by deriving a class from Bar.





More information about the Digitalmars-d mailing list