Why no generic function pointers?

[Tor Rustad]

Re: Why no generic function pointers?

Ben Bacarisse skrev:

Tor Rustad <tor_rustad@hot mail.comwrites:
>

>Ben Bacarisse skrev:

[...]

>>Just to be clear, I was focusing on the function call. At that point,
>>there is not enough information for the compiler to generate a correct
>>call, at least not in the most general case.

>The compiler can very much generate the correct call, BUT it's a
>different matter if such a function exist, and this is the job of the
>run-time loader to detect.

>
I was making a narrow technical point: given a generic function
pointer type, a C function call does not have the information required
to check the type and generate the correct calling code. Assume fp is
such a generic pointer. What is the type of function being called
here:
>
fp(12.3);

Ohh..no

we can't do pointer arithmetic on pointer-to-void either:

void foo(void *p)
{
(*(char *)p)++;
}

so I don't see why you assume I somehow suggest that calling a "generic
function pointer" to be meaningful.


Converting a function pointer to some "generic function pointer", would
throw away information, while converting a "generic function pointer" to
a function pointer, would add information.

I don't see why such conversion should be explicit (i.e. require a
cast), other than as providing a comment for humans (that is, if typedef
of the function pointer is used, else not very readable).


Hmm.. another possibly useful thing with a "generic function pointer",
could be to hold functions (of different types) in a jump table:

gen_func_t jmp[3] = {f1, f2, f3};


Anyway, this is rather academic... in ca. 99,99% IRL cases, void* will
work fine as a generic function pointer. :)

--
Tor <bwzcab@wvtqvm. vw | tr i-za-h a-z>

[Ben Bacarisse]

Re: Why no generic function pointers?

Tor Rustad <bwzcab@wvtqvm. vwwrites:

Ben Bacarisse skrev:

>Tor Rustad <tor_rustad@hot mail.comwrites:
>>

>>Ben Bacarisse skrev:

>
[...]
>

>>>Just to be clear, I was focusing on the function call. At that point,
>>>there is not enough information for the compiler to generate a correct
>>>call, at least not in the most general case.
>>The compiler can very much generate the correct call, BUT it's a
>>different matter if such a function exist, and this is the job of the
>>run-time loader to detect.

>>
>I was making a narrow technical point: given a generic function
>pointer type, a C function call does not have the information required
>to check the type and generate the correct calling code. Assume fp is
>such a generic pointer. What is the type of function being called
>here:
>>
> fp(12.3);

>
Ohh..no
>
we can't do pointer arithmetic on pointer-to-void either:
>
void foo(void *p)
{
(*(char *)p)++;
}
>
so I don't see why you assume I somehow suggest that calling a
"generic function pointer" to be meaningful.

I wasn't. I was trying to explain what I was saying. It may well
have had nothing to do with what you were saying -- these things
happen on Usenet! That is why I asked for an example of what you
want...

Converting a function pointer to some "generic function pointer",
would throw away information, while converting a "generic function
pointer" to a function pointer, would add information.
>
I don't see why such conversion should be explicit (i.e. require a
cast), other than as providing a comment for humans (that is, if
typedef of the function pointer is used, else not very readable).

Now I see what you are saying. You want a pointer type to (and from)
which any function pointer can be converted without a cast. This
would help a little, I agree.

I though you were suggesting that the forced cast somehow prevented
some type checking that could otherwise be done.

--
Ben.

[Dann Corbit]

Re: Why no generic function pointers?

"Ben Bacarisse" <ben.usenet@bsb .me.ukwrote in message
news:87hcbnt2kz .fsf@bsb.me.uk. ..

"Malcolm McLean" <regniztar@btin ternet.comwrite s:
>

>"copx" <copx@gazeta.pl wrote in message

>>Why doesn't the C standard include generic function pointers?
>>>

>Because you can't build an argument list on the fly.

>
That begs the question of why one can't do *that*. There are macros
to examine an existing var-arg list, and there the could be macros to
build one from scratch. Given such a thing, a function pointer type
like:
>
void *(*var_arg_fp)( void *, ...);
>
would be very flexible (you need a dummy first argument to get the var
arg macros going).
>
I presume the answer is just history. Of course, it may be that there
are real systems for which such argument building macros/functions
would be impossible, but the seems a stretch.

For some compilers, functions with varadic argument lists and other function
types can be treated differently.

For instance, I can tell one compiler that I want to pass arguments as
registers when possible. If the function is varadic, then that convention
will not be used (and it will definitely cause problems if a prototype is
not in scope and the warning is ignored).

So I think it is up to the compiler vendor to decide exactly how generic a
pointer to function type might be.


** Posted from http://www.teranews.com **