How to understand context type of a delegate?

Jacob Shtokolov jacob.100205 at gmail.com
Sat Sep 8 10:10:24 UTC 2018


On Wednesday, 5 September 2018 at 16:53:42 UTC, NX wrote:
> Is there a way to know what kind of context a delegate has 
> either in compile time or runtime?
>
> Also is there any way to check whether a pointer legitimately 
> points to an Object instance?

No and no. I was fighting this problem in std.signals but found 
only one way to fix that without breaking backwards 
compatibility: we can use core.memory.GC class in order to check 
whether the object was allocated by GC (GC.addrOf). If it was, we 
need to retain the delegate context pointer to prevent accidental 
deallocation of this class by GC.

And if the object is not managed by GC, it means that the 
delegate's context is a simple anonymous function, struct 
function, or manually allocated delegate's heap (there are few 
more cases though).

In this case we just allow the user to manage this object 
manually. So if he decides to deallocate the entity behind the 
context pointer, he should be ready for a segmentation fault if 
he didn't remove an object from listeners before deallocation.

The main reason why std.signals allows only objects to be used as 
a delegate context is that every object is tracked by D runtime 
(by the so-called Monitor object) and even in the case of manual 
deallocation (if you're using the std.experimental.allocator), 
you will be notified about object destruction if you were 
subscribed to this event.

This makes the implementation extremely safe, but the author of 
the original library didn't finish his work properly. So 
std.signals now is a good candidate for replacement.

I'm working on the fix and will create a pull request soon. Not 
sure if it will be accepted, but this module definitely needs to 
be replaced. If you want to join me in this work, I can share 
additional details about the situation around std.signals in 
general.

If you don't want to spend your time on this, check this module: 
https://github.com/buggins/dlangui/blob/master/src/dlangui/core/signals.d - it's a part of the DlangUI project which already contains most of the things you may need.


More information about the Digitalmars-d-learn mailing list