这样做的关键原因是 for_each () 实际上并没有假设它的第三个参数是一个函数。
它只是假设它的第三个
论证是可以的
用适当的参数调用。 A
适当定义的对象也可以
作为——而且往往比——更好
功能。例如，更容易
内联应用程序运算符
类而不是内联传递的函数
作为函数指针。
因此，函数对象经常
比普通人执行得更快
功能。一个类的对象
应用程序运营商（§11.9）是
称为类函数对象，
函子，或者简称为函数对象。
[Stroustrup，C++ 第三版，18.4-最后一段]
我一直以为操作员
( )call 就像函数调用一样
在运行时。它与什么不同
正常的函数调用？
为什么内联更容易
应用程序操作员比普通操作员
功能？
它们如何比函数更快
称呼？
一般来说，函子被传递给模板化的函数 - 如果您这样做，那么传递“真实”函数（即函数指针）或函子（即具有重载的类）并不重要operator()）。本质上，两者都有一个函数调用运算符，因此都是有效的模板参数，编译器可以为其实例化for_each模板。这意味着for_each要么用特定的实例化type函子的传递，或与特定type传递了函数指针。正是在这种专业化中，函子有可能胜过函数指针。
毕竟，如果你正在通过函数指针，那么参数的编译类型就是函数指针。如果for_each本身不是内联的，那么这个特定的for_each实例被编译为调用不透明的函数指针 - 毕竟，编译器如何内联函数指针？它只知道它的type, not which该类型的函数实际上是被传递的——至少，除非它在优化时可以使用非局部信息，而这是很难做到的。
但是，如果您通过了functor，然后该函子的编译时类型用于实例化for_each模板。这样做时，您可能会传递一个简单的非虚拟类，其中只有一个适当的实现operator()。因此，当编译器遇到调用时operator()它确切地知道意味着哪个实现 - 该函子的唯一实现 - 现在它可以内联它。
如果您的函子使用虚方法，则潜在优势就会消失。当然，函子是一个类，您可以用它来做各种其他低效的事情。但对于基本情况，这就是为什么编译器优化和内联函子调用比函数指针调用更容易的原因。
Summary
编译时函数指针无法内联for_each编译器只有类型
函数而不是函数的恒等式。相比之下，函子可以内联，因为即使编译器只有函子的类型，该类型通常足以唯一地标识函子的类型。operator() method.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
