在C++中，为何要使用函子（functor）实现定制点（customization point）而非普通函数？

嘿，这个问题问到点子上了！咱们先从你给出的普通函数实现定制点的代码说起，看看它藏着哪些坑，再聊聊为啥函子是更靠谱的选择。

先看你贴的这段普通函数实现定制的代码（我帮你补全了main函数方便测试）：

#include <cstdio>

namespace Lib {
void foo([[maybe_unused]] auto x) {
    std::puts("global generic version");
}
}  // namespace Lib

// user namespace
namespace X {
struct Int {
    int val;
};
void foo([[maybe_unused]] Int x) {
    std::puts("local Int version");
}
} // namespace X

int main() {
    Lib::foo(X::Int{}); // 猜猜会调用哪个？
}

运行这段代码你会发现，它输出的是global generic version，而不是用户定制的local Int version！为啥？因为你明确调用了Lib::foo，编译器只会在Lib命名空间和全局命名空间找匹配的版本，根本不会去X命名空间找X::foo——这就是普通函数做定制点第一个头疼的问题：名字查找的不确定性。

有人可能会说，那我不用Lib::foo，直接写foo(x)不就能触发ADL（参数依赖查找）找到X::foo了？但这么做又会带来新问题：如果当前调用的命名空间里也有个foo函数，就会出现重载歧义；或者如果用户没写对应的foo，编译器找不到函数，直接报错，没法优雅 fallback 到库的默认实现。

那函子为啥能解决这些问题？咱们来掰扯掰扯核心优势：

• 精准控制查找顺序：函子本质是一个类型，我们可以把定制版本的查找逻辑封装在它的operator()里。比如先检查用户是否在自己的类型命名空间里提供了定制函数，存在就调用，不存在就用库的默认实现——完全由我们自己掌控，不会出现普通函数那种“找不着”或“找错了”的情况。
• 避免重载歧义：普通函数的重载匹配规则很容易踩坑，比如用户的定制版本和库的泛型版本参数匹配度相同，编译器直接报歧义错误。而函子可以用C++20的requires表达式，或者SFINAE来精确判断，只有当用户的定制版本存在且匹配时才调用，否则用默认实现，根本不会触发歧义。
• 扩展性更强：函子是类型，我们还能支持更多定制方式，比如让用户特化函子本身，或者用标签分发来处理不同的类型场景，比普通函数的重载灵活多了。而且C++20里标准库的定制点对象（比如std::swap、std::begin）本质上就是这种函子模式，靠谱得很。

咱们把刚才的例子改成函子版试试：

#include <cstdio>
#include <utility>

namespace Lib {
// 定义定制点函子
struct Foo {
    template <typename T>
    auto operator()(T&& x) const {
        // 先尝试通过ADL查找用户的foo
        if constexpr (requires { foo(std::forward<T>(x)); }) {
            return foo(std::forward<T>(x));
        } else {
            // 找不到用户定制版本，用默认实现
            std::puts("global generic version");
        }
    }
};

// 全局的定制点对象，方便调用
inline constexpr Foo foo{};
}  // namespace Lib

namespace X {
struct Int {
    int val;
};
// 用户的定制版本
void foo(Int x) {
    std::puts("local Int version");
}
} // namespace X

int main() {
    Lib::foo(X::Int{}); // 这次会正确调用X::foo！
    Lib::foo(42);       // 调用默认版本
}

运行这段代码，就能得到我们想要的结果：传X::Int时用用户定制的版本，传其他类型用默认版本，逻辑清晰得很。

说白了，用函子做定制点，就是为了解决普通函数在名字查找、重载匹配上的各种痛点，让库的定制逻辑更可靠、更灵活，既能给用户明确的扩展方式，又能保证默认行为的稳定性。

内容来源于stack exchange