宏实现编译时计算：把计算塞给编译器

说实话，我第一次接触编译时计算这个概念，是在一个嵌入式项目里。当时产品需要一张256字节的查找表，用于快速查正弦值。我同事直接写了个数组，手动算了半天，还漏了几个点。我心想——这种事，交给编译器干不香吗？

后来我深入研究才发现，C语言的宏和常量表达式，其实能帮我们做很多「编译期苦力活」。说白了，就是让编译器在编译阶段把结果算好，运行时直接拿现成的。这样既省了CPU时间，又不用手动算数。

编译时斐波那契数列

斐波那契数列，大家都不陌生。但用宏在编译时算出来？嗯，这里有个技巧——模板元编程的思路，在C里用宏递归实现。

先看一个简单的版本：

#define FIB_0 0
#define FIB_1 1
#define FIB_2 1
#define FIB_3 2
#define FIB_4 3
#define FIB_5 5
// ... 手动展开到N

这显然不现实。我们需要一个递归宏：

#define FIB(n) \
    ((n) == 0 ? 0 : \
     (n) == 1 ? 1 : \
     FIB((n)-1) + FIB((n)-2))

等等，这样写能编译通过吗？我试过，在大多数编译器里，宏展开时不会递归求值，因为宏展开是文本替换，不是函数调用。所以上面这个写法，实际上会无限展开，导致编译错误。

那怎么办？我个人的习惯是——用「元编程」的套路，手动展开到一定深度：

#define FIB_0 0
#define FIB_1 1
#define FIB_2 (FIB_1 + FIB_0)
#define FIB_3 (FIB_2 + FIB_1)
#define FIB_4 (FIB_3 + FIB_2)
#define FIB_5 (FIB_4 + FIB_3)
#define FIB_6 (FIB_5 + FIB_4)
#define FIB_7 (FIB_6 + FIB_5)
#define FIB_8 (FIB_7 + FIB_6)
#define FIB_9 (FIB_8 + FIB_7)
#define FIB_10 (FIB_9 + FIB_8)
// ... 继续展开到需要的深度

这样，当你写 int x = FIB_10; 时，编译器会展开成 int x = ( ( ( ( ( ( ( ( (1+0) +1) + (1+0) ) + ( (1+0) +1) ) + ... ) ) ) ) ) )，然后常量折叠优化，最终直接生成 int x = 55;。

我在项目中用过这个技巧，生成一个编译时斐波那契查找表，用于某种加密算法的索引。运行时完全零开销。

编译时查找表生成

查找表在嵌入式里太常见了。比如一个8位CRC校验表，256个字节。手动写？累死人。运行时生成？浪费启动时间。最好的办法——编译时生成。

我们可以用宏展开来构造数组：

#define CRC8_TABLE_ENTRY(i) \
    (uint8_t)( ( (i) & 0x80 ) ? ( ( (i) << 1 ) ^ 0x07 ) : ( (i) << 1 ) )

#define CRC8_TABLE_0  CRC8_TABLE_ENTRY(0),  CRC8_TABLE_ENTRY(1),  CRC8_TABLE_ENTRY(2),  CRC8_TABLE_ENTRY(3)
#define CRC8_TABLE_4  CRC8_TABLE_ENTRY(4),  CRC8_TABLE_ENTRY(5),  CRC8_TABLE_ENTRY(6),  CRC8_TABLE_ENTRY(7)
// ... 继续展开

static const uint8_t crc8_table[] = {
    CRC8_TABLE_0,
    CRC8_TABLE_4,
    // ...
};

你想想看，这样写虽然宏定义部分有点长，但每个条目都是编译期常量。最终生成的数组，直接放在ROM里，运行时直接查表，速度飞快。

我曾经在一个电机控制项目里，用这种方法生成了一个2048点的正弦查找表。编译后查看map文件，发现这些数据全在.rodata段，运行时零计算开销。爽。

编译时哈希计算

哈希计算听起来复杂，但编译时也能做。比如一个简单的字符串哈希，用于switch-case的优化：

#define HASH(str) \
    ( (sizeof(str) == 1) ? (str[0]) : \
      (sizeof(str) == 2) ? (str[0] * 31 + str[1]) : \
      (sizeof(str) == 3) ? (str[0] * 31*31 + str[1] * 31 + str[2]) : \
      /* 继续展开到需要的长度 */ \
      0 )

// 使用示例
switch (HASH("cmd_start")) {
    case HASH("cmd_start"): /* ... */ break;
    case HASH("cmd_stop"):  /* ... */ break;
}

这里有个坑——sizeof(str) 在宏里对字符串字面量求值，得到的是包括结尾'\0'的长度。所以实际计算时要减1。我踩过这个坑，调试了半天才发现哈希值对不上。

更稳妥的做法，是用一个编译时字符串长度宏：

#define STRLEN(s) (sizeof(s) - 1)

#define HASH(s) \
    ( STRLEN(s) == 0 ? 0 : \
      STRLEN(s) == 1 ? (s[0]) : \
      STRLEN(s) == 2 ? (s[0] * 31 + s[1]) : \
      /* ... */ )

这样，HASH("hello") 在编译时就被展开成一个整数常量。你可以用它做switch-case的标签，或者作为枚举值。

知识体系总览

下面这张图，是我自己总结的编译时计算的核心逻辑：

实际项目中的避坑指南

我曾经在一个通信协议栈里，用编译时哈希来做命令分发。结果发现，当字符串长度超过宏展开深度时，编译器直接报错。嗯，这里要注意——宏展开深度有限制，一般GCC默认是256层，MSVC是1024层。

另外，编译时计算虽然好，但也不是万能的：

• 宏展开会增大代码体积——每个宏实例都会展开成完整表达式。如果数组很大，编译后的目标文件会膨胀。
• 调试困难——编译时计算的错误信息往往晦涩难懂。我建议先用普通函数验证逻辑，再转成宏。
• 可移植性——不同编译器的常量折叠能力不同。我在IAR上试过，有些复杂的常量表达式它就是不折叠，运行时才算。

最后说一句——编译时计算是C语言里被低估的能力。很多人觉得宏只是文本替换，但配合常量表达式，它其实能做很多「元编程」的活。你想想看，把计算从运行时挪到编译时，不仅省了CPU，还让代码更优雅。何乐而不为？

---

公众号:蓝海资料掘金营，微信deep3321