Item 2：以 const、enum、inline 替换 #define

从“编译器为什么不知道宏的名字”开始

预处理器在 C++ 编译器建立类型和符号之前做 token 替换。

例如：

#define ASPECT_RATIO 1.653

编译错误和调试信息中可能只出现 1.653，而不是 ASPECT_RATIO。宏没有类型，也不遵守 namespace 或 class 作用域。

Item 2 的核心不是少打一个 #，而是尽量让名称进入编译器掌握的语言世界。

对象式宏优先替换为有类型常量

原书以 const double 替代宏：

const double aspectRatio = 1.653;

现代头文件若需要一个跨翻译单元共享身份的编译期常量，可写：

inline constexpr double aspectRatio{1.653};
inline constexpr std::string_view applicationName{"Renderer"};

与

是原书原则在现代 C++ 的直接延伸。不要机械把所有宏替换为 namespace const 而忽略身份和链接需求。

字符串常量避免裸指针语义

比 #define AUTHOR_NAME "Scott" 更有类型，但现代只读接口常用 std::string_view，它同时携带长度且不取得所有权。需要独立拥有内容时使用 std::string。

inline constexpr std::string_view authorName{"Scott Meyers"};
 
void print_author(std::string_view name);

仍有借用生命周期：不能返回指向已销毁临时 string 的 view。替换宏后获得类型系统，不代表生命周期自动正确。

class 专属常量与 enum hack

原书时代常见：

class GamePlayer {
public:
    static const int NumTurns = 5;
    int scores[NumTurns];
};

若程序 ODR-use 该成员，例如取地址，旧语言规则可能要求源文件再提供定义。现代可写 inline static constexpr int NumTurns{5};。

决定“类内初值已经编译”是否足够。

class GamePlayer {
public:
    enum { NumTurns = 5 };
    int scores[NumTurns];
};

它解释历史模板代码与元编程风格，现代新代码通常优先 static constexpr。条款要求理解替代关系，不要求复古写法成为默认。

linkage 决定“有几个常量”

头文件中的普通 namespace const 传统上具有 internal linkage，每个翻译单元可能有一份实体；inline constexpr 可表示一个程序级实体。若只用值，两者结果常相同；若比较地址、注册身份或把引用作为模板参数，差异就可观察。

必须用至少两个 .cpp 测试头文件常量，单文件无法暴露重复定义或身份错误。

// constants.hpp
inline constexpr int protocolVersion{7};
 
// a.cpp / b.cpp
const int* version_from_a() { return &protocolVersion; }
const int* version_from_b() { return &protocolVersion; }

断言两个地址相同，证明需求与实现一致；若身份不重要，则测试值和链接成功即可。

函数式宏的重复求值

经典最大值宏即使加满括号，仍可能重复求值：

#define CALL_WITH_MAX(a, b) f((a) > (b) ? (a) : (b))
 
int x = 5;
int y = 0;
CALL_WITH_MAX(++x, y);      // x 可能增加两次
CALL_WITH_MAX(++x, y + 10); // x 可能只增加一次

括号只能修复优先级，不能修复次数、类型和名称查找。

inline function template 保留效率与语义

template<class T>
inline void callWithMax(const T& left, const T& right)
{
    f(left > right ? left : right);
}

函数实参在进入函数前各求值一次；参数和返回类型受检查；名称可放入 namespace；调试器能识别函数。inline 不是强制展开，而是允许多处相同定义并向优化器表达候选。

现代泛型最大值还要处理不同类型、引用悬空与比较投影；不要为了模仿宏随意返回 const T& 指向临时值。

运算符优先级与 token 污染

#define SQUARE(x) x * x 在 SQUARE(a + b) 下展开为 a + b * a + b。即使写成 ((x) * (x))，副作用仍存在。

系统头中的 min/max 宏是常见例子。语言函数可通过作用域、重载和 ADL 正常解析，宏做不到。

哪些场景仍需要预处理器

include guard、#if 平台适配、编译器属性封装、字符串化和 token paste 有时确实只能在预处理阶段完成。条款是“宁可以语言实体替换”，不是“所有 #define 都违法”。

#if defined(_WIN32)
  #define LIB_EXPORT __declspec(dllexport)
#else
  #define LIB_EXPORT [[gnu::visibility("default")]]
#endif

可以让平台宏只决定属性，业务代码继续使用类型与函数。宏名采用项目级前缀，并在可能时 #undef，降低污染。

迁移与验证顺序

先搜索定义与全部调用，分类为常量、类常量、函数行为或真正预处理。记录是否取地址、跨翻译单元、传递副作用表达式、依赖字符串化。再选择替代物并保持测试。

先预测：对 CALL_WITH_MAX(++x, y) 和 CALL_WITH_MAX(++x, y + 10) 手工展开，写出 x 的增量；替换为函数模板后重新预测。运行计数器测试，确认每个实参只求值一次。

• 常量测试覆盖值、类型、作用域和必要的地址身份。
• class 常量同时测试普通使用与 ODR-use。
• 函数宏测试副作用、混合类型、异常和返回生命周期。
• 两个翻译单元共同 include 头文件并链接。
• 条件编译在每个目标平台至少编译一个分支。

迁移失败模式

第一类失败是“值正确、身份错误”。把宏改成头文件 namespace const 后，每个翻译单元都可能持有独立对象；普通比较看不出来，但地址注册、引用模板参数或跨模块缓存会分裂。先写清是否需要统一身份，再选择 internal linkage 或 inline variable。

第二类失败是“单文件正确、完整程序错误”。类内 static const 的整数初值可满足数组界限，却在取地址时暴露缺失定义；非 inline 外部变量则会造成重复定义。测试必须包含编译、两个翻译单元链接和实际 ODR-use，不能只运行头文件单测。

第三类失败是“宏副作用消失，却引入引用生命周期”。函数模板若为避免复制返回 const T&，而调用点传入临时量，结果可能在完整表达式后悬空。替换宏时要重新设计返回值语义，而不是逐 token 模仿展开结果。小型值通常直接返回值，并让优化器处理复制消除。

迁移完成后保留一张对照表：旧宏职责、替代实体、作用域、linkage、是否可取地址、实参求值次数和失败测试。它比“宏数量减少”更能证明条款真正落实。

小结

• 对象式宏不参与类型、作用域和符号系统，优先改为 const/constexpr
• 类内整数历史上可用 enum hack，现代通常用 inline static constexpr
• linkage 与 ODR-use 决定头文件常量需要怎样声明和定义
• 函数式宏的括号不能解决重复求值，inline function template 才能恢复函数语义
• 条件编译等真正文本处理可以保留，但应隔离并减少污染