在C++开发中，头文件是双刃剑。一方面，头文件是接口声明的自然载体；另一方面，头文件的任何修改都会触发依赖它的所有源文件重新编译。随着项目规模扩大，这种编译依赖可能导致构建时间呈指数级增长。Pimpl（Pointer to Implementation）惯用法，也被称为“编译防火墙”或“ Cheshire Cat”技术，是解决这一问题的经典方案。
参考：https://ltglu.cn/category/sleep-psychology.html
Pimpl的核心思想极其简单：将类的实现细节隐藏在指向不完整类型的指针后面。在头文件中，类只暴露一个指向实现类的指针，以及一组公有接口。所有私有成员——无论是数据成员还是辅助函数——都被移入单独的实现类中。这样，当头文件中的公有接口保持不变时，实现类的任何修改都不会导致依赖该头文件的源文件重新编译。
这一模式的威力源于C++的编译模型。当编译器处理一个包含类定义的源文件时，它需要知道该类的完整大小，以便分配栈内存或内嵌对象。如果类包含一个指向不完整类型的指针，指针本身的大小是已知的（通常是4或8字节），因此编译器无需知道实现类的完整定义。只要头文件中不暴露实现类的细节，任何修改都被隔离在实现文件中。
参考：https://ltglu.cn/category/sleep-environment.html
Pimpl带来的好处远不止缩短编译时间。它也是信息隐藏的极致形式。传统的C++类中，私有成员虽然不能在类外访问，但它们仍然出现在头文件中，暴露了实现细节。任何阅读头文件的开发者都能看到私有成员变量和辅助函数，这在一定程度上破坏了封装性。更严重的是，私有成员的修改——即使只是重命名或改变类型——都会破坏二进制兼容性，因为类的大小和布局发生了变化。使用Pimpl后，实现细节完全从头文件中消失，只有实现文件需要关注它们。
二进制兼容性是Pimpl的另一个重要应用场景。在库开发中，维护稳定的ABI（应用程序二进制接口）至关重要。一旦一个库被发布，用户代码就依赖于该库中类的大小、成员偏移量和虚函数表布局。如果库的后续版本修改了私有成员，用户代码可能会崩溃或产生错误的结果。Pimpl将所有的变化隔离在实现类中，公有类的内存布局只有一个指针，永远不会改变。这样，库可以自由地修改实现类，添加或删除成员，甚至完全重写内部算法，而无需重新编译用户代码。
然而，Pimpl并非没有代价。最明显的代价是额外的内存开销——每个对象需要存储一个额外的指针。对于创建数百万个小对象的场景，这个开销可能不可接受。其次是访问开销——每个成员函数调用都需要通过指针间接访问实现类，这增加了指令数量，也可能影响指令缓存效率。现代编译器可以通过内联优化来减轻这一开销，但并非总是可行。
更微妙的问题在于异常安全。Pimpl惯用法通常使用std::unique_ptr来管理实现对象的生命周期。在构造过程中，如果std::unique_ptr的构造抛出异常（例如，内存分配失败），需要确保对象处于有效状态。通常的解决方案是使用两阶段构造：先构造空指针，再通过reset分配内存。但这破坏了RAII的优雅性。
复制语义也是Pimpl需要处理的问题。如果一个类是可复制的，那么当复制对象时，需要决定是浅复制（共享同一个实现对象）还是深复制（创建新的实现对象）。浅复制类似于std::shared_ptr的行为，需要引用计数；深复制则需要在拷贝构造函数中克隆实现对象。这两种选择各有优劣，开发者必须明确选择。
参考：https://ltglu.cn/category/sleep-products.html
移动语义与Pimpl的交互则更加自然。移动操作只需要转移指针的所有权，代价极低。这正是为什么Pimpl类通常支持移动构造和移动赋值，但不支持复制（或支持深复制）。
Pimpl与多态的关系值得注意。如果一个Pimpl类本身有虚函数，那么它已经有了一个虚函数表指针（vptr）。添加Pimpl指针意味着每个对象有两个指针（vptr和impl），这增加了内存开销。在某些设计中，可以考虑将虚函数也移到实现类中，让公有类成为纯粹的外壳，但这样会使公有类的接口变成转发函数，增加了代码量。
在实际工程中，Pimpl不是万能的，也不是所有类都需要它。使用Pimpl的典型场景包括：
库的公共API：需要维护二进制兼容性的库接口类。
头文件频繁变化的类：在大型团队中，减少因修改私有成员导致的级联重编译。
包含大量私有辅助函数的类：将这些函数从头文件中移出，提高封装性。
依赖于平台特定代码的类：将平台相关实现隐藏在Pimpl后面，头文件保持平台无关。
不适用Pimpl的场景包括：
性能敏感的小对象：额外的指针开销不可接受。
内联函数密集的类：Pimpl阻止了内联优化。
模板类：模板的定义通常必须在头文件中，Pimpl难以应用。
需要栈分配的类：Pimpl强制堆分配，可能影响缓存局部性。
现代C++对Pimpl的支持有所增强。std::unique_ptr可以完美管理Pimpl指针，但需要处理不完整类型的析构问题——因为std::unique_ptr的析构函数需要知道类型的完整定义。解决方案是在实现文件中显式定义析构函数，或者使用自定义删除器。std::shared_ptr没有这个问题，因为它使用类型擦除的删除器，但引用计数的开销更大。
C++20的模块（Modules）可能是Pimpl的终结者。模块从根本上改变了C++的编译模型，头文件不再需要，编译依赖大大减少。在模块系统中，私有成员可以标记为private，模块的消费者无法看到它们，也不依赖于它们。这意味着Pimpl的核心目标——隐藏实现细节和减少编译依赖——可以通过模块的原生机制实现。然而，模块的普及还需要时间，在可预见的未来，Pimpl仍将是C++开发者的重要工具。
参考：https://ltglu.cn
