17、编译期单位换算：物理单位库（如米、秒、千克）的维度分析

物理单位换算，说白了就是让编译器帮你检查「米加秒」这种荒唐事。

我记得刚入行那会儿，写过一个航天器轨道计算模块。代码跑起来没问题，结果卫星入轨偏差了十几公里。查了三天，最后发现是一个函数把「米每秒」当成了「千米每小时」在用。嗯，从那以后，我对物理单位库就有了执念。

为什么要在编译期做维度分析？

运行时检查单位？太慢了。而且很多错误根本活不到运行时——你写代码的时候就应该被揪出来。

举个例子：

auto distance = 100.0_m;      // 100米
auto time    = 9.58_s;        // 9.58秒
auto speed   = distance / time;  // 单位：米/秒

auto wrong = distance + time;  // 编译器就该报错！

你想想看，如果编译器能在编译期就识别出「米+秒」是非法操作，那得省多少调试时间。

维度分析的核心思想

物理单位本质上是一个维度向量。比如：

• 长度 L：维度向量 (1, 0, 0)
• 质量 M：维度向量 (0, 1, 0)
• 时间 T：维度向量 (0, 0, 1)
• 速度 L/T：维度向量 (1, 0, -1)
• 加速度 L/T²：维度向量 (1, 0, -2)
• 力 M·L/T²：维度向量 (1, 1, -2)

乘除运算就是维度向量的加减。乘法对应加法，除法对应减法。就这么简单。

模板元编程实现维度类型

我个人习惯用 std::ratio 来表示维度指数。为什么？因为它本身就是编译期有理数，加减乘除都有现成的元函数。

// 维度类型：长度^L * 质量^M * 时间^T
template <int L, int M, int T>
struct Dimension {
    using type = Dimension<L, M, T>;
};

// 基本单位
using Length   = Dimension<1, 0, 0>;
using Mass     = Dimension<0, 1, 0>;
using Time     = Dimension<0, 0, 1>;

// 导出单位
using Velocity = Dimension<1, 0, -1>;  // L/T
using Force    = Dimension<1, 1, -2>;  // M·L/T²

然后定义数值类型，把值和维度绑在一起：

template <typename T, typename Dim>
class Quantity {
    T value_;
public:
    explicit constexpr Quantity(T v) : value_(v) {}

    constexpr T value() const { return value_; }

    // 同类单位可以加减
    template <typename U>
    friend constexpr auto operator+(
        const Quantity& a, 
        const Quantity<U, Dim>& b
    ) -> Quantity<decltype(T{} + U{}), Dim> {
        return Quantity<decltype(T{} + U{}), Dim>{
            a.value_ + b.value_
        };
    }

    // 不同维度用乘除
    template <typename U, typename Dim2>
    friend constexpr auto operator*(
        const Quantity& a,
        const Quantity<U, Dim2>& b
    ) -> Quantity<decltype(T{} * U{}), 
                  Dimension<Dim::L + Dim2::L, 
                           Dim::M + Dim2::M,
                           Dim::T + Dim2::T>> {
        return {
            a.value_ * b.value_
        };
    }
};

用户定义字面量：让代码更自然

光有模板还不够，写起来太啰嗦。我们需要用户定义字面量：

constexpr auto operator""_m(long double v) {
    return Quantity<long double, Length>{static_cast<long double>(v)};
}

constexpr auto operator""_s(long double v) {
    return Quantity<long double, Time>{static_cast<long double>(v)};
}

constexpr auto operator""_kg(long double v) {
    return Quantity<long double, Mass>{static_cast<long double>(v)};
}

现在代码就清爽多了：

constexpr auto dist = 100.0_m;
constexpr auto t    = 9.58_s;
constexpr auto v    = dist / t;  // 编译期计算速度

// v 的类型是 Quantity<long double, Dimension<1, 0, -1>>
// 也就是 米/秒

维度检查：编译期的守护神

最精彩的部分来了——让编译器在单位不匹配时报错：

// 只有相同维度才能相加
template <typename T, typename U, typename Dim>
constexpr auto operator+(
    const Quantity<T, Dim>& a,
    const Quantity<U, Dim>& b
) {
    return Quantity<decltype(T{} + U{}), Dim>{a.value() + b.value()};
}

// 不同维度相加？编译错误！
// auto bad = 100.0_m + 9.58_s;  // ❌ 编译失败

我在项目中遇到过一种情况：有人把牛顿和千克力混用了。这两个都是力的单位，但维度不同（牛顿是 kg·m/s²，千克力是 kg·g）。如果不用维度分析，这种错误藏得很深。用了模板元编程，编译器直接告诉你「维度不匹配」，省心多了。

更复杂的场景：复合单位

实际工程中，单位往往不是简单的 L、M、T。比如：

• 压强：Pa = N/m² = kg/(m·s²) → 维度 (-1, 1, -2)
• 能量：J = N·m = kg·m²/s² → 维度 (2, 1, -2)
• 功率：W = J/s = kg·m²/s³ → 维度 (2, 1, -3)

用我们的模板系统，这些都可以自动推导：

constexpr auto force   = 10.0_N;   // 10牛顿
constexpr auto area    = 2.0_m²;   // 2平方米
constexpr auto pressure = force / area;  
// 自动得到 Pa，维度 (-1, 1, -2)

constexpr auto mass   = 5.0_kg;
constexpr auto g      = 9.8_m_s²;  // 重力加速度
constexpr auto weight = mass * g;  
// 自动得到 N，维度 (1, 1, -2)

性能：零开销抽象

你可能会担心：这么多模板，会不会让程序变慢？

完全不会。所有维度计算都在编译期完成。生成的机器码和手写裸数值一模一样。我做过 benchmark，开启 -O2 优化后，Quantity 类型和原生 double 的性能完全一致。

这就是模板元编程的魅力——在编译期付出代价，在运行期享受零开销。

知识体系总览

下面这张图总结了编译期单位换算的核心逻辑：

实际项目中的注意事项

我在几个工业级项目里用过这套方案，总结几点经验：

1. 不要过度设计：大部分场景只需要 3-5 个基本维度。搞个 7 维 SI 单位制反而让代码难用。
2. 小心浮点精度：编译期计算用的是 constexpr，浮点运算在不同编译器下可能有细微差异。关键计算建议用有理数。
3. 错误信息可读性：模板报错信息又臭又长。可以用 static_assert 加自定义消息来改善。
4. 考虑运行时单位转换：编译期只能处理同类单位。不同量纲的转换（比如米和英尺）需要运行时乘换算系数。

编译期单位换算，说白了就是让编译器替你盯着物理单位。你只管写业务逻辑，单位对不对、能不能加减，编译器会告诉你。这种「把错误扼杀在编译期」的思路，正是模板元编程最迷人的地方。

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