源地址：https://argcv.com/articles/2669.c
callback，函数的回调，从ANSI C开始，一直被广为使用。无论是windows API的所谓消息机制,动态链接库的调用，还是sqlite的命令，gcc下的pthread，qsort。callback都在其中起着难以替代的作用。
那么,callback为何如此受到亲睐呢？因为它可以以一个函数为参数，放到参数列表交给API，让API调用。比如有个文件夹下有一千万个文件，我们希望对每个文件进行一些处理，比如查看文件长度是否超过512字节。而遍历这个文件夹的程序是个API。如果不使用callback,API可能有两种办法，一种是申请一个超巨大的空间,然后把找到的所有文件名都放进去，然后返回这个空间(类似的还有把这组文件名写到文件中，一个意思)，这样速度的确很快，而且简单方便，但问题是，一千万个文件，占用的空间是如此的庞大，空间复杂度为O(n)，而我们只是要对每个文件进行一点小小的处理而已，实在是杀鸡焉用宰牛刀。另一个方法是搞个迭代器，每次只返回一个文件名，下次调用再返回下个。为了线程安全，每次传参都得来个指针之类的记录自己的进度。如果做的细心，也可以做的很快，也不占用空间。但问题是，只是个简单的遍历文件夹的API，这么折腾好累哦。而如果使用callback，事情就简单很多了。主程序调用API，把处理文件的函数用参数的方法传递给API，API每找到一个文件名，就调用这个函数，当场处理不用存储任何文件名。这样空间复杂度是O(1),而且方便有效，何乐而不为呢？
callback具体怎么实现的呢？我在本文中做一个小小的demo。
Demo的实现的功能是这样的:
bar.c调用foo.c的一个函数，请求给一个magic number。但foo.c的函数并不是直接返回，而是调用bar.c传递过来的函数use_magic_num，把magic number 作为参数使用进去。
首先，定义最后要被调用的函数use_magic_num如下:
|
1
2
3
4
5
6
|
void use_magic_num(int magic_num);
void use_magic_num(int magic_num)
{ printf("bar.c : magic number is %d \n", magic_num);
} |
也就是传进去一个参数，然后函数会打印出这个magic number。它被放置在bar.c下
然后foo.h中定义API get_magic_num的原型
|
1
|
void get_magic_num(void (*callback)(int magic));
|
它的参数列表和普通的有点区别，传入的是一个函数指针，这个函数必须是原型为有一个int类型为参数，返回为void。其他的就和普通的函数一样了。
对get_magic_num进行实现。
|
1
2
3
4
5
6
7
|
typedef void (*foo_run_magic)(int);
void get_magic_num(foo_run_magic foo)
{ int magic = 9;
foo(magic);
} |
我么可以看到，在这儿，我做了点小花招，我typedef了这个函数指针，这样我们可以直接使用foo_run_magic来代替麻烦的各种括号的函数指针了。
然后调用 foo,其实就是调用传入的参数。在本工程中，也就是前面写的use_magic_num了。
虽然foo.c完全看不见use_magic_num,但完全不妨碍函数的使用。
最后定义bar.c的主程序
|
1
2
3
4
5
|
int main(int argc,char *argv[])
{ get_magic_num(use_magic_num);
return 0;
} |
也就是调用foo并传入use_magic_num的函数了。
编译和执行结果大致是如下的样子:
|
1
2
3
4
5
6
7
|
[yu@argcv callback]$ makegcc -c -Wall -std=c99 bar.c -o bar.ogcc -c -Wall -std=c99 foo.c -o foo.ogcc -Wall -std=c99 -o bar bar.o foo.o[yu@argcv callback]$ ./bar bar.c : magic number is 9 [yu@argcv callback]$ |
完整的工程请参考此处