C++最佳实践：用const、enum、inline替代#define的深度解析

我印象很深的一次排查，是在某个跨平台渲染模块里。窗口宽高比被人写成了宏，就一行#define WINDOW_RATIO 1.77，整个工程二十多个文件都在引用。某天另一位图形算法工程师在自己负责的头文件里也顺手定义了一个同名宏，两边一撞，渲染窗口的长宽彻底乱了。最折磨人的是：编译过程完全正常，运行时画面比例才出问题。那种“编译正常、运行错乱”的Bug，排查起来比直接报错痛苦得多，因为编译器完全帮不上忙。

这个教训让我对#define产生了本能的警惕。后来每次做代码评审，看到头文件里堆着一排排宏定义，我都会想起C++最佳实践体系里的条款02：尽量以 const、enum、inline 代替 #define。这不是教人死守教条，而是在讲一个很朴素的道理——预处理阶段的宏替换绕过了编译器的类型检查、作用域规则和符号表，但凡语言本身能表达的语义，就不要交给预处理器。

这篇文章我会从宏被替换的底层机制讲起，用实际代码对比 const、enum、inline 三种替代方案各自适合什么场景，再结合现代 C++ 里 constexpr、inline static 等新特性给出取舍建议，最后分享我实际改造遗留代码时踩过的一些坑。内容适合刚接触 C++ 最佳实践的读者，也适合正在推动团队代码规范落地的同学。

1. 宏的“假编译器”属性：替换发生在编译之前

1.1 预处理阶段到底做了什么

很多人写 C++ 写了几年，对编译流程的理解依然停留在“编译器一行行处理代码”的层面。实际上，C/C++ 的编译是一个流水线：预处理、编译、汇编、链接。宏定义#define在预处理阶段就已经完成了使命，也就是“文本替换”。编译器真正开始做词法分析、语法分析、类型检查的时候，看到的是替换之后的代码，而不是你亲手写的那些宏名字。

我举一个例子。你在代码里写了：

#define ASPECT_RATIO 1.653 double width = height * ASPECT_RATIO;

预处理器先把ASPECT_RATIO替换成1.653，于是编译器实际处理的是：

double width = height * 1.653;

这里最大的问题是：如果1.653拼写错了，或者类型不合适，编译器报错信息里出现的是1.653这个魔数，而不是ASPECT_RATIO这个有名字的标识符。你对着报错去搜索代码，搜ASPECT_RATIO是搜不到东西的。这就好比快递单上只写了门牌号，没写收件人姓名，丢了件你根本不知道该找谁。

其实预处理阶段还有大量看起来“很自然”的坑。比如你定义一个宏来隐藏一个表达式的一部分，替换时把整个上下文打乱，模板、作用域、命名空间这些语言层面的保护机制在宏面前全部失效。编译只能基于替换后的文本工作，所以宏本质上是一个绕过编译器的后门。

1.2 不进入符号表：调试器里的隐形人

符号表是编译器在语义分析阶段建立的一张“身份证登记表”，记录每个名字的类型、作用域、链接属性等信息。调试器、IDE 的智能提示、代码跳转、重命名重构，全部依赖于这张表。

宏不进入符号表。因为它根本不是语言级的名字，只是预处理器的文本替换规则。

我实际遇到的场景是：某个算法模块里定义了#define EPSILON 1e-6，运行结果差了几个百分点，我在调试器里想检查EPSILON当前的值。结果呢？调试器里根本没有这个变量。它在任何断点、监视窗口里都不会出现，因为它不是变量，甚至不是名字。我只能在源码里手动搜索1e-6被用在哪里。

如果你换成const double Epsilon = 1e-6;，调试器里可以直接看到Epsilon的类型和当前值，重命名时 IDE 也可以把所有引用点一起改掉。这种体验差异是在日常开发中真实存在的，不是“理论上更规范”这么轻飘飘。

1.3 宏的作用域失控：一次定义，全局生效

C++ 是一门有作用域的语言。{}圈出块作用域，class圈出类作用域，namespace圈出命名空间作用域。变量和函数都守规矩，在什么范围内定义就在什么范围内可见。

宏不守这个规矩。宏从定义处开始，到文件结束（或被#undef终止）为止，对之后的所有文本都生效，跟你是不是在函数内部、是不是在namespace内部毫无关系。我在一个老项目里见过这样的代码：

