TinyGSM库CRTP实现方式及相关设计选择技术疑问

问题1：为什么不使用函数重写实现？ #

TinyGSM是面向嵌入式微控制器（MCU）的库，运行环境普遍资源极其受限（很多目标设备RAM仅几十KB、主频仅几十MHz），而基于虚函数的运行时重写有两个核心问题不符合需求：

• 虚函数需要额外的虚函数表内存开销，每个实例携带的虚表指针、全局存储的虚表内容都会占用宝贵的RAM/Flash资源，多重继承场景下还会进一步放大开销。
• 虚函数调用需要运行时查虚表跳转，有额外的执行开销，且无法被编译器优化（比如内联），对于低性能MCU的实时性、执行效率有影响。

而CRTP的实现完全在编译期完成绑定，没有任何额外运行时开销，还能在编译阶段就检查子类是否实现了对应*Impl接口，不会出现运行时才发现方法未实现的问题。

问题2：这种实现方式的设计思路是什么？ #

这种设计的核心是模块化的零成本抽象：

1. 功能解耦：把Modem的不同能力（温度查询、GPS、SMS、通话等）拆成独立的模板类（也叫Mixin组件），不同型号的Modem可以按需继承对应能力的组件，不需要的功能完全不会编译进固件，进一步压缩体积。
2. 代码复用：所有对外统一的接口逻辑都在父类模板中实现，比如所有支持温度查询的Modem对外都暴露getTemperature()接口，不需要每个Modem子类重复写相同的接口封装代码，子类只需要实现和硬件强相关的getTemperatureImpl()逻辑即可，大幅减少重复代码。
3. 接口统一：所有Modem的同能力接口完全一致，上层应用不用修改代码就能无缝切换不同型号的Modem，适配成本极低。

问题3：这是C++中的常用模式吗？ #

这是C非常经典的通用设计模式，名为奇异递归模板模式（CRTP, Curiously Recurring Template Pattern），属于C开发者的常用基础模式：

• 应用场景非常广泛，除了这种静态多态场景外，还用于实现对象计数器、Mixin扩展、fluent接口，甚至C++标准库中的std::enable_shared_from_this等特性也基于CRTP实现。
• 尤其是在高性能服务端、资源受限嵌入式等需要零成本抽象的场景下，CRTP的使用频率极高。

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