第24章 constexpr与编译期计算

课程目录第24章 constexpr与编译期计算

constexpr与编译期计算：把计算塞进编译期

constexpr 这个关键字，说实话刚出来那会儿我没太当回事。觉得不就是个「加强版 const」嘛。直到有一次我在一个嵌入式项目里，需要在启动阶段就准备好一组查找表，运行时算太慢，预计算又不够灵活。嗯，那时候我才真正意识到——编译期计算，是 C++ 给性能优化开的一扇暗门。

今天我们就来聊聊这扇门怎么开，以及门后面藏着哪些好东西。

constexpr 函数：让编译器替你打工

constexpr 函数，说白了就是告诉编译器：「这个函数，你可以在编译期就给我算出来。」

我个人习惯把 constexpr 函数当作「编译期模板」来用。它不像宏那么粗暴，又比模板更直观。来看个最简单的例子：

constexpr int factorial(int n) {
    return n <= 1 ? 1 : n * factorial(n - 1);
}

// 编译期就算好了
constexpr int result = factorial(10);
// 运行时就是 3628800，没有循环开销

你想想看，如果这个 factorial 是运行时递归，每次调用都要压栈、跳转、返回。但 constexpr 版本呢？编译器直接给你展开成常量。我在项目中遇到过类似场景——一个需要计算组合数的模块，运行时算一次要几十微秒，改成 constexpr 后，直接变成零开销。

核心要点：constexpr 函数在编译期求值时，所有中间结果都是编译期常量。这意味着没有运行时栈帧、没有分支预测失败、没有缓存缺失。纯粹的数字运算。

constexpr 变量：比宏更优雅的常量

很多人喜欢用 #define 定义常量。我以前也这么干，直到被宏的副作用坑过一次——一个简单的 SQUARE(x) 宏，因为参数是表达式，展开后完全不是我想的那样。

constexpr 变量就干净多了：

constexpr double pi = 3.141592653589793;
constexpr int buffer_size = 1024 * 4;
constexpr int max_connections = 100;

这些变量在编译期就确定了值，而且有类型检查、作用域规则。比宏安全得多。我建议你在任何需要编译期常量的地方，优先用 constexpr 变量，而不是 #define 或者 enum hack。

小技巧：constexpr 变量可以用于模板非类型参数。比如 std::array<int, buffer_size>，buffer_size 必须是编译期常量。constexpr 变量完美胜任。

编译期字符串处理：别在运行时折腾字符

字符串处理往往是性能瓶颈。你想想看，每次启动都要解析配置、拼接路径、计算哈希……这些工作如果能在编译期完成，运行时直接拿结果，多爽。

C++17 之后，我们可以用 constexpr 函数处理字符串了。比如编译期计算字符串长度：

constexpr size_t strlen_constexpr(const char* str) {
    size_t len = 0;
    while (str[len] != '\0') ++len;
    return len;
}

constexpr size_t len = strlen_constexpr("Hello, World!");
// len = 13，编译期就算好了

我在项目中做过一个编译期字符串哈希的模块。当时有个需求：根据字符串键快速查找配置项。运行时哈希当然可以，但每次启动都要重新计算。改成编译期哈希后，启动时间从 200ms 降到了 5ms。嗯，你没看错。

注意：constexpr 字符串处理有一些限制。比如不能使用动态分配、不能使用 reinterpret_cast、不能调用非 constexpr 函数。但基本的字符遍历、比较、哈希，完全没问题。

编译期哈希：把查找表塞进编译期

编译期哈希，说白了就是让编译器在编译阶段就把字符串映射成整数。运行时直接拿整数做 switch-case 或者查表，比字符串比较快几个数量级。

来看一个经典的编译期 FNV-1a 哈希实现：

constexpr uint32_t fnv1a_hash(const char* str) {
    uint32_t hash = 2166136261u;
    while (*str) {
        hash ^= static_cast<uint32_t>(*str++);
        hash *= 16777619u;
    }
    return hash;
}

// 使用示例
constexpr uint32_t hash_hello = fnv1a_hash("hello");
constexpr uint32_t hash_world = fnv1a_hash("world");

// 运行时直接比较哈希值
switch (some_hash) {
    case hash_hello: /* ... */ break;
    case hash_world: /* ... */ break;
}

你想想看，如果没有编译期哈希，你需要在运行时逐个字符比较，或者用 std::unordered_map 做查找。而编译期哈希把这一切都提前到编译阶段，运行时就是一个整数比较，快得飞起。

我曾经在一个网络协议解析模块里用了这个技巧。协议头里有很多字符串字段，需要根据字段名做不同处理。用编译期哈希后，解析速度提升了 3 倍。而且代码可读性一点没降。

性能对比：

方法	运行时开销	代码可读性	灵活性
运行时字符串比较	高（逐字符比较）	中	高
std::unordered_map	中（哈希+冲突处理）	高	高
编译期哈希 + switch	极低（整数比较）	高	中（需编译期确定键）

知识体系总览

下面这张图总结了本章的核心内容。你可以把它当作一个快速索引：

避坑指南

讲几个我踩过的坑，你遇到了可以绕开走：

constexpr 函数不一定在编译期执行。 如果参数不是编译期常量，它会在运行时执行。所以别指望 constexpr 函数能自动优化所有调用。你需要确保调用时传入的是 constexpr 参数。
编译期递归深度有限制。 我记得有一次写了一个深度递归的 constexpr 函数，编译器直接报错说递归太深。不同编译器的限制不一样，GCC 默认是 512 层，Clang 是 1024 层。如果递归太深，考虑用迭代代替。
constexpr 字符串不能太长。 虽然理论上可以处理任意长度的字符串，但编译时间会暴涨。我建议把字符串长度控制在几百个字符以内，否则编译一次够你喝杯咖啡的。
调试困难。 编译期计算的代码，你没法打断点。我一般会在开发阶段先用运行时版本调试，确认逻辑正确后再改成 constexpr。

我的建议：constexpr 不是银弹。它最适合那些「输入固定、计算密集、调用频繁」的场景。如果某个计算只执行一次，或者输入变化频繁，那 constexpr 带来的收益有限，反而增加了编译时间。权衡一下，别滥用。

好了，关于 constexpr 与编译期计算，我们就聊到这里。记住一句话：能在编译期做的事，别拖到运行时。 这是 C++ 性能优化的核心思路之一。

📚 课程目录

constexpr与编译期计算：把计算塞进编译期

constexpr 函数：让编译器替你打工

constexpr 变量：比宏更优雅的常量

编译期字符串处理：别在运行时折腾字符

编译期哈希：把查找表塞进编译期

知识体系总览

避坑指南