PIMPL是通过将私有成员封装到源文件定义的Impl类中，并用std::unique_ptr持有其前向声明指针，实现接口与实现分离；它隐藏实现细节是因为头文件无需包含Impl定义及依赖，避免暴露数据布局、类型和头文件依赖，从而降低编译耦合、稳定ABI并增强封装性。
什么是PIMPL，为什么它能隐藏实现
PIMPL（Pointer to IMPLementation）本质就是把类的私有成员变量全塞进一个独立的、只在源文件里定义的结构体里，再用 std::unique_ptr 或裸指针持有它。头文件里只留个前向声明和指针，编译器就看不到私有数据布局、不依赖私有类型定义、也不用暴露 #include 依赖——接口和实现彻底解耦。
典型收益：修改私有成员（比如加个 std::vector 或换用 std::unordered_map）不会触发所有包含该头文件的源文件重编译；第三方无法通过内存布局或 sizeof 推断内部细节。
怎么写 PIMPL 类（以 Widget 为例）
头文件 widget.h 只做最小声明：
class Widget {
public:
Widget();
~Widget();
Widget(const Widget&);
Widget& operator=(const Widget&);
void do_something();
private:
class Impl; // 前向声明，不定义
std::unique_ptr<Impl> pimpl_;
};
源文件 widget.cpp 才真正定义 Impl 和所有函数实现：
立即学习“C++免费学习笔记（深入）”；
class Widget::Impl {
public:
int counter_ = 0;
std::string name_;
std::vector<double> data_;
};
Widget::Widget() : pimpl_(std::make_unique<Impl>()) {}
Widget::~Widget() = default; // unique_ptr 自动析构，但析构函数必须在此定义（见下条）
Widget::Widget(const Widget& other)
: pimpl_(std::make_unique<Impl>(*other.pimpl_)) {}
Widget& Widget::operator=(const Widget& other) {
if (this != &other) *pimpl_ = *other.pimpl_;
return *this;
}
void Widget::do_something() { pimpl_->counter_++; }
关键点：
-
~Widget()必须在.cpp里定义（哪怕写成= default），否则编译器在头文件里实例化时，看不到Impl定义，无法生成正确的析构逻辑 - 拷贝构造和赋值也要显式定义，否则默认行为只浅拷贝
pimpl_指针，导致双重释放 - 别用裸指针——除非你手动管理生命周期，否则极易泄漏或悬空
常见错误：隐式生成的特殊成员函数搞崩 PIMPL
最常踩的坑是忘了显式定义或 =default 拷贝/移动操作符，结果编译器自动生成的版本直接按位拷贝 pimpl_，两个对象指向同一块 Impl 内存，析构时 crash。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
正确做法（在 widget.h 中）：
class Widget {
public:
Widget();
~Widget(); // 必须在 .cpp 里定义
Widget(const Widget&); // 显式声明
Widget& operator=(const Widget&);
Widget(Widget&&) noexcept; // 若支持移动，也得声明
Widget& operator=(Widget&&) noexcept;
// …
};
然后在 .cpp 里全部实现（或 =default）。不声明就用默认行为？不行——std::unique_ptr 的拷贝被禁用了，编译直接报错：use of deleted function ‘std::unique_ptr<...>::unique_ptr(const std::unique_ptr<...>&)’。
性能与取舍：PIMPL 不是银弹
每次访问私有成员都要多一次指针解引用，对高频调用函数（比如内联的 getter）会有微小开销；额外堆分配一次 Impl 对象，也有内存和分配器调用成本。
所以它适合：
- 公开 SDK 或稳定 ABI 的库接口（如 Qt 的
QFile、QString） - 类私有实现频繁变动，且头文件被大量包含
- 需要严格控制头文件依赖爆炸（比如避免把
<boost/filesystem.hpp>暴露给用户）
不适合：
- 极轻量级结构体（比如只有两个
int成员） - 要求零开销抽象、且所有使用方都可控的内部模块
- 需要
std::is_trivially_copyable的场景（PIMPL 后肯定不是）
真正难的不是写出来，而是判断“这里到底值不值得加一层 indirection”——很多团队加了 PIMPL 却从不改 Impl，纯属自我感动。
