Linux C 如何实现面向对象?从一个嵌入式开源项目说起

基于开源项目 c-periphery 的源码解析，深挖 C 语言面向对象的工程实践。

引子：C 不是面向对象语言，但 C 程序员不这么认为

有一个流传已久的段子：

面试官：你了解面向对象编程吗？候选人：了解，封装、继承、多态。面试官：用 C 能实现吗？候选人：……能，但没必要。面试官：Linux 内核就是这么干的。候选人：沉默。

Linux 内核、SQLite、libuv，这些 C 项目里，面向对象的思想无处不在。不是靠语言特性，而是靠设计模式 + 函数指针 + 结构体，硬生生把 OOP 的精髓给实现了。

今天我们就用一个真实的开源嵌入式库 c-periphery 来扒一扒，C 语言是怎么玩出面向对象的。

什么是 c-periphery？

一句话版本：一个让你在 Linux 用户空间优雅访问 GPIO、I2C、SPI、UART、PWM 等外设的 C 库。

Star 数 1k+，MIT 协议，代码量不大但设计极其精炼，是分析 C 面向对象的绝佳标本。

项目地址：https://github.com/vsergeev/c-periphery

第一招：封装——用不透明指针藏住你的底裤

什么叫"不透明指针"？

面向对象的第一要义是封装：把数据和操作它的方法绑在一起，同时把实现细节藏起来，只暴露接口。

在 C++ 里，你用 class 的 private 字段实现这一点。

在 C 里怎么办？用不透明指针（Opaque Pointer）。

来看 c-periphery 的 gpio.h 里这一行：

// gpio.h（公开头文件）typedefstructgpio_handlegpio_t;

就这一行。struct gpio_handle 在公开头文件里只声明，不定义。你作为调用方只拿到一个 gpio_t * 指针，完全不知道里面长什么样。

真正的结构体定义藏在内部头文件 gpio_internal.h 里，外部代码根本看不见，更别提直接访问字段了。

这就是 C 版的 private——编译器强制执行，你想偷看都偷不了。

对比一下：没有封装是什么惨状

假设不用不透明指针，让调用方直接操作结构体：

// 危险！裸奔的结构体structgpio {int fd;int line;char path[64];// ... 其他内部状态};structgpiomy_gpio;my_gpio.fd = 3;          // 调用方可以随意乱改my_gpio.line = -999;     // 改了个非法值，程序崩溃，凌晨两点排查

一旦结构体字段暴露出去，就意味着：

1. 1. 调用方可能写出依赖内部实现的代码
2. 2. 你改一下内部字段，所有调用方都要重新编译
3. 3. 调用方可能写出不合法的值，库根本无法防御

真实案例：某智能家居控制盒项目早期裸用 struct 传递设备状态，后来硬件换代，GPIO 接口从 sysfs 迁移到 cdev，直接动 fd 字段的代码散落在十几个文件里，改了三天，测试又发现五个地方漏改了。后来统一换成不透明指针，内部随便改，调用方代码一行都不动。

第二招：构造与析构——new/free 是 C 版的 constructor/destructor

观察 c-periphery 的 API 风格：

gpio_t *gpio_new(void);      // 构造：分配并初始化对象voidgpio_free(gpio_t *gpio); // 析构：释放对象

每个外设类型都有一对对应的函数：

来看 gpio_new 的源码（gpio.c）：

