30. 结构体与代码生成：宏生成结构体、X-Macro技术、代码模板化
说到结构体，很多人觉得不就是定义几个成员变量嘛，有啥好讲的？
嗯，我刚开始也是这么想的。直到有一次，我接手一个通信协议栈的项目，里面定义了上百种报文结构体。每个结构体都要写序列化、反序列化、打印、校验函数……那代码量，简直让人崩溃。
后来我学乖了。用宏生成结构体，用X-Macro技术，把重复劳动交给预处理器。今天我就把这些压箱底的经验掏出来，跟你好好聊聊。
30.1 宏生成结构体：别手写，让机器写
先看一个最简单的场景。你有一组寄存器地址，每个寄存器对应一个结构体。传统写法是这样的：
// 传统写法：手写每个结构体
typedef struct {
uint8_t version;
uint32_t status;
uint8_t reserved[3];
} RegBlockA;
typedef struct {
uint16_t counter;
uint16_t threshold;
uint8_t flags;
} RegBlockB;
如果只有两三个，手写没问题。但如果有几十个呢？
我个人习惯用宏来生成这类结构体。你看这个：
// 宏定义：生成寄存器块结构体
#define DEFINE_REG_BLOCK(name, fields) \
typedef struct { \
fields \
} RegBlock_##name;
// 使用宏
DEFINE_REG_BLOCK(A,
uint8_t version;
uint32_t status;
uint8_t reserved[3];
)
DEFINE_REG_BLOCK(B,
uint16_t counter;
uint16_t threshold;
uint8_t flags;
)
看起来好像没省多少代码？别急，这只是开胃菜。
30.2 X-Macro技术：一张表搞定所有
X-Macro，说白了就是「用宏来展开宏」。它把数据定义和代码生成彻底分离。
你想想看，一个结构体通常需要哪些操作？定义、初始化、打印、序列化、反序列化……每个操作都要写一遍代码。X-Macro让你只写一次数据表，然后自动生成所有代码。
先看一个经典例子：
// 第一步：定义数据表（X-Macro的核心）
#define DEVICE_PARAM_TABLE \
X(version, uint8_t, 1) \
X(status, uint32_t, 0) \
X(temperature, int16_t, 25) \
X(humidity, uint8_t, 50) \
X(checksum, uint16_t, 0)
// 第二步：生成结构体定义
#define X(name, type, default_val) type name;
typedef struct {
DEVICE_PARAM_TABLE
} DeviceParams;
#undef X
// 第三步：生成初始化函数
#define X(name, type, default_val) .name = default_val,
DeviceParams default_params = {
DEVICE_PARAM_TABLE
};
#undef X
// 第四步：生成打印函数
#define X(name, type, default_val) \
printf(#name " = %" PRIu##type "\n", params.name);
void print_params(DeviceParams* params) {
DEVICE_PARAM_TABLE
}
#undef X
看到没？数据表只写了一次，但生成了结构体定义、默认初始化、打印函数三份代码。
30.3 实战：用X-Macro管理寄存器映射
我在做MCU驱动库时，遇到过最头疼的问题就是寄存器映射。每个外设都有几十个寄存器，每个寄存器又有多个位域。手写结构体？手写位操作宏？那简直是噩梦。
后来我用X-Macro重构了整个驱动层。看这个例子：
// 定义UART寄存器表
#define UART_REG_TABLE \
X(DR, uint32_t, 0x000, "数据寄存器") \
X(SR, uint32_t, 0x004, "状态寄存器") \
X(CR1, uint32_t, 0x008, "控制寄存器1") \
X(CR2, uint32_t, 0x00C, "控制寄存器2") \
X(BAUD, uint32_t, 0x010, "波特率寄存器")
// 生成结构体
#define X(name, type, offset, desc) type name;
typedef struct {
UART_REG_TABLE
} UART_Regs;
#undef X
// 生成地址偏移宏
#define X(name, type, offset, desc) \
#define UART_##name##_OFFSET offset
UART_REG_TABLE
#undef X
// 生成调试打印
#define X(name, type, offset, desc) \
printf(" %s (0x%03X): 0x%08lX\n", desc, offset, (unsigned long)regs->name);
void dump_uart_regs(UART_Regs* regs) {
UART_REG_TABLE
}
#undef X
30.4 代码模板化：不止是宏
宏生成结构体虽然强大，但也不是万能的。遇到复杂逻辑，比如条件编译、类型推导、多平台适配，宏就有点力不从心了。
这时候，我推荐用「代码生成脚本」来做模板化。说白了，就是写一个Python脚本，读一个YAML或JSON配置文件，然后生成C代码。
举个例子：
# config.yaml
structs:
- name: SensorData
fields:
- {name: id, type: uint8_t, desc: "传感器ID"}
- {name: value, type: float, desc: "测量值"}
- {name: timestamp, type: uint32_t, desc: "时间戳"}
- name: ControlCmd
fields:
- {name: cmd_id, type: uint8_t, desc: "命令ID"}
- {name: param, type: int16_t, desc: "参数"}
然后Python脚本读取这个配置，生成对应的.h和.c文件。结构体定义、初始化函数、序列化函数、单元测试……全部自动生成。
30.5 知识体系总览
下面这张图，是我对结构体代码生成技术的总结。你可以把它当作一个决策树：
30.6 避坑指南
最后，分享几个我踩过的坑：
- 宏展开后的逗号问题：X-Macro在展开时，如果最后一个成员后面多了逗号，某些编译器会报错。我习惯在数据表最后加一个空成员来规避。
- 调试困难：宏展开后的代码，调试器里看不到原始宏。我的做法是：在开发阶段先用脚本生成展开后的代码，调试通过后再切回宏版本。
- 可读性：别为了炫技把宏写得太复杂。我曾经见过一个同事写的X-Macro，嵌套了5层宏展开，最后谁也看不懂。记住，代码首先是给人读的。
好了，关于结构体代码生成，我就聊这么多。记住一句话：重复的工作交给机器，创造性的工作留给自己。用宏生成结构体、用X-Macro做模板化，本质上都是在对抗重复劳动。你省下来的时间，可以去思考更重要的架构问题。