在 C++11 之前，存储任意可调用对象需要原始函数指针或自定义多态基类。std::function 的引入提供了一个类型擦除的包装器，能够存储任何可调用对象，但它要求 CopyConstructible 要求，并使用小缓冲优化 (SBO) 来避免小函数对象的堆分配。随着 C++14 和 C++17 普及移动唯一类型如 std::unique_ptr，开发者遇到了 std::function 无法存储捕获唯一资源的 lambda 的限制。C++23 引入了 std::move_only_function，消除了可复制性要求，并支持仅可移动的可调用对象，同时保持 SBO 性能优势。
std::function 利用类型擦除来隐藏实际的可调用类型，通过统一接口。 当可调用对象超过内部缓冲区大小（通常为 16-32 字节）时，实施会在堆上分配存储空间。 然而，基本约束是 std::function 本身是可复制的，这要求类型擦除机制通过虚拟调度实现 "克隆" 操作。因此，存储的可调用对象必须是 CopyConstructible，排除了捕获 std::unique_ptr 或文件句柄的仅可移动 lambda。这迫使开发人员使用 std::shared_ptr（增加原子开销）或手动虚拟继承（增加间接性）。
std::move_only_function 是一个仅可移动的包装器，消除了 CopyConstructible 要求。它通过仅可移动的 vtable 模式实现类型擦除，允许存储只能被移动的可调用对象。像 std::function 一样，它采用 SBO，将小函数对象直接放置在内部存储中，无需堆分配。这使得从工厂函数返回捕获 std::unique_ptr 的 lambda 或在容器中存储独占所有权的回调成为可能，而无需虚拟调度开销。
#include <functional> #include <memory> #include <iostream> // C++23 std::move_only_function 的简化模拟 template<typename Signature> class MoveOnlyFunc; template<typename Ret, typename... Args> class MoveOnlyFunc<Ret(Args...)> { struct Concept { virtual Ret call(Args... args) = 0; virtual ~Concept() = default; }; template<typename F> struct Model : Concept { F f; Model(F&& f) : f(std::move(f)) {} Ret call(Args... args) override { return f(args...); } }; std::unique_ptr<Concept> impl; public: template<typename F> MoveOnlyFunc(F&& f) : impl(std::make_unique<Model<F>>(std::forward<F>(f))) {} MoveOnlyFunc(MoveOnlyFunc&&) = default; MoveOnlyFunc& operator=(MoveOnlyFunc&&) = default; Ret operator()(Args... args) { return impl->call(args...); } }; int main() { auto ptr = std::make_unique<int>(42); // std::function 会失败：不可复制类型的捕获 MoveOnlyFunc<void()> task = [p = std::move(ptr)] { std::cout << "值: " << *p << "\n"; }; task(); // 输出: 值: 42 }
背景: 一个高频交易 (HFT) 平台通过线程池调度系统处理市场事件。每个任务封装了一个网络套接字用于发送响应，建模为 std::unique_ptr<Socket> 以确保独占所有权和自动清理。
问题: 传统调度队列使用 std::function<void()> 进行类型擦除。当重构以通过从原始指针切换到 std::unique_ptr 现代化资源管理时，编译失败，错误指示该 lambda 是不可复制的。这阻止了迁移，因为 std::function 不能存储仅可移动的可调用对象，迫使重新考虑架构。
考虑的解决方案:
1. 将 unique_ptr 替换为 shared_ptr: 将套接字所有权转换为 std::shared_ptr 会满足 std::function 的可复制性要求。
优点: 最小的代码更改，标准 std::function 兼容性。
缺点: 原子引用计数引入微秒级延迟，在 HFT 中不可接受。语义上不正确：套接字不应在任务之间共享；所有权必须独占转移。
2. 多态任务基类: 实现一个抽象 Task 接口，具有虚拟 execute()，并在队列中存储 std::unique_ptr<Task>。
优点: 清晰的所有权语义，无需可复制性要求。
缺点: 虚拟调度开销（vtable 间接性）使每次调用增加纳秒。每个任务对象都需要堆分配，在热点路径中碎片化内存。
3. 自定义仅可移动类型擦除: 利用 std::aligned_storage 和手动 vtables 自行编写基于模板的类型擦除。
优点: 最优性能，支持仅可移动。
缺点: 易碎的实现，需小心对齐处理和析构函数管理。维护模板元编程代码的负担。
4. 采用 C++23 std::move_only_function: 升级编译器以支持 C++23，并将 std::function 替换为 std::move_only_function。
优点: 标准化解决方案，具有 SBO（小闭包无需堆），零虚拟调度开销，本机仅可移动支持。完美匹配独占所有权要求。
缺点: 需要 C++23 工具链的可用性。必须更新依赖的 API 以接受新类型。
选择的解决方案: 在确认交易公司的编译器支持 C++23 后选择了解决方案 4。迁移涉及将 std::function<void()> 更换为 std::move_only_function<void()> 在调度队列中。
结果: 系统成功处理仅可移动的套接字资源。基准测试表明任务调度延迟相比于 shared_ptr 方法减少了 15%，且由于 SBO 没有小闭包的堆分配。代码库消除了自定义类型擦除黑客，改善了可维护性。
为什么 std::function 要求可调用对象具有 CopyConstructible，即使 std::function 对象本身永远不会被复制？
候选人常常假设可复制性仅在发生复制时检查。然而，std::function 设计上是 CopyConstructible。类型擦除机制必须在其虚拟表中提供 "克隆" 操作，以支持复制包装器。如果存储的可调用对象缺少复制构造函数，则无法实现此操作，使得该类型在实例化时不兼容。 这是一个编译时约束，源自包装器的类型签名，而不是运行时检查。 标准要求可调用对象建模为 CopyConstructible 以确保类型擦除层可以满足 std::function 自身的复制语义。
Small Buffer Optimization (SBO) 在 std::function 移动期间如何与异常安全性互动？
许多候选人假设移动 std::function 是 noexcept。虽然移动包装器本身是便宜的，如果存储的可调用对象位于内部缓冲区（活动 SBO）并且其移动构造函数不是 noexcept，那么 std::function 移动构造函数可能会传播异常。这违反了容器如 std::vector 对重新分配时强异常安全性所要求的 noexcept 保证。除非所包含的可调用对象的移动是 noexcept，并且实现进行了相应优化，否则标准不保证 std::function 的 noexcept 移动。当在依赖 noexcept 移动操作以获得性能的容器中存储 std::function 对象时，这一微妙之处尤其重要。
为什么 std::function 无法将引用修饰符 (&& 或 &) 从包装的可调用对象传播到其 operator()，而 std::move_only_function 是如何解决这个问题的？
std::function 的调用运算符始终是 const 资格，并将包装器视为左值，无论可调用对象的引用资格如何。这阻止了通过包装器调用消耗资源的可调用对象（右值资格的 operator()）。 std::move_only_function 通过允许签名指定引用资格（例如，std::move_only_function<void() &&>）来解决此问题。它存储元数据或单独的虚拟表条目，以使用正确的值类别调用可调用对象，从而使得包装器的值状态能够完美转发到底层可调用对象。这使得被包装的可调用对象能够区分左值和右值调用，对于函数式管道中的移动语义至关重要。