void doSomething() { #define LOCAL_MAGIC 5 int x = LOCAL_MAGIC; } void doOther() { int y = LOCAL_MAGIC; // 居然能编译通过！ }

LOCAL_MAGIC在doSomething内部定义，却在doOther里继续生效。这不是什么神秘机制，就是简单的文本替换。这种写法一旦被人复制、粘贴、改名，头文件里就会积累一堆“看起来只在本地用”的宏，实际影响范围却远远超出预期。

更麻烦的是命名冲突。宏的名字不会自动跟 C++ 标识符体系隔离，只要两个头文件里出现了同名的宏，include 顺序稍微一变，某个文件的编译结果就完全不同。而且是静默改变——编译器根本不知道这属于“重名冲突”，它只看见第二次#define把原来的规则覆盖了。

2. const 替代宏常量：类型、作用域与链接期差异

2.1 从最简单的常量替换开始

既然宏的问题出在“绕过编译器”，那最直接的替代方案就是把常量恢复成语言级别的实体。

// 原来 #define ASPECT_RATIO 1.653 // 替代 const double AspectRatio = 1.653;

这行改动带来几个直接收益：

第一，AspectRatio是double类型。任何地方用它，编译器都会做类型检查，把它赋给int、float时如果出现精度损失，编译器会给出告警。而宏替换后的1.653是字面量，在表达式里跟谁匹配就隐式转换，完全没有“这个常量本来的类型”这回事。

第二，AspectRatio进入符号表。调试器能看到它，报错信息会指出AspectRatio这个名字，IDE 能跳转到定义处。

第三，AspectRatio遵守作用域规则。你可以把它放在某个namespace里，或者放在函数内部，不让它污染全局。

这里有个隐藏知识点：处于命名空间作用域（也就是头文件最外面）的 const 常量默认具有内部链接。这意味着每个包含这个头文件的编译单元都会得到一份独立的AspectRatio，但它们互不冲突，也不违反“一个定义原则”。所以你把 const 常量直接写进头文件是安全的，不需要像普通全局变量那样搞extern声明确认单一实体——当然，如果你确实需要跨编译单元共享同一个地址，那就得反过来用extern const。

2.2 指针常量的写法：两个 const 一个都不能少

只替换数值常量还不够。遇到指针、字符串这类常量，很多人会写错。比如：

#define AUTHOR_NAME "Alice" // 错误写法：只保护了指针指向的内容，指针本身可变 const char* AuthorName = "Alice"; // 正确写法：内容和指针本身都是 const const char* const AuthorName = "Alice";

很多人第一次看到const char* const会觉得“这也太啰嗦了”。先解释一下：第一个const表示AuthorName指向的内容不可变——你不能通过AuthorName修改 “Alice” 这个字符串。第二个const表示指针本身不可变——你不能让AuthorName指向别的字符串。

如果只写const char*，那么代码里某处写着AuthorName = anotherName;也能编译通过。虽然不改变字符串内容，但改变了“这个模块统一使用的作者名”语义。所谓常量，就是要让编译器帮你拦住这种无意中的修改。宏的#define AUTHOR_NAME根本没有“指针对象”这个概念，它是无条件文本替换，改没改、可不可改全靠人自觉，这就很悬。

2.3 类内常量：static const int 和它的链接身世

更多的情况是，常量被定义在类内部，用于控制这个类的行为。经典的写法是这样的：

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

这里static const int NumTurns = 5;是声明，等号后面给的是初始化式。C++ 允许整型常量在类内直接初始化，只要它能在编译期求出值。scores数组需要知道元素个数，编译器把NumTurns当成编译期常量来用，没有任何问题。

但是有一个老坑：如果你在某个.cpp文件里写出了&GamePlayer::NumTurns，也就是取了NumTurns的地址，那某些编译器会要求你在实现文件里额外提供一个定义式：

const int GamePlayer::NumTurns;

这是因为“取地址”会形成对“变量实体”的引用，而类内初始化只是给编译器一个常数，不代表在目标文件里生成了真正的存储空间。C++17 之后情况变得简单了，接下来第 5 节我会具体讲。

顺带说一句，如果常量类型是浮点型、字符串、类对象，类内初始化会有更严格的限制。C++11 之后容器、字符串这类类型可以通过static const std::string加类外定义，但有些编译器对旧标准支持不好，所以老项目里才出现了如此多的宏——因为宏不需要关心这些问题。

2.4 为什么 const 替代宏能改善构建时间

还有一个很少被提及但很实用的问题：解析成本。宏在预处理阶段被展开后，后续每个引用点都要以展开后的字面量参与编译流程；而const常量本身就是一个符号，编译器处理一次定义，后续引用只是一个标识符查找。

听起来差别不大，但在一个被大量include的全工程共享头文件里，如果定义了上百个宏，每次预处理都要把每个宏的替换文本塞进所有引用方。这种成本虽然单次很小，放大到几十个编译单元、上千次引用之后，影响就不容小觑了。反正我自己在改造过一个头文件之后，整个模块的编译时间大概下降了约 10%，这算是一个意外收获。

3. 真正需要编译期常数的场景，就交给 enum

3.1 哪些代码“必须”编译期就有值

const double AspectRatio可以做常量，但它本质上仍然是一个变量，只不过初始化后不能改。当编译器在编译某个代码结构时，如果必须在编译期就知道一个数值，这时候const就不一定管用了。

典型的场景有这么几类：

• 数组的大小（老式写法int scores[NumTurns];）
• switch语句的case标签
• 位掩码，比如1 << 3
• 模板的非类型参数，例如std::array<int, N>
• static_assert里判断的编译期表达式

这些地方需要的是“编译期常量（constant expression）”，也就是编译器能在编译阶段就该算出确切数字的东西。对于一个整数类型的const int，如果初始化式是字面量，它通常也能当作编译期常量；但对于普通const double或者某些非整型，编译器就不认了。于是，在 C++11 引入constexpr之前，enum 成了类内“编译期整数常量”的事实标准。

3.2 enum hack：看起来像非正规手段，其实是老牌工程技巧

“enum hack”这个词听起来像某种 hack，实际上它是在 C++ 早期就广泛使用的技巧。写法如下：

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

这里enum { NumTurns = 5 };定义了一个匿名枚举，而NumTurns就是它的枚举器。枚举器的本质是一个编译期整数常量，它不占用变量存储，也没有传统变量的左值身份。编译器需要的是“编译期数值”，它恰好完美匹配。

更重要的是，这个匿名枚举被定义在class内部，所以NumTurns的作用域被限制在GamePlayer类里，不会像宏一样污染全局。它同时也不需要类外定义——因为它不是变量，只是一个编译期值。老标准里写static const int NumTurns = 5;后还必须记得去.cpp文件补定义，而用enum则可以永远忘记这件事。

这种技巧在早期模板元编程里尤其常见。比如用模板递归算阶乘时：

template<int N> struct Factorial { enum { value = N * Factorial<N - 1>::value }; }; template<> struct Factorial<0> { enum { value = 1 }; };

在 C++11 之前，类模板里的static const int在某些编译器上没法直接当作编译期整型常量用于依赖计算，而enum的枚举器则被广泛接受。于是大量老代码都用enum传递编译期整数，这就是 enum hack 的黄金时代。

3.3 到底该不该用 enum class 替代普通 enum

如果项目可以直接用 C++11 及以上标准，我更推荐用enum class表达业务上的枚举类型，而不再依赖匿名的 enum hack。

class GamePlayer { private: enum class State : int { NumTurns = 5 }; int scores[static_cast<int>(State::NumTurns)]; };

这里的区别很微妙。enum class的枚举器是强作用域的，必须写成State::NumTurns，而且它不会隐式转换成int，所以数组大小那里需要static_cast。好处是：不会意外地把某个枚举值当整数到处混用，类型安全更好，还能显式指定底层类型: int，避免不同编译器对枚举大小理解不一致。

但在模板元编程的老代码里，enum class由于不能隐式转int，反而会让代码变得很啰嗦。因此如果你的主要诉求只是“有一个编译期整数常量用”，传统enum依然是可接受的；如果项目现代化程度高、团队纪律好，那就直接上 C++17 的inline static constexpr，后面会讲。

3.4 使用 enum 代替宏时，需要注意的边界

enum 也不是万能药。有两点需要明确：

第一，enum 的枚举器不是对象，你不能对NumTurns取地址。这在多数场景下是优点——省去了“定义式”的麻烦。但如果代码里真的有地方需要拿常量的地址，比如要传给一个接收const int*的老式函数，那 enum 就行不通了，还是得用static const int或者constexpr。

第二，传统enum会把枚举器名字注入到外层作用域。上面例子里的匿名枚举在类内部，所以只注入到类作用域，问题不大；如果你在全局写enum { BufferSize = 1024 };，那BufferSize就会进入全局作用域，跟其他标识符冲突的风险瞬间升高。所以，要用局部 enum 就一定要放在类或者函数内部，别放到全局裸奔。

4. 宏函数的三宗罪，以及 inline 的救场方案

4.1 多重求值：一个 i++ 引发的未定义行为

宏做的第二件事是“函数式宏”，也就是用宏模拟函数调用。最经典的错误案例是：

#define SQUARE(x) ((x) * (x)) int i = 5; int result = SQUARE(i++);

预处理器把SQUARE(i++)展开成((i++) * (i++))。于是i++被执行了两次。这在同一个表达式里对同一个变量进行两次带副作用的修改，严格说是未定义行为。即使侥幸没崩，result的值也绝不会是你脑子里那个25，而是取决于编译器计算顺序的某种随机结果。

你可能会说：我从来没写过这么蠢的调用。但真实项目里，宏的调用方往往并不知道内部展开过多少次。你把一个dequeue()调用的返回值传给MAX宏，结果dequeue()被调了两次，弹出两个不同的数据，这种 Bug 极其隐蔽。宏的调用者看到的只是“调了一个函数”，实际上却遭受了副作用翻倍的伤害。这是语言级函数永远不会犯的错误——普通函数调用时，每个实参只会被求值一次。

4.2 类型不安全：宏不关心你的参数是不是一个类型

就算躲开了多重求值的坑，函数式宏还面临另一个问题：没有类型约束。

#define MAX(a, b) ((a) > (b) ? (a) : (b)) int a = 3; double b = 4.5; double result = MAX(a, b);

这个写法可以编译通过，因为a被隐式提升为double跟b比较。但这里没有任何人检查过c和b是不是同一种类型，也没人保证返回值跟参数类型一致。假如你传进去的是两个std::string对象，(a) > (b)本来也能比较，但因为宏不会构造临时对象、也不会管operator>是否是成员函数，一些更微妙的问题就暴露出来了。你只能祈祷每个调用点的类型匹配没问题。

另外，宏不重载。你不能写两个同名宏分别处理int和double。C++ 的函数重载机制在宏面前完全用不上，因为宏根本没有“函数签名”这个概念。

4.3 inline 函数：既有宏的性能，又有函数的语义

用 inline 函数替代函数式宏，是条款里最朴素的建议：

template<typename T> inline T Max(const T& a, const T& b) { return a > b ? a : b; }

inline告诉编译器：请求把函数体在调用点展开。这恰恰是宏的性能优势——没有真实的函数调用开销。但这一次它是个真正的函数，因此：

• 实参只会被求值一次，Max(i++, 5)不会出现i++执行两次的问题；
• 有类型检查和推导，传int和double时编译器会明确给出类型不匹配的告警；
• 函数有自己的作用域，可以放进class、namespace，也可以重载；
• 调试时它是一个有名有姓的实体，可以在函数入口打断点，甚至可以单步进入。

模板加上const T&是为了避免不必要的拷贝，同时保证对大对象也安全。如果只是想比较两个int，这个模板也可以实例化成int版本，性能和当年手写宏差别不大。

4.4 类内成员函数天然支持 inline

在类体内直接定义的成员函数，默认会请求inline展开。比如：

class Widget { public: int Value() const { return value_; } private: int value_ = 0; };

这个Value()就是一个隐式 inline 的成员函数。它很短、没有副作用、只是返回一个成员变量，编译器大概率会直接内联到调用处。不用写inline关键字也能享受到宏级别的访问效率。

但要注意一点：inline 只是“请求”，不是命令。递归函数、函数体过于复杂、或者编译阶段无法确定调用点信息的虚拟函数，编译器都可能拒绝展开。现代编译器在优化级别开高之后，会自行判断哪些函数值得内联，哪怕你没有写inline。所以与其迷信 inline 的性能，不如把它看成一种“允许在头文件里定义”的标记。

4.5 inline 函数为什么可以放头文件

初学者常疑惑：函数定义放在头文件，不是违反 ODR（一个定义原则）吗？

C++ 标准对 inline 函数有专门豁免：如果每个翻译单元对同名 inline 函数的定义完全一致，那么多份定义是允许的。预处理器把头文件拷贝到每个包含它的源文件里，每个源文件都有一份Max的定义，但它们内容相同，链接器就不会报“重复定义”错误。

这给了我们一个很大的便利：inline 函数可以作为“接口的一部分”随头文件发布，调用方不需要链接额外的库就能使用。这也是它替代宏的一大优势——宏无法控制访问权限、无法重载、无法放进命名空间，inline 函数却全部可以。

5. 在现代 C++ 语境下，这条条款的演进与新补充

5.1 constexpr：把编译期求值变成一等公民

C++11 之后，const 和 enum 的很多老问题有了更现代的答案：constexpr。

constexpr变量声明告诉编译器“这个值必须在编译期就能求出来”，一旦声明成立，它天然可以在任何需要编译期常量的地方使用。比如：

constexpr int NumTurns = 5; int scores[NumTurns];

这里NumTurns既是不可变常量，又是编译期值，还不需要像 enum hack 那样用一个匿名的枚举类型来包装。可读性比enum { NumTurns = 5 };高了一个档次。

C++14 进一步放宽了 constexpr 函数的限制，允许循环、局部变量、变量修改；C++20 又允许 constexpr 函数里使用 try/catch 和部分标准库容器。所以现代代码里，用 constexpr 函数替代计算型宏，是完全可行的：

// 原来的宏： #define AREA(l, w) ((l) * (w)) constexpr double Area(double l, double w) { return l * w; }

运行时和编译期都可以调用Area，参数检查、作用域控制、调试便利性全部拿到。

5.2 类内常量：C++17 的 inline static constexpr

前面提到老标准里类内static const int用完还要去.cpp补定义。C++17 带来了一个很实用的规则：静态 constexpr 成员变量隐式 inline。

也就是说，下面这样写就够了，不需要类外定义：

class GamePlayer { private: static constexpr int NumTurns = 5; int scores[NumTurns]; };

即使你去取&GamePlayer::NumTurns，编译器也不会再要求额外定义式。这基本上消灭了“类内编译期整数常量”的麻烦，也让 enum hack 在绝大多数新代码里失去了存在价值。我会建议新项目直接统一这种写法。

5.3 旧式条款的现代对照表

拿一张表来总结不同场景下的推荐演进比较直观：

这张表的目的不是制造“新写法歧视旧写法”，而是让人在写每一行代码的时候多问一句：这个东西真的需要预处理器介入吗？

5.4 宏真的就一点都不能用吗

也不是。宏仍然有不可替代的场景：include guard、条件编译、__FILE__和__LINE__的日志标注、字符串化和连接操作、配合编译器特性检测。比如：

#ifndef PROJECT_MODULE_H #define PROJECT_MODULE_H // ... #endif

这是宏的正当用途。它发生在预处理期，处理的是“编译流程控制”，而不是“业务值表达”。所以现代实践不是“彻底封杀 #define”，而是“不要把 #define 用来表达数值、字符串或函数行为”。

6. 实战改造记录：从宏泛滥到规范化的过程与坑

6.1 一份真实的代码扫描结果

我在某个通信中间件模块里做过一次集中清理。模块头文件不大，但整整堆了一排宏，大致分三类：

// 第一类：常量 #define PROTO_VER 3 #define PACKET_MAX_LEN 4096 #define LOG_LEVEL_ERR 1 // 第二类：标志位 #define FLAG_MASK (1 << 3) #define PACKET_TYPE_DATA 0x01 // 第三类：函数式宏 #define CALC_CRC(buf, len) fast_crc(buf, len)

看起来人畜无害，但PACKET_MAX_LEN被用来定义数组大小，FLAG_MASK到处做位运算，CALC_CRC被二十几个调用点使用。其中两个文件里还悄悄#undef过FLAG_MASK，只因为某个硬件驱动头文件恰好也用这个名字。

6.2 按优先级分三批改造

我没有幻想一口气全改完，而是按风险从高到低分了批。

第一批处理函数式宏，因为CALC_CRC这类调用一旦遇到副作用或者类型推导问题，运行期 Bug 最隐蔽。改成：

inline uint32_t CalcCrc(const uint8_t* buf, size_t len) { return FastCrc(buf, len); }

第二批处理常量类宏，全部换成constexpr。这里特别要注意：PACKET_MAX_LEN用在了数组定义里，必须用constexpr而不是普通const，因为数组大小要求编译期常量。普通const在大多数情况下可以，但标准上不如constexpr严格，直接用constexpr最省心。

第三批处理协议状态和标志位。PROTO_VER、PACKET_TYPE_DATA这类语义明确的状态值，改成enum class：

enum class ProtocolVersion : uint8_t { V3 = 3 }; enum class PacketType : uint8_t { Data = 0x01 };

FLAG_MASK这个位掩码比较特殊，它本身是算出来的常量表达式，我改成了constexpr uint32_t FlagMask = (1u << 3);。业务语义跟宏完全等价。

6.3 改造后踩到的新坑

替换本身不难，难的是替换之后编译器开始认真检查类型了，原本靠宏“浑水摸鱼”的地方原形毕露。

第一个坑是用enum class替换标志位宏之后，原来的if (packetType & FLAG_MASK)这种写法编译不过了。因为enum class不会隐式转成整数，位运算要求底层类型显式转换。我最后给PacketType写了重载的operator&，或者干脆在用到的地方写成：

if (static_cast<uint8_t>(packetType) & FlagMask)

第二个坑是PACKET_MAX_LEN从宏改成constexpr size_t之后，某些跟外部 C 库交互的地方要用int类型的缓冲区长度。宏替换时代，4096这个字面量在整数表达式里自动匹配到int；现在是size_t，跟 signed 类型混用就触发符号性告警。这类问题不是常量本身的问题，但要把旧代码里所有隐式转换点都检查一遍。

第三个坑是static constexpr int在类内初始化后，C++17 之前的标准如果只开 C++14，仍然要记得在.cpp文件加定义；我这次项目用的标准确实是 C++17，所以没写类外定义，编译干净通过。如果你的项目还被锁在 C++11/14，这点务必提前确认编译器行为。

6.4 代码评审：看到 #define 先问三个问题

清理旧代码是一回事，预防新代码再犯是另一回事。我在团队评审里把规矩简化成三个问题，看到任何#define都会先过一遍：

1. 这个宏是不是必须由预处理器处理？比如 include guard、条件编译、__FILE__注入这类场景。
2. 它是在表达“值”，还是在表达“函数行为”？如果是在表达值，那 const、constexpr、enum 里一定有更适合的方案。
3. 如果它定义在头文件里，有没有考虑过命名冲突、作用域污染和调试困难？有没有设计#undef策略？

我建议还可以在 CI 脚本里加一条简单的扫描规则：新提交代码中，除了 include guard 和少数白名单宏，不允许新增#define来定义常量或计算逻辑。这样规范不需要靠人肉提醒，而是在提交阶段就拦住大部分问题。

7. 个人在实际改造中的体会

如果要在最后给一条最实在的建议，那就是：不要试图一天之内把仓库里所有宏清理完。我从第一次意识到宏的危害，到真正推动某个模块完成改造，中间隔了好几个月。原因很简单——旧代码里宏的引用点太多，有些宏甚至被别的模块“秘密依赖”，一改就像抽积木，牵一发动全身。

比较稳妥的路径是：新代码从第一天开始就按 const、enum、inline 的思路来写，禁止新增“表达数值或行为”的宏；老代码按模块分批治理，优先处理高频头文件里的、被多个源文件共同引用的宏，它们往往是最容易爆发冲突的地方。每次只改一个模块，改完跑完整回归，再进入下一个模块。

另外一个实用小技巧：用grep -rn "#define"扫描仓库，把所有宏按“定义所在文件”“引用数量”“是否带参数”三个维度排序，先处理那些同时命中“头文件”“多引用点”“带参数”的宏——这三条命中的越多，风险越高。我就是靠这个排序，用很少的精力优先拆掉了项目里最危险的几十个宏，换来后面很长一段时间的清静。

说到底，条款02的核心思想不是让你记住几个代码范本，而是让你理解一件事：C++ 语言本身拥有大量表达常量和函数行为的机制，把它们用起来，编译器才能帮你发现错误。把代码的语义尽可能交还给语言，而不是扔给预处理器，这也是多年实践下来我一直坚持的习惯。