• dyh inbox.lv Dec 29 2005
• "Walter Bright" <newshound digitalmars.com> Dec 29 2005
• John Reimer <terminal.node gmail.com> Dec 29 2005
• dyh inbox.lv Dec 30 2005
• Stewart Gordon <smjg_1998 yahoo.com> Dec 30 2005
• Bruno Medeiros <I.AM FAIAL.com> Dec 30 2005
• Stewart Gordon <smjg_1998 yahoo.com> Jan 03 2006
• David Medlock <noone nowhere.com> Jan 03 2006

dyh inbox.lv writes:

In some old D newsgroup archives (sep 2003) I saw questions about unifying
function pointers and delegates. Walter mentioned that he planning to implement
some kind of thunking for it. 

Is that mean that will be possible to use nonstatic class methods as winapi
callbacks, window procedures, etc.?

How it's going, will it be anytime soon?

DYH.

"Walter Bright" <newshound digitalmars.com> writes:

<dyh inbox.lv> wrote in message news:dp1qe0$11al$1 digitaldaemon.com...
 In some old D newsgroup archives (sep 2003) I saw questions about unifying
 function pointers and delegates. Walter mentioned that he planning to 
 implement
 some kind of thunking for it.


Yes.

 Is that mean that will be possible to use nonstatic class methods as 
 winapi
 callbacks, window procedures, etc.?


Yes.

 How it's going, will it be anytime soon?


It'll be a 2.0 thing. 

John Reimer <terminal.node gmail.com> writes:

Walter Bright wrote:
 <dyh inbox.lv> wrote in message news:dp1qe0$11al$1 digitaldaemon.com...
 In some old D newsgroup archives (sep 2003) I saw questions about unifying
 function pointers and delegates. Walter mentioned that he planning to 
 implement
 some kind of thunking for it.


 Yes.
 
 Is that mean that will be possible to use nonstatic class methods as 
 winapi
 callbacks, window procedures, etc.?


 Yes.
 


Hmmm, that's the feature I've been missing for so long!

 How it's going, will it be anytime soon?


 It'll be a 2.0 thing. 
 
 


Can we name the next version 2.0, then? ;)

-JJR

dyh inbox.lv writes:

In article <dp1tt1$13og$1 digitaldaemon.com>, Walter Bright says...
 Is that mean that will be possible to use nonstatic class methods as 
 winapi
 callbacks, window procedures, etc.?


Yes.


Thanks for reply, Walter. This is the ultimate feature that I miss in c++.

DYH.

Stewart Gordon <smjg_1998 yahoo.com> writes:

Walter Bright wrote:
 <dyh inbox.lv> wrote in message
 news:dp1qe0$11al$1 digitaldaemon.com...
 
 In some old D newsgroup archives (sep 2003) I saw questions about
 unifying function pointers and delegates. Walter mentioned that he
 planning to implement some kind of thunking for it.


 Yes.
 
 Is that mean that will be possible to use nonstatic class methods
 as winapi callbacks, window procedures, etc.?


 Yes.



It would be interesting to see how this is going to work.  When you try 
to convert a delegate to a function pointer, will it wrap the delegate 
in an internal function, or what?

I can see there being more garbage collection issues to think about....

Stewart.

Bruno Medeiros <I.AM FAIAL.com> writes:

Walter Bright wrote:
 <dyh inbox.lv> wrote in message news:dp1qe0$11al$1 digitaldaemon.com...
 
In some old D newsgroup archives (sep 2003) I saw questions about unifying
function pointers and delegates. Walter mentioned that he planning to 
implement
some kind of thunking for it.


 
 Yes.
 


this when I read the D spec):
Is this unification the ability the use delegates as function pointers 
and vice-versa?

Also, Walter said on another thread that this requires:
"... runtime thunk generation and some mucking about with the gc."
What issues to the GC does this bring? At first sight, it doesn't seem 
to me any different from the creation (and memory allocation) of the 
other anonymous entities we have already.

Stewart Gordon <smjg_1998 yahoo.com> writes:

Bruno Medeiros wrote:
 Walter Bright wrote:
 
 <dyh inbox.lv> wrote in message
 news:dp1qe0$11al$1 digitaldaemon.com...
 
 In some old D newsgroup archives (sep 2003) I saw questions about 
 unifying function pointers and delegates. Walter mentioned that 
 he planning to implement some kind of thunking for it.


 Yes.


 Let me just see if I got this right (because I never quite understood 
 this when I read the D spec): Is this unification the ability the 
 use delegates as function pointers and vice-versa?


Yes.

 Also, Walter said on another thread that this requires: "... runtime 
 thunk generation and some mucking about with the gc." What issues to 
 the GC does this bring? At first sight, it doesn't seem to me any 
 different from the creation (and memory allocation) of the other 
 anonymous entities we have already.


If I'm correctly guessing how it will work, then the function that will 
be generated will hold a pointer to an object that may be allocated on 
the heap.  As such, it will be necessary to make sure the GC follows 
this pointer.

Moreover, since the main purpose of converting delegates to function 
pointers is to communicate with foreign APIs, the problem of pointers 
into the GC heap held by foreign code crops up again.

D/26273

Stewart.

David Medlock <noone nowhere.com> writes:

Stewart Gordon wrote:
 Bruno Medeiros wrote:
 
 Walter Bright wrote:

 <dyh inbox.lv> wrote in message
 news:dp1qe0$11al$1 digitaldaemon.com...

 In some old D newsgroup archives (sep 2003) I saw questions about 
 unifying function pointers and delegates. Walter mentioned that he 
 planning to implement some kind of thunking for it.



 Yes.



 Let me just see if I got this right (because I never quite understood 
 this when I read the D spec): Is this unification the ability the use 
 delegates as function pointers and vice-versa?


 
 Yes.
 
 Also, Walter said on another thread that this requires: "... runtime 
 thunk generation and some mucking about with the gc." What issues to 
 the GC does this bring? At first sight, it doesn't seem to me any 
 different from the creation (and memory allocation) of the other 
 anonymous entities we have already.


 
 If I'm correctly guessing how it will work, then the function that will 
 be generated will hold a pointer to an object that may be allocated on 
 the heap.  As such, it will be necessary to make sure the GC follows 
 this pointer.
 
 Moreover, since the main purpose of converting delegates to function 
 pointers is to communicate with foreign APIs, the problem of pointers 
 into the GC heap held by foreign code crops up again.
 
 D/26273
 
 Stewart.


I just wish for function to delegate conversion.

I don't see the benefit of delegate to function conversion.
It's problematic at best, and delegates are superior unless you are 
accessing C code.

-DavidM