Am Fri, 24 Jan 2014 09:52:23 +0100
schrieb Jacob Carlborg <doob@me.com>:

> On 2014-01-23 23:51, Martin Nowak wrote:
> 
> > Wouldn't it be possible to find out whether the delegate context ptr is actually an object? Not sure how to do it safely though and Interfaces slightly differ.
> >
> > ```d
> > import std.stdio;
> >
> > class Foo
> > {
> >      void method() {}
> > }
> >
> > void main()
> > {
> >      auto foo = new Foo;
> >      auto dg = &foo.method;
> >      // It's a class delegate!!!
> >      writeln(cast(void*)foo.classinfo.__vptr, " ",
> > ***cast(void****)dg.ptr, " ", (new ClassInfo).__vptr);
> >      assert(***cast(void****)dg.ptr is (new ClassInfo).__vptr);
> > }
> > ```
> 
> Why don't you just cast the delegate context pointer to Object? Like this:
> 
> auto result = cast(Object) dg.ptr;
> 
> If "result" is not null the context pointer points to an object. Although this won't handled interfaces. I consider it a bug that an interface cannot be casted to Object.
> 

A delegate context could be a struct or closure as well, then calling
cast(Object) is invalid and may crash.
There's no good solution, the old std.signals just assumes all
delegates belong to classes IIRC.

Why do we even need this auto-detection? Just add an additional connectWeak function which either just takes a normal delegate and require that all delegates passed to it have objects as context. Or better: add a proper WeakRef type to druntime/GC as discussed before, then use overloads.

On Thursday, 23 January 2014 at 22:37:25 UTC, Martin Nowak wrote:
> I would have really like more thorough review for the shared library pull request, although I'd like more code review in general.
> https://github.com/D-Programming-Language/druntime/pull/617

We can do it, sure. You should provide some docs / functionality overview to conform usual reviewing requirements.

On Friday, 24 January 2014 at 08:52:24 UTC, Jacob Carlborg wrote:
> Why don't you just cast the delegate context pointer to Object? Like this:
>
> auto result = cast(Object) dg.ptr;
>
> If "result" is not null the context pointer points to an object.

No, this is just a plain (i.e. no-op) cast.

> Although this won't handled interfaces. I consider it a bug that an interface cannot be casted to Object.

Not all interface implementations are (Object) classes, cf. IUnknown.

David

"David Nadlinger"  wrote in message news:nbvmhmhcszmsruszggul@forum.dlang.org...
> > Although this won't handled interfaces. I consider it a bug that an interface cannot be casted to Object.
>
> Not all interface implementations are (Object) classes, cf. IUnknown.

This is not a problem, it is known at compile time. 

24-Jan-2014 02:58, Martin Nowak пишет:
> On 01/13/2014 10:16 PM, ilya-stromberg wrote:
>>
>> It's not so good to have array of delegates because you will have a
>> memory leaks. Delegate has permanent pointer to the object, so GC will
>> never free it. As alternative, you can delete delegate manually, but in
>> this case you can have problems with manual memory management.
>>
>> So, array of delegates is possible solution, but only for VERY simple
>> cases. This module solves problem with memory leaks because it
>> implements weak connections (based on weak reference). It's easy to use,
>> but VERY difficult to implement.
>
> But weak references should be implemented on GC/druntime level.

It could be interesting to provide weak memory mapping with GC.
Could be very useful for caches.

-- 
Dmitry Olshansky

On 2014-01-24 10:06, Johannes Pfau wrote:

> A delegate context could be a struct or closure as well, then calling
> cast(Object) is invalid and may crash.
> There's no good solution, the old std.signals just assumes all
> delegates belong to classes IIRC.

I just tried with a nested function and that returned "null". Was that just luck?

-- 
/Jacob Carlborg

On 2014-01-24 12:52, Daniel Murphy wrote:

> This is not a problem, it is known at compile time.

Exactly.

-- 
/Jacob Carlborg

On 2014-01-24 12:13, David Nadlinger wrote:

> No, this is just a plain (i.e. no-op) cast.

It seemed to work when I tested it. Ok, I see what I did wrong. I forgot to actually refer to an outer variable in my nested function.

-- 
/Jacob Carlborg