在虚函数、函数指针和函子之间进行选择

Question

我正在编写一个类，其中函数的实现之一取决于用户。目前，我将其作为虚拟函数，用户需要重写我的类才能提供其实现。我正在考虑将其设为仿函数(boost::function)/function_pointer，以便用户可以注册它。 应用程序的性能极其关键，速度比类看起来漂亮更重要。更改为函子是否会带来一些性能优势？

在大多数情况下，它将是一个自由函数，因此函数指针应该没问题。但我想在某些情况下可能需要状态，因此它需要是一个函子。

通过允许注册 function_ptr 或仿函数并根据某个 bool 调用适当的函数，我会获得任何性能优势吗？与此类似的东西。

class Myclass
{
   public:
    registerFuncPtr(FuncPtrSignature);
    registerFunctor(boost::function func);
   private:    
   someMethod(someArgs)
   {
    ...
    if(_isFuncPtr)
        _func_ptr(args);
    else
        _functor(args);
    ...
   }
   bool _isFuncPtr;
   FuncptrSignature _func_ptr;
   boost::function _functor;
}

更新：

我正在编写一个共享库，客户端将动态链接到它。 没有 C++0x。 :(

Answer 1

这取决于您的特定用例以及用户添加代码的方式。以下是纯粹的理论分析，但您应该在实际决定之前构建一个现实的场景并测试性能。

如果要在编译时添加代码（即您向用户提供代码，他们创建逻辑并将所有内容一起编译），那么最好的方法可能是提供一个采用 Functor 的模板类型参数。

template <typename Functor> void doProcessing( Functor f) {
   f( data ); 
}

优点是编译器可以访问整个代码，这意味着它可以就是否内联代码做出最佳决策，并且在内联的情况下可能能够进一步优化。缺点是您需要使用每个新逻辑片段重新编译程序，并且必须将产品与用户扩展一起编译，但很多时候这是不可能的。

如果要在主产品编译之后执行扩展，即客户可以生成自己的扩展并将其用于编译后的可执行文件（例如插件），那么您应该考虑替代方案：

• 接受函数指针（C 方式）

• 提供仅具有该操作的接口（基类）（Java 方式）

• 使用执行类型擦除的函子包装器 (boost::function/std::function)

这些是按纯粹性能排序的。 C 方式的成本是三种方式中较小的一个，但在大多数情况下与接口选项的差异可以忽略不计（每个函数调用有一个额外的间接），并且它为您提供了在调用对象中保留状态的选项（这将有通过第一个选项中的全局状态来完成）。

第三个选项是最通用的，因为它将类型擦除应用于用户可调用，并允许用户通过使用重用其现有代码函数适配器，例如 boost::bind 或 std::bind 以及 lambda（如果编译器支持）。这是最通用的，给用户留下了最多的选择。不过，它有一个相关的成本：类型擦除中有一个虚拟调度，加上对实际代码段的附加函数调用。

请注意，如果用户必须编写一个函数来使您的界面与他们的代码相适应，那么手动制作的适配器的成本很可能是相同的，因此如果他们需要通用性，那么 boost::function/std::function 是正确的方法。

至于替代方案的成本差异，它们总体上很可能非常，并且刮擦一两个操作是否重要将取决于循环的紧密程度以及用户代码的昂贵程度。如果用户代码需要执行数百条指令，那么不使用最通用的解决方案可能没有意义。如果循环每秒运行几千次，那么划几条指令也不会产生任何影响。返回，编写一个现实场景并进行测试，并在测试时了解对用户真正重要的内容。在需要几分钟的操作中浪费几秒钟的时间是不值得的，因为这样会失去更高级别解决方案的灵活性。

Answer 2

如果您追求性能，请使用裸函数指针。如果您需要状态，请在函数中提供一个 void* 类型的单独状态参数，并让用户注册其状态。没有任何魔法可以使任何 C++ 构造比这更快，因为函子和虚函数以及所有其他函数都只是包装在或多或少类型安全信封中的函数指针。

更重要的是，在谈论优化时，除了分析器之外，您不应该相信任何东西（顺便说一句，这包括上面的段落）。

内联理论上可以提高性能，但用户的函数无法内联（编译器无法内联尚未编写的代码）。如果您不编译库，而是将其作为源代码分发，则内联可能会带来一些性能优势。与往常一样，只有分析器才能判断。

函数对象可能优于函数指针的一种情况是将它们传递给函数模板。如果模板本身没有内联，则函数对象可能会在模板实例化内部内联，而函数指针则不会。

Answer 3

编译器可以轻松地内联 Functor 调用，而不是通过函数指针调用函数，所以是的，更喜欢 Functor 而不是函数指针。