Andrei Khropov wrote:
> BCS wrote:
>>
>>a while back someone found out that you can take a delegate and replace the
>>internal function pointer with a regular function pointer and it still works
>>just fine. Given this, you could wright a little function*-to-delegate
>>function and let people do this
>>
[...]
>>
>>I known this is an ugly hack, OTOH maybe Walter can be convinced to add a
>>function-pointer to delegate cast that does this in a consistent manner.
>>
>>cast(int delegate(int))&fn
> 
> 
> maybe just "cast(delegate)&fn" in the spirit of inferred typing?
> 
> 

That /would/ be better.

BCS wrote:
> Chad J wrote:
>> So I have decided to roll my own GUI library, one dedicated to computer games.  But I've run into a bit of an unpleasant design problem - for handling callbacks, how should my library expose function pointers and delegates?
>>
> [...]
> 
> a while back someone found out that you can take a delegate and replace the internal function pointer with a regular function pointer and it still works just fine. 

It works fine *most of the time*. IIRC, sometimes it will result in incorrect code. We could deal with those cases if we knew the exact circumstances under which function parameters are passed in registers. But until the ABI gets formalised, it's a non-portable hack that occasionally fails.

Bruno Medeiros escribió:
> Carlos Santander wrote:
>> Derek Parnell escribió:
>>> Sure you can! How about this ...
>>>
>>>
>>>  import std.stdio;
>>>
>>>  int delegate(int) increment;
>>>
>>>  void main()
>>>  {
>>>     writefln( increment(1) );
>>>     writefln( incr(2) );
>>>  }
>>>
>>>  int incr( int a )
>>>  {
>>>      return a + 1;
>>>  }
>>>
>>>  static this()
>>>  {
>>>      increment = delegate int ( int a ) {return incr(a); };
>>>  }
>>>
>>> Would that do?
>>>  
>>
>> I thought the frame pointer would get lost and cause a segfault later on (see DFL events handling for an example.) Did that change with 0.161?
>>
> 
> The frame pointer becomes invalid, but that is no problem since the delegate is function-like and does not access the frame context (i.e., it's not a closure).
> 

In this case, yes, you're right. I must admit I didn't notice that. However, in other circumstances (more complex, I'd say) it's a valid point to take into account.

-- 
Carlos Santander Bernal

Don Clugston wrote:
> BCS wrote:
> 
>> Chad J wrote:
>>
>>> So I have decided to roll my own GUI library, one dedicated to computer games.  But I've run into a bit of an unpleasant design problem - for handling callbacks, how should my library expose function pointers and delegates?
>>>
>> [...]
>>
>> a while back someone found out that you can take a delegate and replace the internal function pointer with a regular function pointer and it still works just fine. 
> 
> 
> It works fine *most of the time*. IIRC, sometimes it will result in incorrect code. We could deal with those cases if we knew the exact circumstances under which function parameters are passed in registers. But until the ABI gets formalised, it's a non-portable hack that occasionally fails.

I wouldn't use it (if possible) even if it was portable. The compiler should do this for you.

cast(delegate)fnpt;