第13章预处理器演进

课程目录第13章预处理器演进

预处理器演进：可变参数宏、__has_include 与 __has_c_attribute

预处理器的演进，说实话，是C语言标准升级里最容易被低估的一块。很多人觉得宏就是简单的文本替换，没什么好说的。但如果你写过一些复杂的日志系统、跨平台适配层，你就会发现——预处理器其实藏着不少好东西。

我个人习惯把预处理器的演进分成三个阶段：C99之前是“能用就行”，C99到C11是“开始讲人话”，C23则是“终于像个现代语言了”。今天我们就聊聊这三个关键特性：可变参数宏、__has_include 和 __has_c_attribute。

可变参数宏（__VA_ARGS__）

先说说可变参数宏。这个特性是C99引入的，说白了就是让宏也能像函数一样接受不定数量的参数。

我记得第一次遇到这个需求是在写调试日志的时候。那时候C89还没这个能力，我不得不写一堆重载宏，或者用逗号表达式来凑合。代码又丑又难维护。

C99之后，事情就简单多了：

#define DEBUG_LOG(fmt, ...) \
    fprintf(stderr, "[DEBUG] " fmt, __VA_ARGS__)

// 使用
DEBUG_LOG("x = %d, y = %s\n", x, str);

这里有个坑，我当年踩过。如果可变参数是空的，比如：

DEBUG_LOG("hello\n");

展开后就成了：

fprintf(stderr, "[DEBUG] " "hello\n", );

看到了吗？末尾多了一个逗号。这在C99里是未定义行为，很多编译器会报错。

注意：C99的可变参数宏在参数为空时会产生尾随逗号。这是一个常见的移植性问题。

C11引入了__VA_OPT__来解决这个问题：

#define DEBUG_LOG(fmt, ...) \
    fprintf(stderr, "[DEBUG] " fmt __VA_OPT__(,) __VA_ARGS__)

这样，当可变参数为空时，__VA_OPT__(,)会被替换为空，逗号就没了。嗯，这个细节我建议你记住，跨平台代码里经常遇到。

小技巧：如果你还在用C99，可以用两个宏来规避尾随逗号问题：

#define DEBUG_LOG(fmt, ...) \
    fprintf(stderr, "[DEBUG] " fmt, ##__VA_ARGS__)

GCC和Clang支持##__VA_ARGS__这个GNU扩展，但MSVC不支持。所以跨平台时还是老老实实用__VA_OPT__吧。

__has_include

接下来聊聊__has_include。这个特性是C23标准引入的，但说实话，Clang和GCC早在C11时代就已经支持了。我猜标准委员会觉得这个特性太实用了，等不及到C23才正式纳入。

__has_include的作用很简单：检查某个头文件是否存在。它通常用在预处理器的条件判断中：

#if __has_include(<optional>)
#  include <optional>
#  define HAS_OPTIONAL 1
#else
#  define HAS_OPTIONAL 0
#endif

我在做跨平台项目时，这个特性帮了大忙。比如有些平台有<sys/epoll.h>，有些只有<poll.h>，还有些两者都没有。以前我得靠平台宏来判断，现在直接问预处理器就行了：

#if __has_include(<sys/epoll.h>)
#  include <sys/epoll.h>
#  define USE_EPOLL 1
#elif __has_include(<poll.h>)
#  include <poll.h>
#  define USE_POLL 1
#else
#  error "No poll implementation found"
#endif

你想想看，这比写一堆#ifdef __linux__要优雅多了。而且它不依赖平台宏，语义更清晰。

核心要点：__has_include是编译时检查，不是运行时。它只告诉你能不能找到这个头文件，不保证头文件里的内容是你想要的。我曾经遇到过头文件存在但内容不兼容的情况，所以建议配合特性检查宏一起使用。

__has_c_attribute

最后说说__has_c_attribute。这个特性也是C23引入的，用来检查编译器是否支持某个属性（attribute）。

C23引入了[[attribute]]语法，跟C++的语法统一了。但不同编译器对属性的支持程度不一样。比如[[nodiscard]]在C23里是标准属性，但有些老编译器不认识。

这时候__has_c_attribute就派上用场了：

#if __has_c_attribute(nodiscard)
#  define NODISCARD [[nodiscard]]
#else
#  define NODISCARD
#endif

NODISCARD int get_value();

如果编译器支持[[nodiscard]]，NODISCARD就展开成它；否则展开成空。这样代码既用了新特性，又保持了兼容性。

我个人习惯在头文件里统一管理这些属性宏：

// compat.h
#if __has_c_attribute(fallthrough)
#  define FALLTHROUGH [[fallthrough]]
#else
#  define FALLTHROUGH ((void)0)
#endif

#if __has_c_attribute(maybe_unused)
#  define MAYBE_UNUSED [[maybe_unused]]
#else
#  define MAYBE_UNUSED
#endif

这样在代码里直接用FALLTHROUGH和MAYBE_UNUSED就行了，既清晰又安全。

注意：__has_c_attribute只检查C风格的属性，不检查GNU的__attribute__((...))。如果你需要检查GNU属性，得用__has_attribute（这是编译器扩展，不是标准）。

知识体系总览

下面这张图总结了预处理器这三个演进特性的核心逻辑和关系：

这三个特性虽然功能不同，但目标是一致的：让C代码更容易跨平台、更容易维护。可变参数宏解决了宏的参数灵活性，__has_include解决了头文件的可移植性，__has_c_attribute解决了属性的兼容性。

我在实际项目中，通常会把这三个特性组合使用。比如写一个跨平台的日志库，既要用可变参数宏处理日志格式，又要用__has_include检测平台相关的头文件，还要用__has_c_attribute给关键函数加上[[nodiscard]]属性。三者配合，代码质量能上一个台阶。