C++中如何向函数传递原子布尔表达式动态求值结果的引用

我有一个函数声明如下：

int f(std::atomic<bool>& flag);

这个函数的作用是检查flag的值，而flag是一个会被其他线程修改的std::atomic<bool>变量。当直接传递单个原子变量引用（比如f(m_flag1);）时，函数能正常感知其他线程对flag的修改，运行符合预期。

现在我需要实现更复杂的逻辑：不是传递单个std::atomic<bool>的引用，而是要把m_flag1 && m_flag2这个表达式的动态求值结果传递给f。但我遇到了两个问题：

• 如果先求值一次赋值给原子变量：std::atomic<bool> x = m_flag1 && m_flag2; f(x);，x只会被初始化一次，不会随着m_flag1和m_flag2的变化更新，导致f无法获取最新的结果。
• 直接传递表达式本身会生成临时值，不仅临时值在调用结束后就销毁，而且右值无法绑定到f要求的左值引用，这种方式根本行不通。

请问有没有简洁的实现方式？是否必须开另一个线程持续执行x = m_flag1 && m_flag2;的赋值操作，还是有更优的解决方案？

完全不需要额外开线程，有两种更优雅的方案可以解决这个问题：

方案1：自定义“动态计算的原子布尔”包装类 #

我们可以创建一个类，对外表现得像std::atomic<bool>，但每次获取值时都会重新计算m_flag1 && m_flag2的结果。这样函数f不需要修改，只需要传递这个包装类的引用即可：

class DynamicAndFlag {
private:
    std::atomic<bool>& flag1;
    std::atomic<bool>& flag2;
public:
    DynamicAndFlag(std::atomic<bool>& f1, std::atomic<bool>& f2) : flag1(f1), flag2(f2) {}

    // 模拟std::atomic<bool>的load方法，每次调用都重新计算
    bool load(std::memory_order order = std::memory_order_seq_cst) const {
        // 按原子方式加载两个flag的值，返回逻辑与结果
        return flag1.load(order) && flag2.load(order);
    }

    // 支持隐式转换为bool，适配原有f函数的使用习惯
    operator bool() const {
        return load();
    }

    // 如果f会调用store()等修改方法，按需处理（比如抛出异常，因为组合值是只读的）
    void store(bool, std::memory_order = std::memory_order_seq_cst) {
        throw std::logic_error("Cannot store to dynamic computed flag");
    }
};

使用示例：

DynamicAndFlag combined_flag(m_flag1, m_flag2);
f(reinterpret_cast<std::atomic<bool>&>(combined_flag));

⚠️ 注意：这种类型转换需要确保DynamicAndFlag的接口和f实际调用的std::atomic<bool>接口兼容。如果f只调用load()或隐式转换为bool，这个方案完全可行；如果f会修改flag，该方案不适用。

方案2：修改函数f的签名，接受可调用对象 #

如果允许修改f的定义，这是更安全、更符合C++风格的方案。把f改成接受一个返回bool的可调用对象，每次需要检查值时都会重新计算表达式：

// 修改后的f函数
template<typename Checker>
int f(Checker checker) {
    // 原来的逻辑中，每次需要获取flag值时调用checker()即可
    while (!checker()) {
        // 原有的等待/处理逻辑
    }
    // ... 其他业务逻辑
}

调用时直接传递lambda表达式：

f([&]() { return m_flag1.load() && m_flag2.load(); });

这个方案类型安全，不需要强制转换，还非常灵活——不仅能处理&&的场景，任何动态计算的布尔条件都可以传递。如果f的逻辑复杂，只需要把原来获取flag值的地方替换为checker()调用即可。

为什么不推荐开额外线程？ #

开线程持续更新中间原子变量确实能解决问题，但存在明显缺点：

• 额外线程会占用系统资源，增加上下文切换开销。
• 需要处理线程生命周期（比如何时停止），增加代码复杂度。
• 中间变量的更新频率难控制：太频繁浪费CPU，太不及时则f无法获取最新值。

所以上面两种方案都比开线程更优，优先推荐方案2；如果无法修改f的定义，再考虑方案1。

内容的提问来源于stack exchange，提问作者godo