C语言中static inline声明与-finline-functions编译选项适用场景疑问

需要显式在头文件声明static inline的核心场景 #

• 跨编译单元内联需求，且未开启链接时优化（LTO）
  版本B的函数实现放在单独的.c文件中，默认情况下编译器处理其他调用该函数的编译单元时，只能看到头文件中的函数声明，看不到具体实现，就算开启-O2 -finline-functions也无法完成内联，只有额外开启LTO才可能实现跨单元内联。而很多嵌入式、兼容旧工具链、对编译速度敏感的项目不会开启LTO，此时显式写static inline放在头文件，才能保证编译器在所有调用处都能看到函数实现，具备内联的前提。
• 高频调用的极短性能敏感函数
  你示例中的位操作函数本身执行的指令数远低于函数调用的开销（压栈、传参、出栈、返回），如果这类函数每秒被调用数十万次以上，函数调用的开销会被放大。显式加static inline会给编译器更高的内联优先级，避免编译器因为策略判断漏优化导致性能损失。另外在低优化等级（如调试用的-O0）下，自动内联不会开启，若你需要在调试场景下也保持这类核心函数的性能，可配合__attribute__((always_inline))使用，强制编译器内联。
• 开发头文件-only的库/模块
  版本A不需要额外的.c实现文件，用户只需要引入头文件即可直接使用函数，不需要额外链接对应的目标文件，分发和集成都更简单。如果直接把函数实现放在头文件不加static inline，多个编译单元引用该头文件时会报重复定义的链接错误，static inline刚好规避了这个问题，且不会导出全局符号，不会产生命名冲突。
• 减少不必要的符号开销
  版本B的两个函数是全局符号，会增加编译、链接阶段的符号表体积，当这类小函数数量很多时，会拖慢编译链接速度，也有概率和其他模块的同名函数产生冲突。static inline的函数只有在未被内联时才会在当前编译单元生成一个静态的函数副本，不会导出全局符号，完全没有上述问题。

注意事项 #

如果static inline函数内部定义了静态变量，那么每个引用该头文件的编译单元都会生成独立的静态变量副本，和你把函数拆成.c实现的全局静态变量行为不一致，这种场景需要谨慎使用。

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