20、跨平台编译：条件编译、平台宏定义、不同编译器兼容性处理

跨平台编译，说白了就是让同一份C代码能在Windows、Linux、macOS甚至嵌入式RTOS上都能跑起来。这事儿看着简单，做起来坑不少。我这些年折腾过不少跨平台项目，从早期的ARM裸机到后来的Linux应用层，每次换平台都得跟编译器、宏定义、链接脚本斗智斗勇。

今天咱们就聊聊怎么优雅地处理跨平台编译。核心就三件事：条件编译、平台宏定义、编译器兼容性。这三板斧耍好了，你的代码就能“一次编写，到处编译”。

20.1 条件编译：代码的“分身术”

条件编译是C语言预处理器提供的能力。说白了就是让编译器根据条件决定“这段代码要不要编译”。最常见的指令是#ifdef、#ifndef、#if、#else、#elif、#endif。

我个人习惯把平台相关的代码用条件编译包裹起来。比如这样：

#ifdef _WIN32
    #include <windows.h>
    #define SLEEP(ms) Sleep(ms)
#elif defined(__linux__)
    #include <unistd.h>
    #define SLEEP(ms) usleep((ms) * 1000)
#elif defined(__APPLE__)
    #include <unistd.h>
    #define SLEEP(ms) usleep((ms) * 1000)
#else
    #error "Unsupported platform!"
#endif

你看，一个SLEEP宏，在不同平台上映射到不同的系统调用。Windows用Sleep，Linux和macOS用usleep。这样上层代码只需要调用SLEEP(100)，不用关心底层是哪个系统。

20.2 平台宏定义：编译器告诉你的“暗号”

编译器在编译时会预定义一些宏，告诉你当前是什么平台、什么编译器。这些宏就是“暗号”。你只要识别这些暗号，就能写出平台无关的代码。

常见的平台宏定义有这些：

宏定义	含义	常见编译器
_WIN32	Windows 32/64位平台	MSVC、MinGW
__linux__	Linux平台	GCC、Clang
__APPLE__	macOS/iOS平台	Clang
__unix__	Unix类系统	GCC、Clang
__arm__	ARM架构	ARMCC、GCC
__MINGW32__	MinGW编译器	MinGW

我曾经在一个项目里遇到过这样的问题：代码在Linux上用GCC编译得好好的，拿到Windows上用MSVC编译就报错。查了半天，发现是_WIN32这个宏在MSVC里默认定义，但在MinGW里也定义。后来我加了__MINGW32__的判断，才把问题解决。

20.3 不同编译器兼容性处理

编译器之间的差异，说白了就是“方言”问题。GCC、Clang、MSVC、ARMCC，它们都支持C标准，但各自有一些扩展和差异。处理这些差异，我有几个经验：

20.3.1 属性/扩展语法

GCC和Clang支持__attribute__，MSVC支持__declspec。比如声明一个函数为“弱符号”：

#if defined(__GNUC__) || defined(__clang__)
    #define WEAK __attribute__((weak))
#elif defined(_MSC_VER)
    #define WEAK __declspec(selectany)
#else
    #define WEAK
#endif

WEAK void my_function(void) {
    // 默认实现
}

嗯，这里要注意：__attribute__和__declspec的行为不完全一样。我建议只在确实需要的地方用，不要滥用。

20.3.2 内联函数

C99标准支持inline关键字，但不同编译器的处理方式有细微差别。GCC和Clang支持static inline，MSVC支持__inline。我一般这样处理：

#ifdef _MSC_VER
    #define INLINE __inline
#else
    #define INLINE inline
#endif

INLINE int add(int a, int b) {
    return a + b;
}

20.3.3 字节对齐

嵌入式开发中经常需要控制结构体的对齐方式。不同编译器语法不同：

// GCC/Clang
struct __attribute__((packed)) my_struct {
    uint8_t a;
    uint16_t b;
};

// MSVC
#pragma pack(push, 1)
struct my_struct {
    uint8_t a;
    uint16_t b;
};
#pragma pack(pop)

我个人习惯用#pragma pack，因为它在主流编译器上都支持。但要注意，#pragma pack会影响后续所有结构体，所以一定要用push/pop配对。

20.4 跨平台编译的“避坑指南”

这些年踩过的坑不少，挑几个典型的说说：

• 路径分隔符： Windows用反斜杠\，Linux用正斜杠/。我建议在代码里统一用正斜杠，或者用宏来转换。
• 换行符： Windows是\r\n，Linux是\n。读写文本文件时要注意。
• 动态库加载： Windows用LoadLibrary/GetProcAddress，Linux用dlopen/dlsym。建议封装成统一的接口。
• 线程/锁： Windows用CreateThread/CriticalSection，Linux用pthread。建议用C11的thrd或者封装一层。

20.5 知识体系结构图

下面这张图展示了跨平台编译的核心知识结构：

20.6 实战建议

最后给几点实战建议：

• 先确定目标平台： 项目启动时就把要支持的平台列清楚。不要等到代码写完了再考虑跨平台。
• 用构建工具辅助： CMake、Makefile、SCons这些工具能帮你管理平台相关的编译选项。我个人偏爱CMake，它的target_compile_definitions可以很方便地传递宏定义。
• 持续集成测试： 在多个平台上跑CI。我见过太多“在Linux上能编译，在Windows上就报错”的情况。CI能帮你尽早发现问题。
• 不要过度抽象： 跨平台是手段，不是目的。如果某个功能只在特定平台上有，强行抽象反而增加复杂度。这时候用条件编译直接处理更简单。

跨平台编译这事儿，说白了就是“多一份准备，少一份麻烦”。把平台相关的代码隔离好，把宏定义用对，把编译器差异处理好，你的代码就能在多个平台上平稳运行。嗯，今天就聊到这儿，希望对你有帮助。

---

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