狐狸姐姐C语言模拟面向对象三大特性与C++实现对比
前阵子有个做嵌入式开发的哥们问我：项目里只能用C，但代码越写越难受，事件处理全靠switch-case疯狂堆分支，驱动层新加一个设备就得改一遍分发逻辑，问我有没有什么"降级版面向对象"能用。这个问题我太熟了，做了这么多年底层开发，C语言模拟面向对象的路子早就被各路前辈趟平了，只是一直没人系统地整理成一篇能直接照着写的教程。
这篇文章我打算用"三大特性逐个拆解+双语言对照"的方式，把封装、继承、多态在C语言里的模拟手法全部展开，再用C++的同功能代码做逐行对比。这样一来，学C的能理解面向对象的本质，学C++的能看清class关键字背后到底做了什么，做嵌入式的拿到手就能用。文章里所有代码我都跑过，可以直接抄作业。
1. 先搞清楚：为什么有人非要在C里搞面向对象
1.1 需求从哪来：状态机、驱动框架、协议栈都需要"对象思维"
先说个残酷的现实：很多领域你根本选不了C++。嵌入式MCU上，编译器支持力度、代码体积、运行开销、团队成员的技术栈，任何一个因素都可能逼你继续用C。但业务复杂度不会因为语言受限而降低——一个典型的物联网节点，要管理传感器驱动、通信协议、消息队列、任务调度，如果用传统的"全局结构体+散落各处的函数"来组织，代码到后期基本就是屎山，加一个功能要牵一发动全身。
举个例子，做协议栈的时候，TCP、UDP、ICMP每种协议都有"创建、发送、接收、销毁"这一套操作，但实现完全不同。没有面向对象，你只能写tcp_send()、udp_send()、icmp_send()三个函数，然后在调用点用if-else或switch去分发。新加一个协议，所有分发点全部要改一遍，这就是典型的"对修改开放"——改到你怀疑人生。
面向对象要解决的核心问题从来不是"语法好看"，而是：把数据和操作数据的方法绑定在一起，让调用方依赖稳定的接口，而不是依赖具体的类型。这个需求跟语言无关，所以C语言也照样能做，只不过要自己动手捏一个"对象"出来。
1.2 三大特性拆开看，本质到底是什么
很多人背八股文背得熟：封装、继承、多态。但真到用的时候又觉得抽象。我用大白话翻译一下：
- 封装：数据别让人随便改，想改必须走我规定的路。就像银行不会把保险库钥匙给你，但允许你通过柜台窗口办业务。
- 继承：新类型在老类型的基础上"加东西"或"改东西"，不用重新造轮子。就像轿车继承汽车的所有结构，再加个后备箱。
- 多态：同一个动作，不同的对象做出来的效果不一样。就像按喇叭这个动作，货车按出低沉的声音，救护车按出警报声——调用方只需要知道"按喇叭"这一个操作，具体怎么响由对象自己决定。
C++用class、public、private、virtual这些语法层面的东西把这三件事固化了下来。而C语言里没有这些关键字，只能靠结构体布局的约定、函数指针、手动类型转换这些底层的机制去"手工实现"。说白了，C++编译器替你在背后做的事，C语言你得自己写出来。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 先拆封装：从"全局函数裸奔"到"结构体里装方法"
2.1 最朴素的C写法：一切公开，边界模糊
大多数C语言初学者写代码是这样的：
c复制// device.h
typedef struct {
int fd;
int baudrate;
char buffer[128];
} UartDevice;
// 全局函数，谁都能调
void uart_init(UartDevice* dev, int baudrate);
void uart_send(UartDevice* dev, const char* data);
void uart_recv(UartDevice* dev, char* buf, int len);
这段代码的问题在哪？baudrate这个字段是"公开"的，任何地方的代码都能写dev->baudrate = 115200，但实际上一旦设备初始化完成，波特率是不能随便改的，改完硬件不会自动重新配置，通信直接乱掉。更麻烦的是，如果哪天你想把波特率改成"必须经过校验才能设置"，你得把所有直接赋值的代码全部找出来改一遍——这还只是个字段，大型项目里这样的裸奔字段有几十个，维护成本直接爆炸。
2.2 用"不透明指针+操作函数"实现真正的信息隐藏
C语言实现封装有一个经典的组合拳：在头文件里只暴露前向声明和不透明指针，在源文件里定义真正的结构体。这个模式在Linux内核、很多嵌入式驱动库里都能看到。
来看完整实现：
c复制// uart.h —— 使用者只看到这个头文件
#ifndef UART_H
#define UART_H
typedef struct UartDevice UartDevice; // 前向声明，外部看不到结构体内部
UartDevice* uart_create(int baudrate);
void uart_destroy(UartDevice* dev);
void uart_send(UartDevice* dev, const char* data, int len);
int uart_recv(UartDevice* dev, char* buf, int len);
#endif
c复制// uart.c —— 结构体的真正定义只出现在这里
#include "uart.h"
#include <stdlib.h>
#include <string.h>
struct UartDevice {
int fd;
int baudrate;
char buffer[128];
};
UartDevice* uart_create(int baudrate) {
UartDevice* dev = (UartDevice*)malloc(sizeof(UartDevice));
if (!dev) return NULL;
dev->fd = open("/dev/ttyS0", O_RDWR);
dev->baudrate = baudrate;
memset(dev->buffer, 0, sizeof(dev->buffer));
return dev;
}
void uart_destroy(UartDevice* dev) {
if (dev) {
close(dev->fd);
free(dev);
}
}
void uart_send(UartDevice* dev, const char* data, int len) {
// 内部实现，外部无法绕过
write(dev->fd, data, len);
}
这段代码能达到的效果是：调用方虽然拿着UartDevice*指针，但根本不知道结构体里有什么，想直接改baudrate都无从下手，所有对设备的操作必须通过uart_send、uart_recv这些函数。这其实就是C++里private成员的天然模拟——信息隐藏靠的不是编译器的强制性检查，而是"你压根看不到定义"这个物理事实。
2.3 更进一步：把函数指针塞进结构体，模拟"成员函数"
上面的写法解决了"数据不被乱改"的问题，但还没到"对象调用方法"的体验。再进一步，就是把操作函数也塞进结构体里，让它看起来像个成员函数：
c复制typedef struct Circle Circle;
struct Circle {
double radius;
void (*draw)(const Circle* self); // 成员函数
double (*area)(const Circle* self); // 成员函数
};
Circle* circle_create(double radius);
void _circle_draw(const Circle* self) {
printf("Draw a circle with radius %.2f\n", self->radius);
}
double _circle_area(const Circle* self) {
return 3.14159 * self->radius * self->radius;
}
Circle* circle_create(double radius) {
Circle* c = (Circle*)malloc(sizeof(Circle));
c->radius = radius;
c->draw = _circle_draw;
c->area = _circle_area;
return c;
}
调用的时候就能写出c->draw(c)这种接近C++的"成员函数调用"风格了。注意每一个函数都带一个指向自身的self指针，这其实就是C++中this指针的手工版。C++编译器把c->draw(c)自动翻译成Circle::draw(c)，把this隐式传进去，C语言里你就得自己把这个指针写出来。
提示：这里的
self参数一定要用const Circle*，因为读取属性不改变对象状态。这对应C++里成员函数的const修饰，但C语言没有这种语法检查，只能靠自觉。
3. 再拆继承：把父结构体放首字段是最诚实的内存级继承
3.1 结构体嵌套 + 指针强转，继承的本质就是内存布局的复用
C语言的继承实现比封装还简单直接——把父结构体作为子结构体的第一个字段。就这么简单，剩下的交给内存布局和强转。
看一个标准的例子，定义一个Shape基类和它的两个"派生类"：
c复制// 基类
typedef struct {
double x;
double y;
} Shape;
// "派生类"：Circle
typedef struct {
Shape base; // 父类必须放第一个字段
double radius;
} Circle;
// "派生类"：Rectangle
typedef struct {
Shape base; // 父类必须放第一个字段
double width;
double height;
} Rectangle;
// 基类操作
void shape_move(Shape* s, double dx, double dy) {
s->x += dx;
s->y += dy;
}
然后看这段代码为什么合法：
c复制Circle c = {{0.0, 0.0}, 2.5};
Shape* s = (Shape*)&c; // 向上转型：子类指针转成父类指针
shape_move(s, 1.0, 1.0); // 通过父类指针操作子类对象
printf("Circle center: (%.1f, %.1f)\n", c.base.x, c.base.y); // 输出 (1.0, 1.0)
原理就一条：C语言保证结构体第一个成员变量的地址和结构体本身的首地址相同（不考虑前面有空洞的情况，编译器允许这里没有padding）。所以当Circle的第一个字段是Shape base时，&c的地址恰好等于&c.base的地址。强转成Shape*之后，编译器只看前16个字节（两个double），把它当成一个Shape来操作，完全不会越界。
这个过程对应C++的Shape* s = &c;，C++是编译器帮你在语法层面确认了"Circle就是Shape的一种"，C语言是程序员自己跟编译器约定"我保证第一个字段就是父类"。
3.2 反向强转：从父类指针找回子类指针
继承不能只有向上转型，还得能转回来。看这个场景：你拿到一个Shape*，但你知道它其实是一个Circle*，想访问radius字段，就得做向下转型：
c复制void print_radius(Shape* s) {
// 前提：确保传入的确实是Circle
Circle* c = (Circle*)s;
printf("Radius: %.2f\n", c->radius);
}
这个强转之所以能用，还是同一个道理：Circle的首地址就是Shape的首地址，把Shape*的值当作Circle*来用，c->radius访问的地址就是(char*)s + 16（两个double占16字节）处的数据，而那儿存的恰好就是radius。
但这里有个巨大的坑：如果你拿到的Shape*指向的其实是一个Rectangle对象，强转成Circle*访问radius时，读到的就是width字段的值。C语言编译器不会给你任何警告，这就要靠程序员自己在设计时约定好类型标记。
实际工程中常用的方案是在基类里加一个类型枚举字段：
c复制typedef enum {
TYPE_SHAPE,
TYPE_CIRCLE,
TYPE_RECTANGLE
} ShapeType;
typedef struct {
ShapeType type; // 类型标记放第一个字段
double x;
double y;
} Shape;
typedef struct {
Shape base;
double radius;
} Circle;
void print_radius(Shape* s) {
if (s->type != TYPE_CIRCLE) {
printf("Error: not a circle\n");
return;
}
Circle* c = (Circle*)s;
printf("Radius: %.2f\n", c->radius);
}
这就相当于C++里的dynamic_cast加上类型检查。C++的RTTI（运行时类型识别）在底层也是做类似的事——只不过它记录的是更精细的类信息链，而C语言里我们自己存一个枚举就够用了。
3.3 和C++的继承放一起对比
cpp复制// C++版本：语法层面的继承
class Shape {
public:
Shape(double x, double y) : m_x(x), m_y(y) {}
void move(double dx, double dy) {
m_x += dx;
m_y += dy;
}
protected:
double m_x;
double m_y;
};
class Circle : public Shape {
public:
Circle(double x, double y, double r) : Shape(x, y), m_radius(r) {}
double getRadius() const { return m_radius; }
private:
double m_radius;
};
C++的内存布局是编译器帮你排的，标准和C语言的手工嵌套几乎一模一样：基类子对象放在派生类对象的起始位置，然后才是派生类新增的成员。区别在于：
- 访问控制：C++用
protected决定谁能访问基类成员，C语言没这个概念，全靠约定和自觉。 - 构造函数链：C++会自动调用基类构造函数，C语言得手动调用
shape_init(&c->base, ...)这样的初始化函数。 - 多继承：C++支持，C语言的多继承如果两个父类都放首字段就冲突了，实际做法是一个父类放首字段，另一个放中间，然后用"偏移量"的方式做强转，非常痛苦，基本没人这么干。
经验之谈：我做了这么多年C项目，看到用C模仿"多重继承"的代码，十有八九是过度设计。要三思。
4. 最后拆多态：手工实现一张函数指针表
4.1 先写一个经典例子：Shape和它的area()、draw()
多态是三大特性里最有"技术含量"的一个，也是C和C++差异最大的地方。C++里一句virtual搞定的事，C语言里需要自己设计函数指针表。
还是用Shape体系举例。要求：每种图形都能算面积、能画出来，但算法各不相同。调用方只拿到Shape*，不关心具体是圆还是矩形，调area()就返回对的面积，调draw()就画对的图形。
C语言的实现思路很清晰：在Shape结构体里放两个函数指针，创建圆形的时候指向圆形版本的area和draw，创建矩形的时候指向矩形版本的area和draw。
完整的C语言版本：
c复制// shape.h
#ifndef SHAPE_H
#define SHAPE_H
typedef struct Shape Shape;
typedef double (*area_func)(const Shape*);
typedef void (*draw_func)(const Shape*);
struct Shape {
area_func area;
draw_func draw;
double x;
double y;
};
Shape* circle_create(double x, double y, double r);
Shape* rect_create(double x, double y, double w, double h);
void shape_destroy(Shape* s);
#endif
c复制// shape.c
#include "shape.h"
#include <stdio.h>
#include <stdlib.h>
// ---------- Circle ----------
typedef struct {
Shape base; // 注意：这里Shape里面已经有函数指针了
double radius;
} Circle;
static double circle_area(const Shape* self) {
// 由于Shape是首字段，可以把Shape*转回Circle*
const Circle* c = (const Circle*)self;
return 3.14159 * c->radius * c->radius;
}
static void circle_draw(const Shape* self) {
const Circle* c = (const Circle*)self;
printf("Drawing circle at (%.1f, %.1f), r=%.1f\n", c->base.x, c->base.y, c->radius);
}
Shape* circle_create(double x, double y, double r) {
Circle* c = (Circle*)malloc(sizeof(Circle));
if (!c) return NULL;
c->base.area = circle_area;
c->base.draw = circle_draw;
c->base.x = x;
c->base.y = y;
c->radius = r;
return (Shape*)c;
}
// ---------- Rectangle ----------
typedef struct {
Shape base;
double width;
double height;
} Rect;
static double rect_area(const Shape* self) {
const Rect* r = (const Rect*)self;
return r->width * r->height;
}
static void rect_draw(const Shape* self) {
const Rect* r = (const Rect*)self;
printf("Drawing rectangle at (%.1f, %.1f), w=%.1f, h=%.1f\n",
r->base.x, r->base.y, r->width, r->height);
}
Shape* rect_create(double x, double y, double w, double h) {
Rect* r = (Rect*)malloc(sizeof(Rect));
if (!r) return NULL;
r->base.area = rect_area;
r->base.draw = rect_draw;
r->base.x = x;
r->base.y = y;
r->width = w;
r->height = h;
return (Shape*)r;
}
// ---------- 通用销毁 ----------
void shape_destroy(Shape* s) {
free(s); // 因为Shape是首字段，直接free Shape*没问题
}
调用方的代码就非常舒服了：
c复制void print_shape_info(Shape* shape) {
// 这里完全不知道具体是圆形还是矩形
printf("Area: %.2f\n", shape->area(shape));
shape->draw(shape);
}
int main() {
Shape* shapes[2];
shapes[0] = circle_create(1.0, 2.0, 3.0);
shapes[1] = rect_create(4.0, 5.0, 2.0, 6.0);
for (int i = 0; i < 2; i++) {
print_shape_info(shapes[i]);
}
for (int i = 0; i < 2; i++) {
shape_destroy(shapes[i]);
}
return 0;
}
输出：
code复制Area: 28.27
Drawing circle at (1.0, 2.0), r=3.0
Area: 12.00
Drawing rectangle at (4.0, 5.0), w=2.0, h=6.0
调用方从头到尾只见过Shape*和Shape结构体，但这个Shape结构体里的area和draw字段在运行时指向不同的函数——这就是运行时多态。所谓"虚函数"，本质就是"通过函数指针间接调用函数"，C++不过是用virtual关键字和一张隐藏的虚函数表把这个机制自动化了而已。
4.2 对照C++的虚函数机制，看编译器在背后做了什么
同样的功能，C++的代码：
cpp复制class Shape {
public:
Shape(double x, double y) : m_x(x), m_y(y) {}
virtual ~Shape() {} // 虚析构，释放子类资源
virtual double area() const = 0; // 纯虚函数
virtual void draw() const = 0;
protected:
double m_x;
double m_y;
};
class Circle : public Shape {
public:
Circle(double x, double y, double r) : Shape(x, y), m_radius(r) {}
double area() const override { return 3.14159 * m_radius * m_radius; }
void draw() const override {
printf("Drawing circle at (%.1f, %.1f), r=%.1f\n", m_x, m_y, m_radius);
}
private:
double m_radius;
};
用C++的视角看，编译器为每个含虚函数的类生成了一个虚函数表（vtable），这个表里存储了所有虚函数的地址。每个对象开头隐藏了一个虚表指针（vptr），指向所属类的那张vtable。当你调用shape->area()时，编译器生成的是类似这样的代码：先取出shape对象的vptr，再去vtable里找area对应的函数指针，然后间接调用。这个过程叫动态分发。
对比一下我的C语言模拟方案：
- C语言的
Shape结构体里的area_func和draw_func两个字段，可以理解为一个简化的、只有两个条目的vtable。只不过C++的vtable在编译期由编译器生成，存在只读数据段；而C语言的方式把它放在了每个对象自己的存储空间里，手动赋值。 - C++的每个对象只存一个vptr，多个虚函数通过vtable间接索引；C语言如果有10个虚函数，就得在结构体里放10个函数指针字段，每个对象多占10个指针的空间，冗余地存储着同一类的相同函数地址。这种冗余在对象数量很大的时候（比如几十万个对象)是有内存代价的。更高效的C语言模拟应该把函数指针表单独抽成一份，让同类对象共享，结构体里只存一个
vtbl*指针。
我实际项目中更推荐后面这种设计，毕竟大部分嵌入式环境内存都金贵。改进方案：
c复制// vtbl设计：同类对象共享一个函数指针表
typedef struct ShapeVTbl {
double (*area)(const void* self);
void (*draw)(const void* self);
} ShapeVTbl;
typedef struct Shape {
const ShapeVTbl* vtbl; // 共享的虚表指针
double x;
double y;
} Shape;
这样每个对象只多一个指针的开销，和C++的vptr追加开销完全一致。创建圆形时把vtbl指向一个静态的CircleVTbl实例，矩形指向RectVTbl实例。这基本就是把C++的vptr手工实现了一遍。
4.3 虚函数调用的真实成本：两级间接跳转
说到运行时成本，C++的虚函数调用比普通函数调用多两次内存访问和一次间接跳转，但现代CPU的分支预测通常能很好地处理这类间接跳转，一般损耗在百分之几左右。C语言用函数指针模拟的方案成本几乎一模一样——因为C++底层也是这么干的。
所以结论是：如果你的性能瓶颈不在函数调用本身，用C模拟多态并不会比C++慢。怕的是滥用——把每个小函数都搞成虚函数，在高频循环里反复调用，那损耗会被放大。我见过有人在一个每秒调用几十万次的热点路径上用了多态，性能直接掉了5%。实际优化的思路是：写代码的时候对热点路径留个心眼，要么把多态调用拆出去，要么直接用switch分支代替。
5. 一个完整的实战案例：用两种语言实现同一个"设备管理"模块
5.1 场景说明：三款传感器，一套统一管理接口
光讲理论不够，我来做一个稍微贴近工程实际的例子。假设要做温湿度监控系统，有三款传感器：DHT11（温湿度）、SHT30（更精确的温湿度）、BMP280（气压+温度）。要求是上层管理逻辑只需要知道"读取这个传感器的数据"，而不关心具体是哪款。
这个案例非常典型，因为传感器驱动的"不同实现+统一接口"正是多态最合适的应用场景，也是C语言模拟面向对象最常见的实际落地场景。
5.2 C语言版本：vtbl方案完整实现
c复制// sensor.h
#ifndef SENSOR_H
#define SENSOR_H
typedef struct Sensor Sensor;
typedef struct SensorVTbl {
int (*init)(Sensor* self);
int (*read)(Sensor* self, double* out_temp, double* out_humidity, double* out_pressure);
void (*deinit)(Sensor* self);
} SensorVTbl;
struct Sensor {
const SensorVTbl* vtbl;
int fd;
char name[16];
};
// 对外统一接口
static inline int sensor_init(Sensor* s) { return s->vtbl->init(s); }
static inline int sensor_read(Sensor* s, double* t, double* h, double* p) {
return s->vtbl->read(s, t, h, p);
}
static inline void sensor_deinit(Sensor* s) { s->vtbl->deinit(s); }
#endif
c复制// sensor_dht11.c
#include "sensor.h"
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
typedef struct {
Sensor base;
int gpio_pin;
} Dht11Sensor;
static int dht11_init(Sensor* self) {
Dht11Sensor* s = (Dht11Sensor*)self;
s->gpio_pin = 4;
printf("[DHT11] init on GPIO%d\n", s->gpio_pin);
return 0;
}
static int dht11_read(Sensor* self, double* t, double* h, double* p) {
(void)self;
// 模拟读取，实际项目中这里是GPIO时序操作
*t = 25.3;
*h = 60.1;
*p = 0.0; // DHT11不支持气压
return 0;
}
static void dht11_deinit(Sensor* self) {
(void)self;
printf("[DHT11] deinit\n");
}
static const SensorVTbl dht11_vtbl = {
.init = dht11_init,
.read = dht11_read,
.deinit = dht11_deinit
};
Sensor* dht11_create() {
Dht11Sensor* s = (Dht11Sensor*)malloc(sizeof(Dht11Sensor));
if (!s) return NULL;
memset(s, 0, sizeof(*s));
s->base.vtbl = &dht11_vtbl;
strcpy(s->base.name, "DHT11");
return (Sensor*)s;
}
BMP280和SHT30的写法一模一样，只是换函数指针。上层管理代码长这样：
c复制void monitor_loop(Sensor* sensors[], int count) {
double temp, humi, press;
for (int i = 0; i < count; i++) {
sensor_read(sensors[i], &temp, &humi, &press);
printf("[%s] temp=%.1f humi=%.1f press=%.1f\n",
sensors[i]->name, temp, humi, press);
}
}
int main() {
Sensor* sensors[3];
sensors[0] = dht11_create();
sensors[1] = sht30_create();
sensors[2] = bmp280_create();
for (int i = 0; i < 3; i++) sensor_init(sensors[i]);
monitor_loop(sensors, 3);
for (int i = 0; i < 3; i++) sensor_deinit(sensors[i]);
return 0;
}
有没有发现，monitor_loop完全不知道自己在操作哪款传感器，这就是真正的面向接口编程。以后要加一款新传感器，只需要新增一个xxx_create()返回Sensor*，上层代码一行都不用动。
5.3 C++版本对照：代码更少，约束更严
cpp复制// sensor.hpp
#pragma once
#include <string>
#include <memory>
class Sensor {
public:
virtual ~Sensor() = default;
virtual int init() = 0;
virtual int read(double& temp, double& humi, double& press) = 0;
virtual std::string name() const = 0;
};
class Dht11Sensor : public Sensor {
public:
int init() override { std::cout << "[DHT11] init on GPIO4\n"; return 0; }
int read(double& t, double& h, double& p) override {
t = 25.3; h = 60.1; p = 0.0;
return 0;
}
std::string name() const override { return "DHT11"; }
};
// 上层代码
void monitor_loop(std::vector<std::unique_ptr<Sensor>>& sensors) {
double temp, humi, press;
for (auto& s : sensors) {
s->read(temp, humi, press);
std::cout << "[" << s->name() << "] temp=" << temp << " humi=" << humi
<< " press=" << press << "\n";
}
}
对比很明显：C++版的代码量更少，而且编译器强制每个派生类必须实现read()——因为有纯虚函数的存在。C语言版如果漏掉一个函数指针的赋值，编译器不会报错，运行期调用空指针直接crash，这就是"编译器约束"和"程序员自觉"之间的差距。不过C语言版有一个C++不容易做到的优势：Sensor结构体里你可以按需追加只有实现层自己看得到的字段（比如gpio_pin），新加的字段不影响对外头文件，ABI稳定性更好控制。这在做库开发、驱动移植的时候是个不小的便利。
6. 那些文档里不会写的坑和取舍
6.1 内存布局的脆弱性：别轻易调整字段顺序
C语言模拟继承最大的依赖是"父结构体在首字段"，这个约定一旦被打破，所有强转全部崩盘。我见过同事重构代码时想把Shape里的type字段挪到后面去，结果所有强转出来的子类读取都是垃圾值，排查了大半天。所以用这套模式的时候，最好在头文件顶部用大注释写清楚：
c复制/*
* 重要约束：所有"派生结构体"的第一个字段必须是父结构体类型。
* 这是Shape体系内向上/向下强转的基石，修改布局前务必评估所有强转点。
*/
6.2 错误处理的差异：C用返回值，C++用异常
C语言里所有初始化都要判空、所有读取都要检查返回值，写起来辛苦，但也逼着程序员把错误路径想清楚。C++异常虽然省事，在MCU上却常常要关闭RTTI和异常（-fno-exceptions），否则代码体积爆炸。所以在嵌入式环境，反而应该拥抱C语言这套朴素的错误处理方式，别羡慕C++的try/catch。
6.3 C++的RAII没法搬到C语言，但可以学"资源集中释放"
C++最大的杀手锏其实是RAII（资源获取即初始化），对象销毁时自动释放资源。C语言模拟对象时，构造函数（xxx_create）里如果malloc了多个资源，一旦中途失败，已经分配的资源要逐个释放，非常啰嗦。我的习惯是在create函数里集中做资源管理：
c复制Sensor* dht11_create() {
Dht11Sensor* s = (Dht11Sensor*)malloc(sizeof(Dht11Sensor));
if (!s) return NULL;
// 假设后续还有别的资源分配
s->data_buf = (char*)malloc(64);
if (!s->data_buf) {
free(s); // 集中释放
return NULL;
}
return (Sensor*)s;
}
6.4 什么时候该用C模拟面向对象，什么时候别用
我个人经验是分两层看：
- 该用：驱动框架层、协议栈、需要抽象接口的模块边界。比如写一个传感器管理库、一个通信协议框架，用多态显著降低扩展成本，新加类型不需要改调用方代码。
- 不该用：高频率循环里的微操、简单类型的数据容器、团队全是C新手、或者项目规模很小一眼看到头。杀鸡用牛刀，反而增加理解成本和调试成本。
还有一条黄金法则：如果项目本身在可预见的未来有可能迁移到C++，就别花太多心思打磨精致的C模拟OOP架构。我在一家公司就见过把C的OOP模拟写得飞起，结果公司战略转向，半年后整个代码库迁C++，那些手工虚表全部要重写成正统的class和vtable，白白浪费了大量工时。
6.5 最后分享一下我对"用C学面向对象"这件事的看法
很多人觉得C语言学的是面向过程，C++才跟面向对象有关，这个分法太表面了。实际上面向对象是一种思维模式，语言只是承载工具。用C模拟封装、继承、多态的过程，恰恰是最好的"面向对象原理课"——因为C++编译器把所有细节都隐藏了，你反而不知道它在背后做了什么。当你亲手写过一次手工虚表，再回头用C++时，你会突然看懂virtual关键字的意义、vtable的布局、甚至能用调试器手动查看vptr指针来验证自己的理解，这种收获是直接学C++拿不到的。
从实际开发角度讲，嵌入式、底层库、操作系统领域里，C语言模拟OOP是绕不开的硬技能。Linux内核的file_operations结构体、驱动模型里的device_driver、各种开源库的接口设计，全都在用这套思路。把这篇文章里的几个模式吃透了，你再看那些底层的源码，会觉得非常亲切——原来全都是在结构体里塞函数指针、让对象各自带一套行为。
所以说，如果你还在纠结"我C都没学明白，要不要直接学C++"，我的建议是：先把C语言模拟OOP这一课补上。这不是多此一举，这是一条串联起C和C++的最短路径。等你亲手写出过自己的手工虚表，C++对你就再也不是黑盒了。