
std::move_only_function 为什么不是 std::function 的“升级版”?
它根本不是用来替代 std::function 的——两者语义不同:std::function 要求可拷贝(CopyConstructible),而 std::move_only_function 明确放弃拷贝,只保留移动。痛点不在“功能缺失”,而在“强制拷贝开销 + 类型擦除冗余”。比如你存一个只能移动的 lambda(捕获了 std::unique_ptr),用 std::function 会编译失败;退而求其次用 std::shared_ptr<:function> 又引入引用计数和堆分配——这不是零开销。
std::move_only_function 如何实现零开销抽象?
关键在实现策略:它仍做类型擦除,但不强求拷贝,因此可以省掉拷贝相关的虚函数表项、避免为支持拷贝预留额外存储空间(如某些 libstdc++ 实现中 std::function 内置小缓冲区需对齐到拷贝安全边界)。更重要的是——它允许底层直接 move-only callable 对象(如带 std::unique_ptr 捕获的 lambda)原地构造,不经过中间包装或堆分配。
-
std::function存一个捕获std::unique_ptr的 lambda → 编译错误 -
std::move_only_function存同个 lambda → 合法,且通常不触发堆分配(若满足 small-buffer 条件) - 调用开销与
std::function相当(一次虚函数调用),但构造/移动更轻量
实际使用时最容易踩的坑
不是所有 move-only callable 都能“零开销”——是否真正避免堆分配,取决于 callable 对象大小和对齐要求,以及标准库实现的小缓冲区容量(通常是 24 或 32 字节)。一旦溢出,仍会 fallback 到堆分配。
- 别假设“move-only 就一定栈上存”:检查
sizeof和你的 STL 实现文档(如 libc++ 的__small_size) - 不能传给需要
CopyConstructible的接口:例如std::thread构造函数接受右值但内部会 move,没问题;但std::vector::push_back若反复扩容,可能需要重排元素——此时若 vector 元素是std::move_only_function,则要求其可移动,而非可拷贝,这是 OK 的;但若误传给期望std::function的 API(如某些老库回调注册函数),编译直接失败 - 没有
target()或target_type():因为 move-only erase 后无法安全反向还原类型,所以运行时类型查询能力被主动舍弃
auto f = [p = std::make_unique零开销不体现在“完全没成本”,而在于它把成本控制在 move-only 语义所必需的最小集合里——不为不存在的需求(拷贝)买单,也不因规避拷贝而引入新成本(如 shared_ptr 包装)。真正难的是判断你的 callable 是否够小、是否真能避开堆。(42)]() mutable { std::cout << *p << "\n"; p = nullptr; }; std::move_only_function fn = std::move(f); // OK // std::function fn2 = std::move(f); // ERROR: copy constructor of 'f' is deleted











