7、#define 与 #undef：宏的取消定义、条件编译中的配合使用

宏定义这东西，说白了就是给代码里的某个“名字”贴个标签。你告诉编译器：“以后看到这个标签，就把它替换成我指定的内容。” 但有时候，这个标签贴错了，或者贴完了不想用了，怎么办？这时候就需要 #undef 登场了。

我个人习惯把 #define 和 #undef 看作一对“开关”。一个负责打开，一个负责关闭。配合条件编译，它们能玩出很多花样。

7.1 #define：不只是简单的文本替换

先复习一下 #define 的基本用法。它有三种常见形式：

• 对象宏：定义一个常量，比如 #define PI 3.14159
• 函数宏：带参数的宏，比如 #define MAX(a,b) ((a)>(b)?(a):(b))
• 空宏：只定义名字，不替换内容，比如 #define DEBUG

空宏特别有用。它不替换任何东西，但它的“存在”本身就是一个信号。条件编译就是靠这个信号工作的。

7.2 #undef：把宏“收回来”

#undef 的语法很简单：

#undef 宏名

它的作用就是取消一个已经定义的宏。取消之后，这个宏名就不再被识别了。

我在项目中遇到过一种情况：一个头文件里定义了一个通用的调试宏 DEBUG_PRINT，但某个模块想用自己的打印方式。如果直接重新 #define，编译器会报“重复定义”的警告。这时候，先 #undef 再 #define，就干净利落了。

7.3 条件编译中的配合使用

这才是重头戏。#define 和 #undef 最经典的搭档就是 #ifdef、#ifndef、#if 这些条件编译指令。

你想想看，一个项目里可能有多个平台、多种配置。你不可能为每个平台都写一套代码。条件编译就是让你“一份代码，多套编译”。

7.3.1 典型模式：开关控制

#define FEATURE_A_ENABLED

#ifdef FEATURE_A_ENABLED
    // 功能A的代码
    printf("Feature A is active\n");
#else
    // 功能A的替代代码
    printf("Feature A is disabled\n");
#endif

如果你想关闭功能A，只需要把 #define 那行注释掉，或者改成 #undef FEATURE_A_ENABLED。不需要动任何业务代码。

7.3.2 模块化控制：头文件里的开关

我曾经维护过一个嵌入式项目，里面有十几个外设驱动。每个驱动都有一个独立的开关宏。在项目的主配置头文件里，我这样写：

// config.h
#define USE_UART
#define USE_I2C
// #define USE_SPI    // SPI暂时不用，注释掉
#define USE_GPIO

然后在每个驱动文件里：

// uart.c
#include "config.h"

#ifdef USE_UART
    // UART初始化代码
    void uart_init() { ... }
#else
    // 空函数，避免链接错误
    void uart_init() {}
#endif

这样，我只需要改一个配置文件，就能控制整个项目的编译内容。省心省力。

7.3.3 调试与发布版本的切换

这是我最常用的场景。调试阶段，我需要打印大量日志；发布阶段，这些日志必须全部消失。用宏控制，完美解决：

// 调试版本：定义DEBUG宏
#define DEBUG

#ifdef DEBUG
    #define LOG(msg) printf("[DEBUG] %s\n", msg)
#else
    #define LOG(msg) // 空宏，什么都不做
#endif

void process_data() {
    LOG("开始处理数据");
    // ... 业务逻辑 ...
    LOG("数据处理完成");
}

发布时，只需要把 #define DEBUG 改成 #undef DEBUG，所有日志代码就自动消失了。编译器甚至不会生成任何指令。

7.4 避坑指南

嗯，这里要注意几个容易踩的坑。

• 宏的作用域：宏定义没有块作用域。它从定义点开始，到文件结束，或者遇到 #undef 为止。不会因为进入一个函数或一个 {} 就失效。
• 重复定义：同一个宏被定义两次，编译器会警告。所以如果你不确定某个宏是否已经被定义，先 #undef 再 #define 是安全的做法。
• 头文件中的宏：如果头文件里定义了宏，并且被多个源文件包含，那么每个源文件都会看到这个宏。取消定义时，也要在每个源文件里分别 #undef。

我曾经在调试一个多文件项目时，在一个源文件里 #undef 了一个宏，以为其他文件也会受影响。结果其他文件还在用旧的定义，导致行为不一致。排查了半天才发现问题。

7.5 知识体系图

下面这张图展示了 #define 和 #undef 在条件编译中的核心逻辑：

7.6 总结

#define 和 #undef 的组合，是 C 语言预处理阶段最灵活的控制手段之一。它们让你在编译之前就能决定“哪些代码该留，哪些该走”。

我个人习惯在项目里维护一个统一的配置头文件，把所有开关宏都放在里面。每个模块的代码只依赖这些宏，不依赖具体的值。这样，换平台、切配置，都只需要改一个文件。

记住：宏是预处理阶段的工具，不是运行时的变量。用好它们，能让你的代码更干净、更灵活。