gpio_t *gpio_new(void) {gpio_t *gpio = calloc(1, sizeof(gpio_t));if (gpio == NULL)returnNULL;#if PERIPHERY_GPIO_CDEV_SUPPORT    gpio->ops = &gpio_cdev_ops;   // 关键：注入虚函数表（下文详解）    gpio->u.cdev.line_fd = -1;    gpio->u.cdev.chip_fd = -1;#else    gpio->ops = &gpio_sysfs_ops;  // 编译时选择另一套实现    gpio->u.sysfs.line_fd = -1;#endifreturn gpio;}

这跟 C++ 的构造函数干的事情完全一样：

• • 分配内存（calloc 还顺带清零，防止野值）
• • 初始化内部状态（line_fd = -1 表示"还没打开"）
• • 绑定虚函数表（这是这段代码最妙的地方，下文展开）

gpio_free 则对应析构，就是个 free(gpio)，简单但必要。

注意这里的设计决策：为什么要分 new 和 open 两步？

gpio_t *gpio = gpio_new();                           // 第一步：构造对象gpio_open(gpio, "/dev/gpiochip0", 10, GPIO_DIR_IN);  // 第二步：打开资源

因为构造和初始化是不同的事情。对象可以存在，但暂时还没有绑定到具体资源。这在需要提前分配对象数组、后续再批量打开的场景下非常有用。

第三招：多态——函数指针 + 虚函数表，C 版 virtual

这是整个 c-periphery 设计中最精彩的部分，值得细细品味。

问题背景：GPIO 有两种后端

Linux 的 GPIO 有两套接口：

• • sysfs 接口（老的，/sys/class/gpio/，已被标记为 deprecated）
• • character device 接口（新的，/dev/gpiochip0，Linux 4.8+ 引入）

两套接口操作方式完全不同，但上层调用代码应该是统一的——你不希望调用方去判断"我该走哪条路"，这是库应该帮你解决的事。

这就是多态要解决的问题。

c-periphery 的解法：ops 虚函数表

先看内部结构（gpio_internal.h，外部不可见）：

// 这就是 C 版的"虚函数表"（vtable）structgpio_ops {int (*read)(gpio_t *gpio, bool *value);int (*write)(gpio_t *gpio, bool value);int (*poll)(gpio_t *gpio, int timeout_ms);int (*close)(gpio_t *gpio);int (*read_event)(gpio_t *gpio, gpio_edge_t *edge, uint64_t *timestamp);int (*get_direction)(gpio_t *gpio, gpio_direction_t *direction);int (*set_direction)(gpio_t *gpio, gpio_direction_t direction);int (*get_edge)(gpio_t *gpio, gpio_edge_t *edge);int (*set_edge)(gpio_t *gpio, gpio_edge_t edge);// ... 其他方法};// "基类"——gpio_handle 内部持有一个 ops 指针structgpio_handle {conststructgpio_ops *ops;// 指向当前实现的虚函数表union {struct {// cdev 实现的私有数据int line_fd;int chip_fd;// ...        } cdev;struct {// sysfs 实现的私有数据int line_fd;        } sysfs;    } u;struct {// 统一的错误状态int c_errno;char errmsg[96];    } error;};

然后，cdev 实现和 sysfs 实现各自填充自己的 ops 表：

// gpio_cdev_v2.c（cdev 实现）conststructgpio_opsgpio_cdev_ops = {    .read       = _gpio_cdev_read,    .write      = _gpio_cdev_write,    .poll       = _gpio_cdev_poll,    .close      = _gpio_cdev_close,    .get_direction = _gpio_cdev_get_direction,    .set_direction = _gpio_cdev_set_direction,// ...};// gpio_sysfs.c（sysfs 实现）conststructgpio_opsgpio_sysfs_ops = {    .read       = _gpio_sysfs_read,    .write      = _gpio_sysfs_write,    .poll       = _gpio_sysfs_poll,    .close      = _gpio_sysfs_close,// ...};

最后，gpio_read 这类公开函数长这样（gpio.c）：

intgpio_read(gpio_t *gpio, bool *value) {return gpio->ops->read(gpio, value);  // 通过函数指针调用，自动多态}intgpio_write(gpio_t *gpio, bool value) {return gpio->ops->write(gpio, value);}

这就是多态！

调用方写：

gpio_read(my_gpio, &value);

底层可能走 cdev 实现，也可能走 sysfs 实现，取决于 gpio_new() 时注入了哪套 ops——调用方完全不感知。

和 C++ 虚函数机制的对照

两者机制几乎完全等价，C++ 只是让编译器替你做了那些繁琐的手工活。