15、#line 与 #pragma：行号控制、编译器特定指令、结构体对齐
说实话，#line 和 #pragma 这两个预处理指令，平时用得不算多。但一旦用上，往往就是解决一些比较棘手的问题。我个人习惯把 #line 看作是「调试时的障眼法」，而 #pragma 则是「跟编译器打交道的暗号」。今天咱们就聊聊这两个家伙。
15.1 #line：给编译器「撒谎」的行号控制
#line 的作用很简单——它告诉编译器：接下来这行代码，你把它当成第 X 行，来自文件 Y。说白了，就是修改编译器内部维护的 __LINE__ 和 __FILE__ 这两个预定义宏的值。
语法长这样：
#line 行号 ["文件名"]举个例子：
#include <stdio.h>
int main() {
printf("当前行号: %d\n", __LINE__);
printf("当前文件: %s\n", __FILE__);
#line 100 "fake_file.c"
printf("现在行号: %d\n", __LINE__);
printf("现在文件: %s\n", __FILE__);
return 0;
}输出结果：
当前行号: 5
当前文件: test.c
现在行号: 100
现在文件: fake_file.c你看，编译器真的「信了」。
核心用途：#line 最常见的场景是代码生成器。比如你用 Python 或 Perl 脚本生成了 C 代码，如果生成的代码报错，你希望错误信息指向原始的模板文件，而不是那个又臭又长的生成文件。这时候 #line 就派上用场了。
我在项目中遇到过类似的情况。当时我们写了一个协议解析器的代码生成器，输入是 XML 描述文件，输出是 C 代码。一开始调试时，编译器报错总是定位到生成的 .c 文件，根本不知道原始 XML 的哪条规则出了问题。后来我在生成的每个函数开头都加上了 #line 指令，指向 XML 文件的行号。嗯，调试效率一下子就上来了。
注意：#line 只影响编译器的行号计数，不影响实际代码的执行逻辑。它纯粹是给编译器看的「假情报」。
15.2 #pragma：编译器私房话
#pragma 是 C 标准留给编译器的「后门」。每个编译器都可以定义自己的 #pragma 指令，用来控制编译器的特定行为。标准只规定了 #pragma STDC 系列，其他的全是厂商自定义的。
常用的 #pragma 指令包括：
| 指令 | 作用 | 常见编译器 |
|---|---|---|
#pragma once |
防止头文件重复包含 | GCC、MSVC、Clang |
#pragma pack(n) |
设置结构体对齐字节数 | GCC、MSVC、Clang |
#pragma warning(disable:xxx) |
禁用特定警告 | MSVC |
#pragma GCC optimize("O3") |
设置优化级别 | GCC |
#pragma message("text") |
编译时输出信息 | GCC、MSVC |
我个人最常用的是 #pragma once。它比传统的 #ifndef 守卫更简洁，而且不会出现宏名冲突的问题。不过要注意，#pragma once 不是标准 C，虽然主流编译器都支持，但如果你写的是跨平台库，还是老老实实用 #ifndef 吧。
15.3 结构体对齐：#pragma pack 的实战
结构体对齐是个老生常谈的话题。默认情况下，编译器会在结构体成员之间插入填充字节，以保证每个成员都对齐到它的自然边界上。这样做的好处是访问速度快，坏处是浪费内存。
举个例子：
struct DefaultAlign {
char a; // 1 字节
int b; // 4 字节
short c; // 2 字节
};默认情况下，这个结构体的大小是 12 字节（而不是 1+4+2=7 字节）。为什么？因为 int b 需要 4 字节对齐，所以 a 后面会填充 3 个字节；short c 需要 2 字节对齐，但 b 结束后已经是 8 字节偏移，所以 c 后面还要填充 2 个字节，让整个结构体大小对齐到 4 的倍数。
这时候 #pragma pack 就登场了：
#pragma pack(1) // 设置对齐为 1 字节
struct PackedStruct {
char a;
int b;
short c;
};
#pragma pack() // 恢复默认对齐加了 #pragma pack(1) 后，这个结构体的大小就是 7 字节，没有任何填充。代价是访问 b 和 c 时可能不是对齐访问，在某些架构上会引发性能问题甚至崩溃。
我的建议：#pragma pack 最适合用在网络协议、文件格式、硬件寄存器映射等场景。这些场景下，结构体必须与外部数据格式严格匹配，不能有多余的填充字节。但如果是普通的内存数据结构，我建议保持默认对齐，换取访问速度。
我曾经在一个嵌入式项目中吃过亏。当时要解析一个二进制文件格式，结构体定义用了默认对齐，结果读出来的数据全是错的。排查了半天才发现是填充字节搞的鬼。从那以后，凡是涉及外部数据格式的结构体，我都会用 #pragma pack(1) 包起来。
15.4 知识体系一览
下面这张图帮你理清 #line 和 #pragma 的核心脉络：
15.5 避坑指南
最后分享几个我踩过的坑：
- #pragma pack 的作用域：
#pragma pack(n)从它出现的位置开始生效，直到遇到#pragma pack()恢复默认。如果你忘了恢复，后面的所有结构体都会受影响。我曾经在头文件里用了#pragma pack(1)但忘了恢复，结果整个工程的结构体大小都变了，链接时各种报错。排查了一下午才发现。 - #line 不影响实际行号：
#line只影响编译器报错时显示的行号，不影响代码的执行顺序。别指望它能改变程序流程。 - #pragma once 不是标准：虽然主流编译器都支持，但如果你写的是需要严格遵循 C 标准的代码，还是用
#ifndef守卫更稳妥。 - 结构体对齐与网络字节序：
#pragma pack(1)只解决对齐问题，不解决字节序问题。如果你在 x86 和 ARM 之间传输结构体，还得考虑大小端转换。
好了，关于 #line 和 #pragma 就聊这么多。这两个指令虽然冷门，但用好了能解决不少实际问题。下次遇到代码生成器调试或者结构体对齐的麻烦，不妨试试它们。
公众号：蓝海资料掘金营，微信 deep3321