Member function pointers

Manu turkeyman at gmail.com
Fri Jun 7 16:54:42 PDT 2013


On 8 June 2013 09:42, Adam D. Ruppe <destructionator at gmail.com> wrote:

> On Friday, 7 June 2013 at 23:22:03 UTC, Manu wrote:
>
>> Currently, to get the instance or function pointers from a delegate, you
>> need to do something like:
>>
>
> delegates have two members, ptr and funcptr:
> http://dlang.org/function.html
>
> As a fun fact, if you modify druntime's allocator to be malloc(), you can
> use free(delegate.ptr) to manually manage closures, though this takes a lot
> of care to know if it actually should be freed or not.
>
> Anyway, the ptr member there is always void*, however, so at least one
> cast is required to actually use it. Perhaps the language could be extended
> to make this strongly typed, but then you'd have to change the whole
> visible type as assigning say, a closure to a delegate variable would need
> to be a different type than a class member; I guess this is what you're
> talking about though.
>

Indeed, I apologise for my ignorance! The properties are already there...
but they're not properly typed.

idk, I've kinda wanted pointer to members before but I also think D's
> delegates being so versatile and interchangeable is totally boss.


I agree, a delegate is almost always what I want. But a delegate is really
just a compound concept, and without a way to express it's fundamental
parts, which in certain circumstances (like in my case) are useful on their
own, then it feels like a bit of magic.

 I don't know a syntax to describe the type of a closure, so when a
>> delegate is typed with a closure instead of a struct/class,
>> what is 'C' in the struct template above?
>>
>
> That's a tricky one, perhaps it could be a tuple of the captured
> variables' type.
>

Yeah, that was my initial feeling too... and I think it could be quite
workable in that way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130608/a69e50c1/attachment-0001.html>


More information about the Digitalmars-d mailing list