C++扩展用户类时，应选择包装类实现还是继承实现？

继承方案的特点和局限性 #

优势 #

• 语法侵入性极低：wrapper实例可以直接当作T的实例使用，不需要重载operator->、operator*这类仿指针接口，天然支持多态、能直接调用T的所有公开成员，不需要额外做转发。
• 无额外内存开销：不需要额外申请堆内存存储被包装对象，直接在wrapper的内存布局内构造T的实例，性能开销和直接构造T几乎一致。

劣势 #

• 适配范围有限：被标记为final的类禁止继承、拥有私有构造函数的类无法被继承构造，这两类场景下继承方案直接失效。
• 存在隐性风险：如果用户将wrapper实例向上转为T类型并按值传递/赋值，会发生对象切片，直接切掉wrapper扩展的所有功能；如果T的析构函数不是虚函数，通过T指针释放wrapper实例会引发内存泄漏。
• 灵活性不足：只能包装由你自行构造的T实例，如果拿到的是已经构造完成的T的指针/引用，继承方案完全无法复用已有对象。
• 破坏原有设计的可能性高：如果T本身存在虚函数，继承可能意外覆盖原有虚函数逻辑，也会额外引入虚表开销；如果用户传入的T是多态基类，继承方案只能构造基类实例，无法保留派生类的额外属性和行为。

组合（包装类）方案的特点 #

优势 #

• 适配性极强：不管T是不是final类、是不是已经构造完成的实例、是基类还是派生类，都可以直接包装，没有额外限制。
• 完全解耦无侵入：包装类和被包装类的逻辑完全独立，不会修改T的内存布局，也不会引入对象切片、虚析构这类继承带来的隐性问题，对用户类的原有设计没有任何要求。
• 生命周期管控灵活：你可以根据需求选择用unique_ptr独占所有权、shared_ptr共享所有权，甚至直接存引用/裸指针借用外部对象的所有权，不需要完全绑定被包装对象的构造逻辑；如果不需要堆分配，也可以直接在包装类内存储T的栈实例，抹平性能差异。

劣势 #

• 语法有额外开销：你需要重载operator->、operator*来模拟指针行为，或者手动编写成员函数转发逻辑，部分场景下用起来没有继承方案顺滑，也无法隐式转换为T类型，需要显式调用接口获取被包装对象。
• 默认用unique_ptr实现时会有堆内存申请/释放的开销，以及缓存命中率下降的性能损耗，需要自行优化为栈存储才能对齐继承方案的性能。

选型建议 #

库开发的核心要求是兼容性和鲁棒性，包装类几乎没有使用限制，不会因为用户类的特殊设计就失效，也不会引入各类隐性问题，因此通用场景下优先选择包装类方案。

只有同时满足以下所有条件时，才考虑选择继承方案：

• 明确用户传入的T一定不是final类，且T的析构函数是虚函数，或者可以保证不会出现通过T指针释放wrapper实例的场景
• 不需要包装已有的T实例，所有被包装的T实例都由你自行构造
• 要求wrapper实例能完全替代T的实例使用，不想额外编写运算符重载或者成员转发逻辑

内容的提问来源于stack exchange，提问作者Määäxx