Jerry Quinn wrote:
OK, having thought a bit more about delegates, I now have another question.
The ABI shows a delegate as consisting of a context ptr and a function ptr.
The context ptr can be a class reference, ptr to struct, ptr to closure or ptr
to stack frame.
If you're passing one of these delegates into another function, how does the
receiving function figure out what kind of context it's looking at? Each of
these things will look different in memory. Also, structs at least don't have
a header that can be used to disambiguate the situation.
The caller just passes the context pointer as a hidden argument when
calling the function ptr and doesn't care about the rest. It's up to the
code on the callee side to actually use the context pointer.
But there's never an ambiguity what the callee expects as the context
pointer. It's simple: if you take a delegate of an object method, the
context pointer has to be a class reference. If you take a delegate of a
nested function, the context pointer must point to the stack frame. And
so on.
If you want to say so, the code referenced by the function pointer
decides how the context pointer is interpreted.
Note that this can never go wrong: it's not possible to take a delegate
of a class method and (somehow) to use a frame pointer as the context
pointer.
Thanks,
Jerry
