C风格的面向对象，以及scf编译器框架对它的支持

C风格的面向对象设计，是从linux内核代码流行开的一种设计模式。

C++并不适合编写系统内核代码，但内核里的很多模块又非常的OOP[呲牙]所以Linux之父就想出了这么一套C风格的OOP，然后被大量的程序员有样学样[呲牙]

C风格的面向对象，是使用结构体加函数指针来模拟C++的多态的。

它们的区别只是，C++的虚函数表是编译器自动生成的，而C语言的“虚函数表”则需要创建对象时由程序员手动初始化。

我觉得C语言的函数指针声明比较麻烦，所以我在scf编译器框架里让函数既可以当作函数，也可以当作类型。

然后，就可以用函数名直接声明它的指针变量，来作为函数指针。

因为当函数指针的参数里也有函数指针时，C语言代码会变得很复杂，例如：

类似这样的多级函数指针的嵌套，会让代码的可读性变得很差。

在C语言里遇到这种情况，一般也是用typedef去定义一个函数指针类型，然后再去声明函数指针变量：

typedef int (*cmp)(...);

cmp c0;

所以我在scf框架里就直接让函数名也可以当类型用了：先声明1个函数，然后用它的函数名加上星号去定义函数指针变量。例如：

int file_close_pt(int fd);

file_close_pt* close; //这就是函数指针

在scf框架里，我直接去掉了typedef关键字。反正它也只是C语言的版本演化而导致的一个补丁关键字[捂脸]

全局结构体的初始化如下：

file_ops test_file_ops = {file_open, file_close}; // “虚函数表”

file f = {NULL, &test_file_ops}; // "类"的对象

如果是动态申请的对象结构体，需要手动设置它的“虚函数表”：

file* f = malloc(sizeof(file));

f->ops = &test_file_ops;

然后这么调用它：f->ops->open()，与C++的f->open()也差不多。

C++的虚函数的查找是由编译器自动实现的，C语言则只能明确的写出来：调用的是ops函数指针结构体里的open()函数。

C++的虚函数表，实际上也是函数指针组成的结构体，只不过实现细节被编译器隐藏了。

我在scf框架里没有区分这2种语法：结构体取成员和结构体指针取成员，前者在C语言里用点号运算符(.)，后者用指针运算符(->)，我全部使用了->运算符。

在更底层的汇编代码里，读取结构体的成员都是通过指针进行的：都是先把结构体的内存地址加载到某个寄存器，然后以这个寄存器为基础，读取偏移量是什么位置的多少个字节。

如果file结构体的指针在rdx寄存器，读取它的ops成员到rax，那么就是：mov rax, 8(rdx)，其中8是以字节计算的偏移量。

读取的长度也是8字节，这是由rax寄存器的位数指定的。

如果直接读取file结构体的ops成员，即C语言的f.ops，那么首先要把f的地址加载它rdx：

lea rdx, f(rip) // 这里的f是个重定位符号，需要连接器后来修改

mov rax, 8(rdx)

因为这两个语法过于类似，所以我使用了同一个运算符，而没有像C语言那样使用2个。

结构体变量与结构体指针的区别在于，结构体变量需要分配内存。

全局的结构体变量，内存需要分配在程序的数据段.data里，然后在程序启动时被操作系统映射到内存里（通过Linux的mmap系统调用）。

局部的结构体变量，内存需要分配在函数的栈上。

而结构体指针，只是个8字节的普通变量。

mAIn函数对f->ops->open的调用

汇编代码对全局变量的加载，都是通过rip寄存器加一个偏移量实现的。

汇编代码对函数指针的调用都是call *register，其中register是存放着函数指针的寄存器。

.data段的重定位符号

函数也是全局的，函数的地址也是个全局常量，所以test_file_ops结构体（“虚函数表”）的内容也是需要连接器填写的，编译器只能给出一个重定位符号。

全局变量的符号表

本文代码的运行结果，当然是打印一行"file_open"，main()函数的返回值是0。

在Linux上，查看main()函数的返回值，使用命令：echo $?

运行结果