type-erased delegate 的核心约束是：调用签名必须固定，禁止依赖 rtti 或 dynamic_cast 回溯原类型，且调用开销应逼近函数指针跳转（理想为 1 层间接跳转 + 1 次 call）。
什么是 type-erased delegate 的核心约束
C++ 中实现 type-erasure 委托，本质是把任意可调用对象（std::function 风格）封装成统一接口，但不依赖 std::function —— 比如你要控制内存布局、避免堆分配、或嵌入到无异常/无 RTTI 环境。关键约束有三个：
- 调用签名固定（例如
void()或int(int)），类型擦除只针对“可调用对象的类型”，不擦除签名 - 不允许虚函数表以外的运行时多态（即不能靠
dynamic_cast或typeid回溯原类型） - 调用开销应尽量接近函数指针跳转（理想是 1 层间接跳转 + 1 次 call）
如何手写 minimal delegate 支持 void() 签名
最简可行版本只需两个核心组件：一个存储“调用者”的函数指针（invoke_fn），和一个能容纳小对象的缓冲区（storage）。不使用虚函数，改用函数指针表 + 手动 placement-new：
struct delegate_void {
using invoke_fn = void(*)(const void*); // 统一调用入口
<pre class="brush:php;toolbar:false;">alignas(max_align_t) char storage[32]; // 小对象优化缓冲
invoke_fn fn;
template<typename f>
delegate_void(F&& f) : fn(&trampoline<F>) {
new (storage) std::decay_t<f>(std::forward<F>(f));
}
void operator()() const { fn(storage); }</f></typename>private:
template
注意点：
-
storage大小必须 ≥sizeof(F)且对齐足够；超出就崩溃（可加static_assert(sizeof(F) ） - 析构没处理 —— 这是典型坑：若
F有非平凡析构函数，必须额外存一个destroy_fn并在 delegate 析构时调用 -
trampoline是关键：它把泛型调用转换为固定签名，避免模板爆炸
支持带参数和返回值的签名（如 int(int)）
签名变化只影响 trampoline 和 operator()，存储和调度逻辑不变。以 int(int) 为例：
struct delegate_int_int {
using invoke_fn = int(*)(const void*, int);
alignas(max_align_t) char storage[32];
invoke_fn fn;
<pre class="brush:php;toolbar:false;">template<typename f>
delegate_int_int(F&& f) : fn(&trampoline<F>) {
new (storage) std::decay_t<f>(std::forward<F>(f));
}
int operator()(int x) const { return fn(storage, x); }</f></typename>private:
template
常见错误现象：
- 忘记把
trampoline声明为static→ 编译失败（非静态成员函数不能转函数指针） - 参数类型未完全匹配（比如传
const int&却声明为int）→ 调用时静默截断或未定义行为 - 返回类型不是 trivially copyable（如含引用、非 POD 类）→
return语句可能触发隐式拷贝构造，而 trampoline 没预留空间
为什么不用 std::function？哪些场景必须手写
std::function 默认使用堆分配（即使小对象优化开启，部分标准库实现仍会分配），且强制要求可复制（CopyConstructible）。手写 delegate 的刚性需求包括：
- 嵌入式环境禁用
new/malloc，必须栈/静态分配 - 对象生命周期由外部严格管理（比如绑定到某个 event loop 的 lifetime，不允许 delegate 自行析构捕获对象）
- 需要 zero-cost 绑定到成员函数（
std::function包装&T::f时会额外存this指针，而手写可直接用reinterpret_cast把成员函数指针转为普通函数指针——仅限标准布局类） - 要求
noexcept保证（std::function::operator()不是noexcept，因内部可能抛bad_function_call）
真正难的是析构安全和完美转发支持——这两块一旦漏掉，就不是“通用”，而是“脆弱封装”。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
