11、#error与#line：编译期的“红牌”与“路标”

各位好，欢迎来到宏定义与预处理系列的第十一讲。

今天聊两个“存在感”不那么强，但关键时刻能救命的指令——#error 和 #line。

先说个我自己的经历。几年前接手一个老项目，代码里有一堆平台相关的宏定义。我改完一个模块，编译通过，心里还挺美。结果烧到板子上，跑起来直接死机。查了两天才发现——编译器用的版本不对，某个关键宏在新版里被废弃了，但编译时没有任何提示。我当时就想：要是代码里能有个“版本检查”，编译不通过就直接报错，该多好。

嗯，#error 就是干这个的。

#error：编译期断言，说停就停

#error 的用法极其简单：

#error "错误信息"

只要预处理器碰到这行，编译立刻终止，并输出你写的错误信息。没有商量余地。

它最常见的用途，就是做“编译期断言”。比如检查编译器版本：

#if __STDC_VERSION__ < 199901L
#error "需要 C99 或更高版本支持"
#endif

再比如检查平台：

#if !defined(__linux__) && !defined(__APPLE__)
#error "当前仅支持 Linux 和 macOS 平台"
#endif

你想想看，这些检查如果放到运行时，用户可能跑了好几个小时才发现问题。而 #error 在编译阶段就把问题堵死了——这才是真正的“尽早失败”。

实战：版本检查与编译约束

我习惯在项目里放一个 config_check.h，专门做编译期约束。举个例子：

#ifndef CONFIG_CHECK_H
#define CONFIG_CHECK_H

// 强制要求 C11 以上
#if __STDC_VERSION__ < 201112L
#error "本项目需要 C11 标准，请使用 -std=c11 编译"
#endif

// 检查关键宏是否定义
#ifndef MAX_CONNECTIONS
#error "必须定义 MAX_CONNECTIONS，请在编译时添加 -DMAX_CONNECTIONS=xxx"
#endif

// 检查数值范围
#if MAX_CONNECTIONS < 1 || MAX_CONNECTIONS > 1024
#error "MAX_CONNECTIONS 取值范围为 1~1024"
#endif

// 检查字节序（假设项目只支持小端）
#if !defined(__BYTE_ORDER__) || __BYTE_ORDER__ != __ORDER_LITTLE_ENDIAN__
#error "本项目仅支持小端字节序"
#endif

#endif

这段代码里，我用了三个 #error：

• 第一个检查 C 标准版本
• 第二个检查关键配置宏是否定义
• 第三个检查数值范围
• 第四个检查字节序

这些检查全部在编译期完成，零运行时开销。我曾经在一个跨平台项目里，就是因为忘了加字节序检查，导致在某个大端平台上数据解析全乱套。从那以后，我每个项目都会加这么一套“编译期安检”。

#line：调试信息的“路标”

说完 #error，再聊聊 #line。这个指令平时用得少，但一旦遇到代码生成器、宏展开调试，它就是神器。

#line 的语法：

#line 行号 "文件名"

它的作用是告诉编译器：接下来这行代码，在调试信息里要当成“行号”和“文件名”来对待。说白了，就是篡改编译器看到的“假行号”和“假文件名”。

举个例子：

#line 100 "generated_code.c"
int x = 42;

如果这行代码报错，编译器会告诉你错误在 generated_code.c 的第 100 行。但实际上，这行代码可能在你手写的 main.c 的第 5 行。

为什么要这么干？

最常见的使用场景是代码生成器。比如你用 Python 脚本生成了大量 C 代码，这些代码最终会被编译。如果生成的代码有错误，调试信息指向的是“生成后的文件”，你根本不知道原始模板的哪一行出了问题。

这时候，#line 就能把调试信息“映射”回原始模板的行号。我见过一个项目，用 #line 把几百行生成的代码，全部映射回一个只有几十行的模板文件——调试体验瞬间提升。

#line 的另一个用途：宏展开调试

我记得有一次调试一个极其复杂的宏，展开后有好几十行。每次报错，编译器都指向宏展开后的某一行，但我根本不知道那对应宏定义里的哪一部分。

后来我用 #line 在宏定义里做了“标记”：

#define COMPLEX_MACRO(x) \
    do { \
        #line 1 "macro_part1" \
        int a = (x) * 2; \
        #line 2 "macro_part2" \
        int b = a + 1; \
        #line 3 "macro_part3" \
        int c = b * b; \
    } while(0)

这样，如果宏展开后的某行报错，编译器会告诉你错误在 macro_part2 的第 2 行——我就能立刻定位到宏定义里的对应部分。虽然这招有点“野”，但在调试复杂宏时确实管用。

知识体系总览

下面这张图，帮你理清今天讲的核心逻辑：

这张图把两个指令的定位、作用和应用场景串起来了。左边是“红牌”——#error，负责在编译期喊停；右边是“路标”——#line，负责修正调试信息。两者看似无关，但都是预处理阶段控制编译行为的关键工具。

避坑指南

最后，分享几个我踩过的坑：

• #error 不能放在函数内部。预处理器指令是全局的，不能放在函数体里。如果你试图在函数里用 #error 做条件检查，编译器会报错。
• #line 的行号不能为 0。标准规定行号必须为正整数。我曾经手滑写了个 #line 0，结果编译器直接罢工。
• #line 只影响调试信息，不影响 __LINE__。等等，这句话不对——__LINE__ 宏的值也会被 #line 影响。因为 __LINE__ 本身就是预处理器维护的。所以如果你用了 #line，后续代码里的 __LINE__ 也会跟着变。这一点要格外小心。

好了，今天的内容就到这里。#error 和 #line 虽然冷门，但用好了能省不少调试时间。下次你写代码生成器，或者被复杂宏搞得焦头烂额时，不妨试试这两个指令。

---