I want to assign a function ptr to a void* variable.

There are no compile error in case the function is a overloaded one. Is this a bug?

How to select the correct function? I tried a cast, and it seams to work.

void fnc(){}
void fnc(int a ){}

void * ptr = cast(void*)cast( void function( int )) & fnc;

"Frank Benoit (keinfarbton)" <benoit@tionex.removethispart.de> wrote in message news:erpk4o$1oom$1@digitalmars.com...
>I want to assign a function ptr to a void* variable.
>
> There are no compile error in case the function is a overloaded one. Is this a bug?
>
> How to select the correct function? I tried a cast, and it seams to work.
>
> void fnc(){}
> void fnc(int a ){}
>
> void * ptr = cast(void*)cast( void function( int )) & fnc;

Yes, that does seem to choose the (int) overload.  Although what's really odd is that getting the address of fnc without any cast before it gets the address of the overload that was defined first.  Personally I think it should be an error, as it's ambiguous..

Jarrett Billingsley wrote:
> "Frank Benoit (keinfarbton)" <benoit@tionex.removethispart.de> wrote in message news:erpk4o$1oom$1@digitalmars.com...
>> I want to assign a function ptr to a void* variable.
>>
>> There are no compile error in case the function is a overloaded one. Is
>> this a bug?
>>
>> How to select the correct function? I tried a cast, and it seams to work.
>>
>> void fnc(){}
>> void fnc(int a ){}
>>
>> void * ptr = cast(void*)cast( void function( int )) & fnc;
> 
> Yes, that does seem to choose the (int) overload.  Although what's really odd is that getting the address of fnc without any cast before it gets the address of the overload that was defined first.  Personally I think it should be an error, as it's ambiguous.. 
> 
> 

And now one of the classic proposals, once again.  :)

void* ptr = cast(void*) &fnc(int) ;

So nice, so concise.

-- Chris Nicholson-Sauls

> Personally I think it should be an error, as it's ambiguous..
> 
posted:
http://d.puremagic.com/issues/show_bug.cgi?id=1006

Jarrett Billingsley wrote:
> "Frank Benoit (keinfarbton)" <benoit@tionex.removethispart.de> wrote in message news:erpk4o$1oom$1@digitalmars.com...
> 
>>I want to assign a function ptr to a void* variable.
>>
>>There are no compile error in case the function is a overloaded one. Is
>>this a bug?
>>
>>How to select the correct function? I tried a cast, and it seams to work.
>>
>>void fnc(){}
>>void fnc(int a ){}
>>
>>void * ptr = cast(void*)cast( void function( int )) & fnc;
> 
> 
> Yes, that does seem to choose the (int) overload.  Although what's really odd is that getting the address of fnc without any cast before it gets the address of the overload that was defined first.  Personally I think it should be an error, as it's ambiguous.. 
> 
> 

What we really need is a way to get a tuple of all of the function types associated with a given symbol. Something like:

fnc.tupleof => Tuple!(void function(), void function(int))

Making the above an error without providing a mechanism like this would adversely affect Pyd, for example.

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org

> And now one of the classic proposals, once again.  :)
> 
> void* ptr = cast(void*) &fnc(int) ;

Is this perhaps a problem with context free syntax?
It is not clear, if this is a "get function pointer address" or a "call
function" operation.

void* ptr = cast(void*) &fnc( Something ) ;

To decide this, the compiler needs to have the arguments completely resolved. Then he can see if they are types, or not.

Reply to Frank,

>> And now one of the classic proposals, once again.  :)
>> 
>> void* ptr = cast(void*) &fnc(int) ;
>> 
> Is this perhaps a problem with context free syntax?
> It is not clear, if this is a "get function pointer address" or a
> "call
> function" operation.
> void* ptr = cast(void*) &fnc( Something ) ;
> 
> To decide this, the compiler needs to have the arguments completely
> resolved. Then he can see if they are types, or not.
> 

The "address of" should resolve that because you can't take the address of a return. OTOH that would introduce L-value/R-value into the grammar. Maybe the syntax of a function call could allow a type list or an expression list (but not a mixed list) and then the semantics would sort it out later. Bahh, The more I think about this stuff the more I respect Walter.