在C++社区，PImpl（Pointer to Implementation）惯用法长期以来被视作一种“优雅的妥协”：它既能隐藏实现细节、缩短编译时间，又能维护二进制接口的稳定性。然而，这一惯用法始终伴随着手动管理裸指针、异常安全、拷贝语义等繁琐负担。随着C++26标准提案的推进，std::indirect类型的加入有望从根本上改变这一局面。
PImpl 惯用法的困境
PImpl的核心思想是将类的实现细节移入一个独立的类（Impl），主类仅持有一个指向Impl的指针。例如：
class Widget {
public:
Widget();
~Widget();
private:
struct Impl;
std::unique_ptr<Impl> pImpl;
};
尽管unique_ptr已经解决了大部分资源管理问题，但开发者仍需手动实现拷贝构造函数、拷贝赋值运算符，以及处理移动语义和异常安全。尤其当Impl类包含自定义删除器或需要深层拷贝时，代码量急剧膨胀，且极易引入缺陷。
Widget(const Widget& other)
: pImpl(other.pImpl ? std::make_unique<Impl>(*other.pImpl) : nullptr) {}
这种模式在大型项目中反复出现，成为维护负担。
std::indirect：设计思路与核心特性
C++26提案中的std::indirect是一种智能指针类型，旨在以最简方式实现“间接存储”语义。其核心设计与unique_ptr类似，但更针对PImpl场景进行了优化：
-
默认深层拷贝：与
unique_ptr的禁止拷贝不同，indirect在拷贝时自动对指向对象进行克隆（通过调用拷贝构造函数）。这种默认行为完美契合PImpl的“值语义”需求。 -
移动语义：移动操作高效转移所有权，与
unique_ptr一致。 -
异常安全保证：复制操作提供强异常安全保证，当克隆失败时，目标状态不变。
-
隐式类型推导：支持
make_indirect工厂函数，减少重复代码。
struct Widget::Impl {
std::string data;
int value;
};
Widget::Widget()
: pImpl(std::make_indirect<Impl>()) {}
在上述代码中，Widget的拷贝构造和拷贝赋值将自动触发Impl的深层拷贝，无需手动编写。
对比：indirect vs 传统PImpl
对于以下典型场景，indirect的优势尤为突出：
- 拷贝构造：传统PImpl需检查指针是否为空，并手动调用
make_unique。indirect的拷贝构造函数内置了null检查与克隆逻辑。 - 赋值操作：传统PImpl需处理自赋值、异常安全性、资源释放，而
indirect的赋值运算符已实现强安全保证。 - 成员访问：
indirect提供operator*和operator->，与unique_ptr完全一致。
当然，indirect也并非银弹。对于需要自定义删除器或非堆分配的场景，unique_ptr更灵活。indirect更适合“对象必须拥有且可复制”的典型PImpl用例。
社区反响与未来展望
C++26的std::indirect提案已在WG21（C++标准委员会）内部获得广泛关注。多位资深委员指出，该类型填补了标准库在“拥有型间接存储”方面的空白，与optional、variant等类型共同构成了现代C++更完备的类型工具箱。
不过，也有开发者担忧默认深层拷贝可能带来意外开销，尤其当Impl对象包含大型资源句柄时。对此，提案设计者回应：indirect的性能与手写PImpl几乎一致，编译器优化通常能消除不必要的拷贝；对于特殊情况，仍可配合移动语义或自定义拷贝控制。
结语
从PImpl到indirect，C++26正在以更智能的工具减轻开发者的心智负担。虽然标准落地尚需时间，但这一变革清晰地指向C++的未来：让常见的最佳实践不再是重复劳动的代名词，而是语言与库的“第一公民”。对于所有使用PImpl的开发者而言，std::indirect无疑将是一份值得期待的“官方平替”。