Steve Litt:
...
> Years ago I gave up trying to logically explain the syntax of function
> pointers, which are so essential for callbacks and pseudo-oop, and just
> memorized the idiom.
>
> Edition 1 of K&R had an actual algorithm by which one could dissect any
> lvalue (thing that can appear on the left of the equal sign), but it
> was so complicated I couldn't understand it. So I memorized the idiom
> for function pointers.
>
> I think C would have been much more successful (and it's already been
> quite successful) if it could have had a better syntax for function
> pointers.
Too late to change that, but I think you are better off if you do a
typedef first, as in:
typedef int (*func_t)(int,int);
int add(int a, int b) {
return a + b;
}
int proc(func_t f, int a, int b) {
return f(a,b);
}
int main(void) {
int ix = 0;
func_t func_arr[10];
func_arr[0] = add;
return proc(func_arr[ix], 1, 2);
}
$ gcc -Wall a.c
$ ./a.out
$ echo $?
3
> I think the reason you see so few callback functions in
> average C code is the syntax,
Just because c gives you the possibility to make code that looks like
tty noise, doesn't mean you have to...
> as well as the unforgivingly strict typing
> of the arguments.
...
The strict typing comes with the language, but you can get around it
with pointers (gives you 0 to x number of arguments, same type unless
the type is void). You can use varargs, and a remote possibility is
to pass down a string and parse it which is quite radable from the
calling side :)
Regards,
/Karl Hammar
-----------------------------------------------------------------------
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
