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