编译期函数式编程：constexpr Lambda、模板元编程与函数式

说实话，很多人一听到「模板元编程」就头大。我当年也是。

但后来我发现，当你把函数式编程的思想带到编译期，事情反而变得清晰了。constexpr Lambda 的出现，更是让这条路好走了不少。

为什么要在编译期做函数式？

你想想看，运行时能做的事，编译期也能做，那干嘛不提前做完？

• 性能：编译期算完，运行时零开销
• 安全：类型错误在编译期就暴露，不会拖到线上崩溃
• 表达力：用函数式的思路写模板，代码更简洁

我在项目中遇到过几次运行时性能瓶颈，最后发现都是可以在编译期算完的东西。嗯，从那以后我对 constexpr 就格外上心。

constexpr Lambda：编译期的「小函数」

C++17 开始，Lambda 可以声明为 constexpr。说白了，就是你的 Lambda 可以在编译期执行。

// C++17 编译期 Lambda
constexpr auto square = [](int x) constexpr { return x * x; };

// 编译期就计算好了
constexpr int result = square(5);  // result = 25

我个人习惯把这种小 Lambda 写在 constexpr 变量里，当做一个编译期的「函数对象」来用。你想想看，这比写一个完整的模板函数要轻量得多。

模板元编程：老派但强大

模板元编程（TMP）是 C++ 的「黑魔法」。它利用模板特化、递归实例化，在编译期完成计算。

// 编译期阶乘
template <int N>
struct Factorial {
    static constexpr int value = N * Factorial<N - 1>::value;
};

template <>
struct Factorial<0> {
    static constexpr int value = 1;
};

// 使用
constexpr int fact5 = Factorial<5>::value;  // 120

我曾经在代码里看到过七八层嵌套的模板元编程，说实话，可读性很差。但它的确能解决一些运行时无法解决的问题，比如类型萃取、编译期分支选择。

函数式思想 + 模板元编程 = 优雅

把函数式的「高阶函数」「不可变性」「递归」带到模板元编程里，你会发现代码变得更容易理解。

// 编译期 map：对类型列表做变换
template <typename T>
struct AddPointer {
    using type = T*;
};

template <typename... Ts>
struct TypeList {};

// 编译期 transform
template <typename List, template <typename> class F>
struct Transform;

template <typename... Ts, template <typename> class F>
struct Transform<TypeList<Ts...>, F> {
    using type = TypeList<typename F<Ts>::type...>;
};

// 使用
using Original = TypeList<int, double, char>;
using Pointed = Transform<Original, AddPointer>::type;
// 结果：TypeList<int*, double*, char*>

你看，这其实就是函数式编程里的 map 操作。只不过它发生在编译期，操作的是类型而不是值。

constexpr Lambda + 模板元编程：最佳组合

C++20 进一步放宽了 constexpr 的限制。现在你可以在模板元编程里用 constexpr Lambda 来写更灵活的编译期逻辑。

// 编译期 filter：用 Lambda 做条件判断
template <typename T, auto Pred>
struct Filter;

template <typename T, auto Pred>
    requires (Pred(T{}))
struct Filter<T, Pred> {
    using type = T;
};

// 使用 constexpr Lambda 作为谓词
constexpr auto is_integral = []<typename T>() {
    return std::is_integral_v<T>;
};

// 配合类型列表使用（简化示例）
// 实际需要更复杂的递归实现

避坑指南

我曾经在编译期递归里忘记写终止条件，结果编译器直接爆了上千行的错误信息。嗯，从那以后我每次写模板递归都会先检查特化版本。

• 递归深度：编译器对模板递归深度有限制（通常 256 或 512 层），别写太深
• 编译时间：复杂的编译期计算会显著增加编译时间，注意权衡
• 可读性：能用 constexpr 函数解决的问题，就别用模板元编程

知识体系总览

下面这张图展示了编译期函数式编程的核心脉络：

实际应用场景

场景	推荐方案	说明
编译期数值计算	constexpr 函数 + Lambda	简单直观，适合数学运算
类型变换	模板元编程 + 函数式组合	处理类型列表、类型萃取
编译期策略选择	constexpr Lambda + if constexpr	根据类型或条件选择不同实现
DSL 构建	三者结合	构建类型安全的领域特定语言

我个人在实际项目中用得最多的是「编译期策略选择」。比如根据不同的平台或配置，在编译期就决定使用哪种算法实现。这样既保证了性能，又保持了代码的整洁。

公众号:蓝海资料掘金营，微信deep3321