为何在嵌入式PIC32代码中传递void指针而非自定义类型指针？

为何采用void*传递再强制转换的模式？ #

这种写法是C语言里模拟面向对象多态特性的常见手段，核心原因和潜在优势包括：

• 统一函数指针类型：如果代码中存在多个类似custom_list的结构体（比如custom_menu、custom_button这类同层级的自定义对象），它们的函数指针成员可以统一使用void (*func)(void*)类型。这样就能用一套通用的函数接口处理不同类型的对象，实现类似基类虚函数的效果。
• 适配扩展需求：后续新增同类型结构体时，无需修改函数指针的定义，仅需在函数内部补充对应类型的转换与逻辑，减少代码改动范围。
• 嵌入式代码的历史习惯：部分老嵌入式框架会沿用这种模式，要么是代码从更早版本迁移而来，要么是开发者习惯用这种方式模拟类和方法的结构。

这种写法是否属于不良实践？ #

不能直接判定为不良实践，但它存在明确的缺陷：

• 可读性差：如你观察到的，操作转换后的结构体指针却传递原始void*，容易让维护者产生困惑，大幅提升理解成本。
• 类型不安全：强制转换会绕过编译器的类型校验，若误传了错误类型的指针，运行时会触发未定义行为——在嵌入式系统中这可能直接导致崩溃，且排查难度极高。
• 调试效率低：调试时void*无法直接查看结构体成员，必须手动转换类型，增加调试的复杂度。

为何不直接传递custom_list*？ #

如果你的代码仅针对custom_list这一种结构体设计这类函数，直接传递custom_list*显然更合理：

• 保留编译器的类型检查，从源头避免类型错误。
• 代码逻辑更直观，降低维护成本。
• 省去多余的强制转换步骤，减少冗余代码。

但如果代码中存在多个同类型的结构体，且需要一套统一的接口来处理不同对象，void*的写法就有其必要性——这是C语言在无原生面向对象支持的前提下，实现多态的经典方案。

针对你场景的建议 #

从补充信息来看，当前代码同一时间仅使用一个custom_list对象，且list_text指向全局列表，这种场景下完全可以改用直接传递custom_list*的写法。你可以逐步重构代码：修改函数定义为接收custom_list*，同步调整结构体的函数指针成员类型与调用方式，以此提升代码的可读性与安全性。

内容的提问来源于stack exchange，提问作者Trashman