带参数宏必须为形参和整体表达式加括号以避免优先级错误；多行宏应使用do{...}while(0)封装；调试宏常用__file__、__line__和#操作符；宏适用于文本拼接、符号操作等场景，类型相关逻辑应改用模板。
宏定义带参数时，括号不是可选的
不加括号的宏在展开时会直接文本替换，导致运算符优先级出问题。比如 #define SQUARE(x) x * x，调用 SQUARE(a + b) 展开成 a + b * a + b，结果完全错误。
正确写法必须给形参和整个表达式都加括号：#define SQUARE(x) ((x) * (x))。这是最基础也最容易被跳过的安全习惯。
- 所有参与运算的宏参数必须包裹在
(x)中 - 整个宏体也应包裹在额外一层括号里，避免在复杂表达式中被截断
- 宏名建议全大写加下划线（如
MAX_VALUE），与变量名明显区分
用 do { ... } while(0) 封装多行宏
想让带参数的宏支持类似函数的语义（比如包含多个语句、能跟 if 配合），直接写花括号会出问题——if (cond) MACRO(); else ... 里的分号会让 else 悬空。
标准解法是用 do { ... } while(0) 包裹：
立即学习“C++免费学习笔记（深入）”；
#define LOG_DEBUG(fmt, ...) do { \
fprintf(stderr, "[DEBUG] %s:%d " fmt "\n", __FILE__, __LINE__, ##__VA_ARGS__); \
} while(0)- 它让宏在语法上等价于一条语句，能安全接分号、参与
if/else和for -
##__VA_ARGS__是 GCC/Clang 扩展，用于处理零参数的可变宏（避免末尾逗号） - MSVC 需要启用
/Zc:preprocessor或用__VA_OPT__（C++20）替代
宏里用 __LINE__、__FILE__ 做调试定位
带参数宏常用于日志、断言、自动注册等场景，嵌入预定义标识符能极大提升可调试性。
例如断言失败时打印位置：
#define ASSERT(cond) do { \
if (!(cond)) { \
fprintf(stderr, "ASSERTION FAILED at %s:%d: %s\n", __FILE__, __LINE__, #cond); \
abort(); \
} \
} while(0)-
#cond是字符串化操作符，把x > 0变成"x > 0" -
__FILE__和__LINE__在每次宏调用处实时展开，不是定义处的值 - 注意：这些标识符在头文件中被包含多次时，会展开为各自实际使用位置，不是头文件内部行号
宏和内联函数该怎么选
很多人以为“宏更快”，但现代编译器对 inline 函数的优化已经非常激进。宏真正的不可替代场景其实很窄：
- 需要在编译期做文本拼接（比如
CONCAT(a, b)生成ab） - 需要操作未声明的符号（如自动生成类注册代码，依赖宏展开时机）
- 需要绕过类型检查做泛型模拟（C++98 时代常见，现在应优先用模板）
- 调试辅助类宏（如
LOG_DEBUG）仍广泛使用，因为它们本就不该有类型语义
一旦宏里出现类型相关逻辑（比如想对 int 和 float 做不同处理），就该立刻换成模板或 constexpr if —— 宏做不到类型安全，也压根不理解类型。
真正难处理的是宏和模板混用时的展开顺序、以及跨平台预处理器行为差异（比如 Windows 的 _MSC_VER 和 GCC 的 __GNUC__ 判断）。这些细节不报错，但可能让同一份宏在不同编译器下表现不一致。
