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

downs default_357-line at yahoo.de
Thu Oct 4 21:35:04 PDT 2007


BCS wrote:
> Reply to Downs,
> 
>> BCS wrote:
>>
>>> Reply to Downs,
>>>
>>>> BCS wrote:
>>>>
>>>>> Fun
>>>>> Bar.opApply  <<<<<
>>>>> Fun.foreachBody_1
>>>> Again, you're missing something.
>>>> The void[] data property I'm proposing does not contain the complete
>>>> stack of the delegate. Since part of that stack (the delegate's)
>>>> doesn't even EXIST when the delegate is created, this would be
>>>> rather
>>>> pointless. Instead, data references the stack area _outside_ of the
>>>> delegate that the delegate uses. So in this case, that would be Fun,
>>>> directly followed by its foreach body; two parts of the stack which
>>>> indeed form a continuous area. I hope that clears things up.
>>>> --downs
>>> In between the Fun frame and the foreach frame is the opApply frame
>>> (or several frames). If you keep nesting function and passing
>>> delegate to arbitrary code to be called deeper in the stack, sooner
>>> or later, you get a gap of unknown size.
>>>
>> That is correct.
>> And since the void[] data and the immediate stack space of the
>> function
>> don't need to have any direct relationship, it isn't a problem.
>> The stack space of the function is accessed via the SP or an
>> equivalent
>> register. The outer stack area is accessed via (currently) void *ptr
>> or
>> (proposed) void[] data. The two are separate areas. I don't see the
>> problem.
>> --downs
>>
> 
> but from within the delegate the delegates frame is accessed with the
> SP, the foreach body's frame is accessed with the void *ptr or void[]
> data. But what is the outermost frame accessed with? Currently I think
> it is accessed with chained indirection (look in my outer function for
> his outer function's pointer, then use that pointer to find the next one
> etc.). This would still work with your proposal, but it gets all the
> issues of deep vs. shallow copies, which kinda defeats the point of the
> proposal.
> 
Yes.
The idea is, since chained indirection only accesses consecutive stack
frames anyway, void[] data contains _all_ the *outer* stack frames which
the function *does* access, information which is definitely known at
compile time. Since their size is also known, we can do away with
chained indirection as well and simply use a fixed index in data.

> If you don't see my point for this case, consider this; the accessable (sp.)
> scope of a nested function can contain an arbitrary number of non
> adjacent stack frames simply by passing callbacks to other function
> where the callback does the same.
This is simply false.
The stack space of other passed-in functions is not directly accessible
from the current function. Thus, it is entirely irrelevant to this
debate. How to access this space is the problem of the passed-in
functions alone.

 --downs



More information about the Digitalmars-d mailing list