适配器模式在c++中应通过组合+委托实现，而非继承；核心是持有被适配对象并转发调用，避免类型判断、参数硬映射和异常吞没，注意生命周期、性能及语义清晰性。
适配器模式在 C++ 里不是靠继承“实现”，而是靠组合+委托
很多人一写 Adapter 就下意识让新类继承旧接口、再重写所有函数——这其实是“伪装成适配器的重构”，容易把责任耦合死，也违背了开闭原则。真正轻量、可复用的适配器，核心是持有被适配对象（Target 或 Adaptee）的引用或指针，把调用转过去。
常见错误现象：Adapter 类里大量重复 if/else 判断类型、手动映射参数顺序、把 Adaptee 的异常直接吞掉不转换。
- 使用场景：对接老 C 风格 API（如
int do_work(const char*, size_t)）到现代 C++ 接口（std::string_view+std::expected） - 参数差异：注意 const 限定符传递（比如
Adaptee接const char*，但你传了std::string&的c_str()，得确保生命周期够长） - 性能影响：避免在
operator()或频繁调用函数里做临时std::string构造；能用std::string_view就别用std::string
std::function + lambda 是最简适配器，但别滥用
当你只需要“把一个签名转成另一个”，比如把 int(int, int) 包一层变成 double(double, double)，std::function 加 lambda 一行就能搞定，比手写类快得多。
容易踩的坑：lambda 捕获了局部变量地址，但适配器对象活得比该变量久；或者忘了加 mutable 却在捕获中修改了值。
立即学习“C++免费学习笔记（深入）”；
示例：
auto add_ints = [](int a, int b) { return a + b; };
std::function<double(double, double)> add_doubles = [add_ints](double x, double y) {
return static_cast<double>(add_ints(static_cast<int>(x), static_cast<int>(y)));
};
模板适配器要注意 SFINAE 和概念约束
泛型适配器（比如把任意 Container 适配成 Range）一旦放开模板参数，编译器可能在错误位置报一堆晦涩的 no matching function，而不是告诉你“你传的类型没 begin()”。这时候光靠 static_assert 不够，得用约束。
使用场景：封装第三方库容器（如 boost::container::static_vector）使其支持 for (auto& x : adapt(v))。
- 推荐用
requires（C++20）或std::enable_if_t（C++17）筛掉非法类型 - 别在适配器构造函数里做 heavy 初始化（比如预分配内存），用户可能只拿它来声明变量
- 兼容性影响：GCC 10+ 对
requires支持稳定；Clang 12+ 没问题；MSVC 19.29+ 才完整支持
多重继承适配器必须显式解决二义性
当你要同时适配两个有同名函数的接口（比如 Readable 和 Writable 都有 close()），用多重继承会触发编译错误：request for member ‘close’ is ambiguous。
这不是设计缺陷，是语言在提醒你：语义冲突必须人工裁定。
- 必须用作用域解析明确指定调用哪个基类的
close()，比如Readable::close() - 如果两个
close()行为本质不同（一个刷缓冲区，一个释放句柄），就别硬塞进一个类——拆成两个独立适配器更安全 - 别依赖虚继承绕过二义性，那只会把调用路径变得更不可预测
适配器最难的从来不是语法，而是判断“哪部分逻辑该由适配器承担，哪部分该推给使用者”。比如错误码转换：是统一转成 std::error_code，还是保留原始整数并提供映射表？这个边界划错，后面所有人调用时都要猜。
