表达式模板实现中是否存在未定义行为（UB）？

开发者阿泽

2026-4-7

你的判断完全正确——这段代码确实存在未定义行为（UB），问题核心就藏在临时对象的引用生命周期管理上。我们一步步拆解来理清楚：

当你计算(x+x) + (y+y)时，会触发几个关键的执行步骤：

x+x会生成一个临时的ExprAdd<const std::vector<int>&, const std::vector<int>&>对象，同理y+y也会创建同类型的临时对象；
外层的operator+会接收这两个临时对象作为const Left&和const Right&参数，进而构造最终的ExprAdd<ExprAdd<...>, ExprAdd<...>>对象v。

这里的坑点在于C++临时对象生命周期延长的规则限制：

当临时对象被绑定到函数参数的const T&时，它的生命周期会被延长到整个函数调用期间（也就是外层operator+执行的全过程）；
但这个生命周期延长不会传递到存储该引用的对象成员。也就是说，当外层operator+执行完毕、v构造完成后，之前的两个临时ExprAdd对象会立即被销毁——而v的成员l和r持有的正是这两个已销毁对象的引用，此时这些引用就变成了悬垂引用。

当后续在main中遍历v并访问v[i]时，代码会通过这些悬垂引用尝试访问已被释放的内存，这完全符合C++标准中“未定义行为”的定义。

你可以给ExprAdd类添加一个析构函数来观察临时对象的销毁时机：

template <typename Left, typename Right>
class ExprAdd {
    // ... 原有成员 ...
    ~ExprAdd() {
        std::cout << "ExprAdd 临时对象已销毁\n";
    }
};

运行原代码后，你会发现在v构造完成之前，x+x和y+y生成的临时ExprAdd对象就已经被销毁了——这直接证明了v持有的引用早已失效。

要解决这个问题，你需要调整ExprAdd的设计，放弃持有临时对象的引用。常见的安全方案有两种：

持有值而非引用（推荐）
将ExprAdd的成员从引用改为值类型，配合移动语义减少拷贝成本。这样临时对象会被移动（而非拷贝）到ExprAdd的成员中，从根本上避免悬垂引用：
```
template <typename Left, typename Right>
class ExprAdd {
private:
    Left l;
    Right r;
public:
    ExprAdd(Left l_, Right r_) : l(std::move(l_)), r(std::move(r_)) {}
    
    size_t size() const { return l.size(); }
    auto operator[](size_t i) const { return l[i] + r[i]; }
};
```
这种方案保留了表达式模板延迟计算的核心优势，同时通过移动语义将性能损耗降到最低。
使用智能指针管理生命周期
比如用std::shared_ptr存储表达式节点，但这种方式会引入额外的内存管理开销，通常不是表达式模板场景的首选。

你的分析完全准确，原代码中v的引用指向已销毁的临时对象，后续对v的访问属于未定义行为。通过将ExprAdd的成员从引用改为值（配合移动语义），可以安全地修复问题，同时保留表达式模板的设计初衷。

内容来源于stack exchange