运行时为std::function类型类成员赋值的最优方式？

问题背景 #

我希望将签名一致的成员函数指针存储到std::function对象中。成员变量status_在初始化阶段从配置文件或CLI标志读取，此后不再变更，但对应的成员函数会被调用约1000次。目前有三种实现方案，请问哪种是给std::function类型类成员赋值的最优方式？

三种实现方案 #

方案1：使用Lambda表达式 #

// Product(int status) 构造函数中
Product::Product(int status)
{
    status_ = status ;

    if (status_ == 0) {
      jobRunner_ = [this](const ProductState& state) {this->create(state);} ;
    } else if (status_ == 1) {
      jobRunner_ = [this](const ProductState& state) {this->repair(state);} ;
    } else if (status_ == 2) {
      jobRunner_ = [this](const ProductState& state) {this->deploy(state);} ;
    }
}

void Product::runJob(const ProductState& state)
{
    jobRunner_(state) ;
}

方案2：使用std::bind与std::placeholders #

// Product(int status) 构造函数中
Product::Product(int status)
{
    status_ = status ;

    if (status_ == 0) {
      jobRunner_ = std::bind(&Product::create, this, std::placeholders::_1);
    } else if (status_ == 1) {
      jobRunner_ = std::bind(&Product::repair, this, std::placeholders::_1);
    } else if (status_ == 2) {
      jobRunner_ = std::bind(&Product::deploy, this, std::placeholders::_1);
    }
}

void Product::runJob(const ProductState& state)
{
    jobRunner_(state) ;
}

方案3：在runJob中每次判断status_ #

void Product::runJob(const ProductState& state)
{
    if (status_ == 0) {
      create(state);
    } else if (status_ == 1) {
      repair(state);
    } else if (status_ == 2) {
      deploy(state);
    }
}

方案对比与最优选择 #

方案3的劣势 #

方案3每次调用runJob都要执行分支判断，虽然1000次判断的性能开销不算特别大，但相比直接调用绑定好的函数还是有额外消耗。更关键的是，它把分支逻辑和业务执行逻辑耦合在一起，后续如果新增status取值，必须修改runJob函数，违反开闭原则，维护成本更高。

方案1与方案2的优势 #

这两个方案都在初始化阶段完成函数绑定，后续调用runJob时直接执行绑定好的逻辑，没有分支判断，性能更优，同时把分支逻辑和执行逻辑解耦，代码结构更清晰。

Lambda vs std::bind

• 可读性与简洁性：Lambda的写法更直观，闭包逻辑一目了然，不需要依赖std::placeholders，代码更简洁易读。
• 性能优化：编译器对Lambda的优化支持通常更好，Lambda的闭包类型是明确的，编译器更容易做内联等优化，减少间接调用的开销；而std::bind返回的是一个复杂的绑定对象，部分场景下优化效果不如Lambda。
• 维护性：Lambda的代码结构更直观，后续新增分支或修改逻辑时，出错概率更低。

最终结论 #

优先选择方案1（Lambda表达式），它在性能、可读性和可维护性上都表现最优。如果是维护老旧代码或团队习惯使用std::bind，方案2也可以作为替代，但Lambda是更现代、更推荐的C++写法。方案3因耦合度高、存在额外分支开销，不推荐使用。

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