委托构造函数必须在初始化列表中调用同名类的另一构造函数，且初始化列表中不能有其他成员初始化；被委托构造函数的初始化列表和函数体均会执行，禁止循环委托。
委托构造函数的基本写法 C++11 起支持委托构造函数，本质是一个构造函数调用同一类的另一个构造函数来复用初始化逻辑。关键点是：委托必须出现在成员初始化列表中，且不能同时在初始化列表里初始化其他成员。
常见错误是写成 this->ClassName(...) 或在函数体内调用，这会创建临时对象，不是委托；也有人误以为可以混合委托和其他成员初始化——不行，一旦用了委托，初始化列表里只能有它（C++11 规定）。
- 委托语法固定为
ClassName(...) : ClassName(other_args) { ... } - 被委托的构造函数仍会执行自己的函数体（包括可能的
return语句），但它的成员初始化列表优先于委托者的函数体执行 - 不能形成循环委托，编译器会报错，例如 A → B → A
- 委托目标可以是带默认参数的构造函数，但显式写出的实参必须匹配重载决议
class Widget {
public:
Widget(int x) : Widget(x, 0) {} // 委托给双参数版本
Widget(int x, int y) : a(x), b(y) {}
private:
int a, b;
};
委托后还能不能初始化成员？
不能。只要用了委托，初始化列表里就只能有委托调用，不能再写 a(1)、b{2} 这类成员初始化。否则编译报错：error: constructor delegation cannot have member initializers。
如果确实需要在委托基础上补充逻辑，只能把这部分挪到函数体里，比如赋值、动态分配或条件处理。但要注意：此时所有成员已经由被委托的构造函数完成初始化（含默认构造），再赋值属于二次操作，对 POD 类型无妨，对有状态的对象（如 std::vector）可能带来额外开销。
- 委托不等于跳过初始化——它只是把初始化责任转交出去
- 若被委托构造函数里没显式初始化某成员，该成员仍按常规规则处理（内置类型未定义，类类型调默认构造）
- 想避免重复赋值？把共用初始化逻辑拆进私有辅助函数，让多个构造函数都调它（注意：不能在初始化列表里调函数来初始化成员）
和默认参数相比，委托更适合什么场景？ 默认参数适合简单、正交的可选配置；委托更适合存在明显“主构造路径”、且不同构造函数之间初始化逻辑差异较大（比如涉及资源申请顺序、条件分支、异常安全要求）的情况。
例如，一个类既要支持从文件路径构造，又要支持从内存 buffer 构造，两者解析逻辑完全不同，但最终都要调用统一的 init_common() 并设置相同的状态标志——这时用两个构造函数分别实现解析，再各自委托给一个 protected 的 Widget(InternalTag, ...) 更清晰，比塞进一堆默认参数 + if 分支更易读、更易维护。
- 默认参数会让所有变体共享同一套签名，调用时容易传错位置；委托则保持各构造函数语义独立
- 委托能控制初始化顺序（比如先调基类，再委托，再执行派生类逻辑），默认参数做不到
- 调试时，委托调用栈更明确；默认参数掩盖了实际走的是哪条路径
继承体系里委托构造函数要注意什么？
派生类的委托只能指向本类的其他构造函数，不能直接委托给基类构造函数。基类初始化仍需通过初始化列表显式写出，且必须放在委托调用之前（语法上不允许委托后还写 Base(...)）。
也就是说，你不能在派生类里写 Derived() : Base(), Derived(42) {}——这是非法的。正确做法是：让某个派生类构造函数负责调基类，其他构造函数委托给它。
立即学习“C++免费学习笔记（深入）”；
- 基类构造始终优先于任何派生类委托链的执行
- 如果基类没有默认构造，所有派生类构造函数（包括被委托的那个）都必须显式调用基类构造
- 静态分析工具（如 clang-tidy）可能对深层委托链报警，建议单层委托为主，避免三层以上嵌套
