1. 从一个真实的编译报错说起几年前我在维护一个跨平台的日志模块时遇到过一个让我盯着屏幕看了半小时的编译错误。报错信息大概是这样的error: pasting ) and LOG_LEVEL does not give a valid preprocessing token。当时我的第一反应是——我明明只是写了一个宏参数传进去就完事了怎么预处理器还管起我括号和标识符能不能拼在一起了后来把出错的那行代码单独拎出来用gcc -E展开一看才发现问题出在宏定义里一个不起眼的##上。那个宏的本意是把前缀和日志级别拼成一个完整的函数名但我在某个分支里多写了一个括号导致##试图把)和后面的标识符粘在一起预处理器直接罢工。这件事让我意识到#和##这两个在宏里看起来像装饰符号的东西其实是 C/C 预处理阶段最容易被低估、也最容易踩坑的运算符。很多人写宏的时候凭感觉加#或##能编过就万事大吉一旦换个编译器、换个调用方式问题就冒出来了。这篇文章就围绕这两个运算符把它们的语义、典型用法、常见陷阱和实战技巧一次讲透。不管你是刚接触宏的新手还是写了多年 C/C 但一直没系统梳理过预处理器的老手应该都能从中找到一些之前忽略的细节。需要先明确一个前提#和##只在宏定义体内有效它们不是 C/C 语言层面的运算符而是预处理器指令的一部分。这意味着它们的作用发生在编译之前理解它们的关键在于理解“预处理器到底做了什么”。2.#运算符把参数变成字符串的字符串化机制2.1 字符串化的本质是什么#在宏定义中被称为字符串化运算符stringizing operator。它的作用非常直接把宏参数转换成对应的字符串字面量。注意这里的关键词是“对应的”因为转换过程并不是简单地在参数两边加引号而是有一套明确的规则。先看最基本的用法#define STR(x) #x STR(hello) // 展开为 hello STR(123) // 展开为 123 STR(a b) // 展开为 a b这里有一个很多人第一次接触时会感到意外的点STR(a b)展开后是a b而不是a b或者别的什么。预处理器会把参数中的空白序列压缩成一个空格然后整体作为字符串内容。也就是说STR(a b)和STR(a b)的结果是一样的都是a b。这个特性在实际开发中非常有用。比如你想打印一个表达式的文本形式同时打印它的值#define PRINT_EXPR(expr) \ printf(%s %d\n, #expr, (expr)) int x 3, y 4; PRINT_EXPR(x y); // 输出: x y 7这种写法在调试和单元测试中特别方便你不需要手动维护一份“表达式文本”和“表达式值”的对应关系宏帮你一次性搞定。2.2 字符串化不会展开嵌套宏这是#最容易让人踩坑的地方之一。看下面这个例子#define VALUE 42 #define STR(x) #x STR(VALUE) // 展开为 VALUE而不是 42很多人会直觉地认为STR(VALUE)应该先展开VALUE为42然后再字符串化成42。但实际结果是VALUE。原因在于#运算符作用于宏参数时参数不会被预先展开。预处理器直接把参数字面上的 token 序列拿来做字符串化。如果你确实需要先展开再字符串化需要加一层间接宏#define STR_IMPL(x) #x #define STR(x) STR_IMPL(x) STR(VALUE) // 现在展开为 42这个技巧的原理是外层STR先把VALUE展开为42然后把42作为参数传给STR_IMPL再由STR_IMPL里的#完成字符串化。多一层间接就多一次展开机会。这个模式在需要把宏常量转成字符串的场景中非常常见比如把版本号宏转成字符串用于日志输出。2.3 字符串化中的转义处理当参数中包含字符串字面量或字符字面量时#会自动插入反斜杠进行转义STR(hello) // 展开为 \hello\ STR(a) // 展开为 a STR(a\nb) // 展开为 \a\\nb\这个行为保证了字符串化后的结果是一个合法的字符串字面量。如果你手动拼接字符串很容易忘记处理这些转义而#帮你自动完成了。不过要注意反斜杠在宏定义中还有续行的作用。如果你在宏参数里写了反斜杠情况会变得复杂。比如STR(a\b) // 结果取决于具体实现可能不是你想要的样子所以实际使用中尽量避免在传给#的参数里包含反斜杠除非你非常清楚自己在做什么。2.4 一个实用的字符串化案例自动生成枚举名假设你有一组错误码枚举想在日志里同时输出错误码的数值和名称。传统做法是维护一个switch或者一个字符串数组但这样容易漏掉新增的枚举值。用#可以做到自动同步#define ERROR_NAME(e) #e typedef enum { ERR_NONE 0, ERR_TIMEOUT, ERR_INVALID_PARAM, ERR_OUT_OF_MEMORY } ErrorCode; const char* error_code_to_string(ErrorCode code) { switch (code) { case ERR_NONE: return ERROR_NAME(ERR_NONE); case ERR_TIMEOUT: return ERROR_NAME(ERR_TIMEOUT); case ERR_INVALID_PARAM: return ERROR_NAME(ERR_INVALID_PARAM); case ERR_OUT_OF_MEMORY: return ERROR_NAME(ERR_OUT_OF_MEMORY); default: return UNKNOWN; } }虽然switch本身还是要写但至少字符串部分不用手动维护了。更进一步可以用 X-Macro 技巧把枚举定义和字符串映射合并到一处这个后面会提到。3.##运算符token 拼接的粘合剂与它的边界3.1 token 拼接到底在拼什么##被称为token 粘贴运算符token-pasting operator它的作用是把两个相邻的预处理 token 合并成一个 token。注意这里说的是“token”不是“字符串”也不是“字符”。理解 token 的概念是理解##的关键。在预处理阶段源代码被切分成一系列 token比如标识符、数字、运算符、标点符号等。##的作用就是把左右两边的 token 粘成一个新的 token#define CONCAT(a, b) a##b CONCAT(foo, bar) // 展开为 foobar CONCAT(var, 1) // 展开为 var1 CONCAT(123, 456) // 展开为 123456这里foo和bar是两个标识符 token粘在一起变成一个新的标识符foobar。123和456是两个数字 token粘在一起变成123456。但##不是万能的。它只能拼接出合法的 token。什么叫合法就是拼接后的结果必须是一个预处理器能识别的 token。比如CONCAT(, -) // 错误- 不是一个合法的 token CONCAT(1, ) // 错误1 不是一个合法的 token CONCAT(., .) // 错误.. 不是一个合法的 token除非是 C 的某种上下文这些都会导致编译错误报错信息通常就是本文开头提到的那种does not give a valid preprocessing token。3.2##两侧的空白处理和#类似##两侧的空白在拼接时会被忽略。但有一个细节需要注意##会把它左右两侧的 token 直接粘在一起不会插入任何空格。所以#define CONCAT(a, b) a ## b CONCAT(foo, bar) // foobar和#define CONCAT(a, b) a##b CONCAT(foo, bar) // foobar结果是一样的。但如果你写成#define CONCAT(a, b) a ## b CONCAT(foo, bar) // 仍然是 foobar预处理器会忽略##周围的空白直接拼接。这个行为在写多行宏的时候要特别注意因为续行符\后面的空白可能会影响可读性但不会影响拼接结果。3.3##与宏展开的交互和#不同##两侧的参数会被展开但展开发生在拼接之前还是之后取决于具体写法。标准规定##两侧的参数先被替换成对应的实参然后进行拼接。但这里有一个微妙之处——如果实参本身是一个宏它会不会被展开看这个例子#define PREFIX my_ #define CONCAT(a, b) a##b CONCAT(PREFIX, func) // 展开为 my_func 还是 PREFIXfunc实际结果是PREFIXfunc。因为##阻止了参数的展开。PREFIX作为参数传给CONCAT后直接和func拼接不会先展开成my_。如果你希望先展开再拼接同样需要加一层间接#define CONCAT_IMPL(a, b) a##b #define CONCAT(a, b) CONCAT_IMPL(a, b) CONCAT(PREFIX, func) // 现在展开为 my_func这个模式和#的间接展开模式如出一辙。记住这个规律#和##都会阻止参数的预展开需要额外一层宏来强制展开。3.4 用##生成函数名和变量名##最经典的用途之一是生成带前缀或后缀的标识符。比如在一个模块里你想为每种类型生成一套操作函数#define DEFINE_ACCESSORS(type, name) \ type get_##name(void) { return g_##name; } \ void set_##name(type v) { g_##name v; } DEFINE_ACCESSORS(int, count) // 展开为: // int get_count(void) { return g_count; } // void set_count(int v) { g_count v; }这种写法在 C 语言中模拟“泛型”时非常常见。虽然 C 有模板但在一些嵌入式场景或者需要保持 C 兼容性的代码库里宏生成函数仍然是主流做法。再比如生成一组相关的变量#define DECLARE_BUFFER(name, size) \ char buf_##name[size]; \ int buf_##name##_len 0; DECLARE_BUFFER(rx, 256) // 展开为: // char buf_rx[256]; // int buf_rx_len 0;注意这里用了两次##一次拼接buf_和rx一次拼接buf_rx和_len。这种链式拼接在宏里很常见但要注意拼接顺序和 token 合法性。4. 当#和##一起出现复合宏的设计模式4.1 日志宏的经典实现在实际项目中#和##经常一起出现在日志宏里。一个典型的日志宏需要做到输出日志级别、文件名、行号、格式化消息同时支持可变参数。下面是一个简化版的实现#define LOG(level, fmt, ...) \ do { \ fprintf(stderr, [%s] %s:%d: fmt \n, \ #level, __FILE__, __LINE__, ##__VA_ARGS__); \ } while (0)这里#level把日志级别转成字符串##__VA_ARGS__是 GCC 的扩展用法用于处理可变参数为空的情况。当__VA_ARGS__为空时##会把前面的逗号“吃掉”避免出现fprintf(..., )这样的语法错误。这个##__VA_ARGS__的用法虽然被广泛支持但它并不是 C 标准的一部分。C20 引入了__VA_OPT__来标准化这个行为但在那之前##__VA_ARGS__是事实上的标准做法。如果你写的代码需要跨编译器这一点要特别注意。4.2 用 X-Macro 消除重复代码X-Macro 是一种利用宏展开来生成重复代码的技术#和##在其中扮演关键角色。假设你有一组配置项需要同时生成枚举、字符串映射和默认值表#define CONFIG_ITEMS \ X(TIMEOUT, 30) \ X(RETRY, 3) \ X(BUFFER_SIZE, 1024) // 生成枚举 #define X(name, value) CFG_##name, typedef enum { CONFIG_ITEMS } ConfigKey; #undef X // 生成字符串映射 #define X(name, value) #name, const char* config_names[] { CONFIG_ITEMS }; #undef X // 生成默认值 #define X(name, value) value, const int config_defaults[] { CONFIG_ITEMS }; #undef X这段代码里CONFIG_ITEMS宏定义了一份“数据源”然后通过三次不同的X宏定义分别生成了枚举、字符串数组和默认值数组。#name把配置项名称转成字符串CFG_##name生成枚举常量名。这种模式在需要维护多份相关数据时非常高效改一处就能同步所有地方。不过 X-Macro 也有代价可读性对不熟悉的人来说比较差调试时展开后的代码可能很长。所以它适合用在数据驱动、重复度高的场景不适合滥用。4.3 字符串化与拼接的组合技巧有时候你需要根据宏参数生成一个字符串同时生成一个对应的标识符。比如在注册回调函数时既需要函数名又需要函数名的字符串形式用于日志#define REGISTER_HANDLER(name) \ do { \ register_handler(#name, handle_##name); \ } while (0) void handle_connect(void) { /* ... */ } void handle_disconnect(void) { /* ... */ } REGISTER_HANDLER(connect); REGISTER_HANDLER(disconnect);这里#name生成connect和disconnecthandle_##name生成handle_connect和handle_disconnect。一个宏同时完成了字符串化和 token 拼接代码非常紧凑。这种模式在事件系统、命令注册、插件加载等场景中很常见。它的优势在于新增一个处理器只需要写一行REGISTER_HANDLER(xxx)不需要手动维护字符串和函数名的对应关系。5. 那些年我踩过的#和##的坑5.1 逗号在宏参数中的陷阱宏参数是以逗号分隔的但如果参数本身包含逗号就会出问题。比如#define MAKE_PAIR(a, b) a##b MAKE_PAIR(x, y) // 正常展开为 xy MAKE_PAIR((1, 2), z) // 错误预处理器看到三个参数(1, 2)里的逗号会被预处理器当作参数分隔符导致宏调用参数数量不匹配。解决办法是用括号把含逗号的参数包起来或者用可变参数宏#define MAKE_PAIR(...) __VA_ARGS__但可变参数宏也有自己的限制比如不能直接对__VA_ARGS__做##拼接因为__VA_ARGS__可能包含多个 token。所以实际使用中尽量避免让宏参数包含逗号或者用辅助宏来拆分。5.2##拼接结果不是合法 token前面提到过##只能拼接出合法的 token。但“合法”的边界有时候比较微妙。比如#define CONCAT(a, b) a##b CONCAT(1, 2) // 12合法 CONCAT(1, e) // 1e合法吗1e在 C 语言中不是一个完整的浮点数字面量1e后面必须跟指数所以1e本身不是一个合法的 token。但预处理器在拼接时可能不会立即报错而是在后续编译阶段才暴露问题。这种延迟报错会让排查变得困难。再比如CONCAT(, ) // 合法自增运算符 CONCAT(-, ) // -合法成员访问运算符 CONCAT(, ) // 合法左移运算符这些拼接结果是合法的因为、-、都是 C/C 中的合法 token。但如果你拼接出*或者这种就会报错。经验法则用##拼接标识符时确保两侧都是合法的标识符片段拼接数字时确保结果是一个合法的数字字面量拼接运算符时确保结果是一个合法的运算符。不确定的时候用gcc -E展开看看。5.3 宏展开顺序导致的意外结果宏展开是一个递归过程但#和##会打断这个递归。看这个例子#define A B #define B C #define STR(x) #x #define CONCAT(a, b) a##b STR(A) // A不是 C CONCAT(A, B) // AB不是 CC因为#和##阻止了参数的展开所以A不会被展开为B再展开为C。如果你需要完全展开必须用间接宏。这个行为在标准里有明确规定但实际写代码时很容易忘记。5.4 跨编译器差异虽然#和##是标准的一部分但不同编译器在某些边缘情况下的行为可能不同。比如##__VA_ARGS__是 GCC 和 Clang 的扩展MSVC 在较新版本中才支持类似行为。再比如某些编译器对##拼接后的 token 合法性检查更严格。如果你写的代码需要跨多个编译器建议尽量使用标准明确支持的特性避免依赖编译器扩展。在多个编译器上测试宏展开结果用-EGCC/Clang或/PMSVC查看预处理输出。对于可变参数宏考虑用__VA_OPT__C20/C23替代##__VA_ARGS__如果目标编译器支持的话。6. 调试宏展开的实用手段6.1 用-E看预处理结果这是最直接的方法。GCC 和 Clang 都支持-E选项只做预处理不编译gcc -E source.c -o source.i然后打开source.i搜索你关心的宏展开位置。如果宏嵌套很深可以在代码里加一些标记#define MARKER(x) /* x */ MARKER(BEFORE_EXPAND) // 你的宏调用 MARKER(AFTER_EXPAND)这样在预处理输出里搜索BEFORE_EXPAND和AFTER_EXPAND就能快速定位到宏展开的区域。6.2 用编译器的宏展开追踪GCC 和 Clang 都支持-ftrack-macro-expansion选项Clang 默认开启在宏展开出错时能给出更详细的上下文。比如gcc -ftrack-macro-expansion2 -c source.c这样当宏展开出错时编译器会显示宏展开的调用栈帮助你定位是哪一层宏出了问题。6.3 用静态断言检查拼接结果如果你用##生成了一个标识符想确认它是否符合预期可以用静态断言#define CONCAT(a, b) a##b #define STATIC_ASSERT(cond, msg) typedef char static_assert_##msg[(cond) ? 1 : -1] STATIC_ASSERT(sizeof(CONCAT(my, var)) 4, my_var_size_check);如果CONCAT(my, var)生成的标识符不存在或者类型不对编译会报错。这种方法在模板元编程和宏生成代码的场景中很有用。6.4 一个实际调试案例我曾经遇到过一个宏展开问题一个用于生成状态机转换函数的宏在某些状态下生成的函数名不对。用-E展开后发现问题出在##的拼接顺序上。宏定义大概是这样的#define STATE_FUNC(state, event) \ on_##state##_##event当state是idleevent是timeout时期望生成on_idle_timeout。但实际生成的是on_idle_timeout——看起来没问题。问题出在某个调用中state参数本身是一个宏比如CURRENT_STATE它展开后是idle。但由于##阻止了展开实际拼接的是on_CURRENT_STATE_timeout导致函数名不匹配。解决办法就是加一层间接宏#define STATE_FUNC_IMPL(state, event) on_##state##_##event #define STATE_FUNC(state, event) STATE_FUNC_IMPL(state, event)这样CURRENT_STATE会先展开为idle然后再拼接。这个坑让我花了整整一个下午才定位到从此养成了“只要宏参数可能是宏就加一层间接”的习惯。7. 进阶话题#和##在现代 C 中的替代方案7.1 什么时候该用宏什么时候不该用#和##虽然强大但宏本身有很多缺点没有类型检查、调试困难、容易产生副作用、污染命名空间。在现代 C 中很多原本用宏实现的场景已经有了更好的替代方案。比如字符串化可以用constexpr函数和std::string_view来替代constexpr std::string_view expr_to_string(std::string_view expr) { return expr; }当然这不能自动把表达式文本转成字符串但可以通过其他方式实现类似效果。C20 的std::source_location可以获取文件名和行号减少了对__FILE__和__LINE__宏的依赖。再比如token 拼接可以用模板和constexpr来模拟template typename T struct TypeName { static constexpr std::string_view name unknown; }; #define DEFINE_TYPE_NAME(type) \ template \ struct TypeNametype { \ static constexpr std::string_view name #type; \ }这里#type仍然用了字符串化但整体结构更符合 C 的类型系统。7.2 宏不可替代的场景尽管现代 C 提供了很多替代方案但有些场景宏仍然是唯一选择条件编译#ifdef、#ifndef这些指令本身就是预处理器的功能无法用语言特性替代。头文件保护#pragma once虽然方便但标准做法仍然是#ifndef宏。生成重复代码X-Macro 在需要生成大量结构化代码时仍然高效。跨语言接口在 C/C 混合编程或者需要导出 C 接口时宏经常用于生成包装代码。编译期配置根据编译选项生成不同的代码路径宏是最直接的手段。所以#和##并不会因为 C 的发展而消失它们仍然是预处理器工具箱里的重要工具。关键在于知道什么时候用它们什么时候用语言特性更合适。7.3 一个混合使用的例子下面这个例子展示了如何用宏生成类型名称同时用 C 的constexpr做编译期检查#define TYPE_NAME(type) #type template typename T constexpr std::string_view type_name() { return unknown; } #define SPECIALIZE_TYPE_NAME(type) \ template \ constexpr std::string_view type_nametype() { \ return TYPE_NAME(type); \ } struct MyStruct {}; SPECIALIZE_TYPE_NAME(MyStruct) static_assert(type_nameMyStruct() MyStruct);这里#type完成了字符串化constexpr函数提供了类型安全的接口static_assert在编译期验证结果。宏和现代 C 特性各司其职配合得还不错。8. 写在最后一些个人习惯我现在的习惯是每次写涉及#或##的宏都会先用gcc -E展开看一眼。这个习惯帮我省下了大量调试时间。另外对于复杂的宏我会在宏定义旁边写一行注释说明展开后的预期结果这样别人包括未来的自己读代码时能快速理解意图。还有一点如果发现一个宏用了超过两层间接展开或者需要同时处理#、##和可变参数我会认真考虑是不是应该换一种实现方式。宏的复杂度增长很快超过一定阈值后维护成本会超过它带来的便利。最后分享一个小技巧在写##拼接时如果拼接结果是一个标识符可以在宏定义里加一个static_assert或者sizeof检查确保生成的标识符确实存在且类型正确。这样即使拼接逻辑出错也能在编译期发现而不是等到运行时才暴露问题。