我正在阅读Herb Sutter所著的书《Exceptional C++》，在这本书中我学习到了PIMPL惯用语法。基本上，这个想法是为一个类的私有对象创建一个结构，并动态地分配它们，以减少编译时间（同时更好地隐藏私有实现）。
例如：
class X
{
private:
C c;
D d;
} ;
可以改为：
class X
{
private:
struct XImpl;
XImpl* pImpl;
};
同时，在 .cpp 文件中，有如下定义：
struct X::XImpl
{
C c;
D d;
};
这听起来很有趣，但我以前从未见过这种方法，无论是在我工作的公司还是在我看到源代码的开源项目中都没有出现过。因此，我想知道这种技术是否真的被实际应用。
我应该到处使用它，还是谨慎使用？这种技术是否建议在嵌入式系统中使用（性能非常重要的地方）？
那取决于您的目标设备有多强大。然而，对于这个问题唯一的答案是：衡量和评估您的收益和损失。此外，请注意，如果您不是发布供客户在嵌入式系统中使用的库，则仅适用于编译时间优势！在嵌入式系统中（性能非常重要），是否建议使用此技术？
似乎许多库在API的稳定性方面使用它，至少在某些版本中是这样。
但正如所有的事情一样，在不加注意地到处使用之前，你应该谨慎。在使用之前要先思考，评估它给你带来了什么优势，以及它是否值得你付出的代价。
它可能会给您带来以下优势：
那些可能对你有用，也可能没有。就像对我来说，我并不关心几分钟的重新编译时间。最终用户通常也不关心，因为他们只需要从一开始编译一次即可。
可能的缺点是（同样也要根据实现和它是否对你产生真正的不利影响）：
因此，仔细给所有事情评估一个价值，并为自己进行评估。对我来说，几乎总是证明使用PIMPL惯用语不值得努力。只有一种情况，我个人会使用它（或至少类似的东西）：
我的C++封装器用于Linuxstat调用。这里C头文件中的结构体可能不同，这取决于设置了哪些#defines。由于我的封装器头文件无法控制所有这些内容，我只在我的.cxx文件中#include <sys/stat.h>并避免这些问题。
File类（在Unix下公开大部分stat返回的信息）在Windows和Unix下使用相同的接口。 - James Kanze#ifdef语句，使得包装器尽可能薄。但每个人的目标不同，重要的是要花时间去思考，而不是盲目地跟随某些东西。 - PlasmaHH我同意其他人对商品的看法，但是我要提出一个限制：与模板不兼容。
原因是模板实例化需要可用于实例化位置的完整声明。(这也是为什么你不会看到将模板方法定义在.cpp文件中的主要原因。)
虽然你仍然可以引用泛化子类，但由于必须包含它们，编译时避免在所有平台特定代码中包含所有内容，并缩短编译的优势的"实现解耦"消失了。
这是经典面向对象编程 (基于继承) 的良好范例，但不适用于泛型编程（基于特化）。
其他人已经提供了技术上的利弊，但我认为以下值得注意：
首先，不要教条地看待问题。如果PIMPL适用于你的情况，就使用它 - 不要仅仅因为“它更好的面向对象，因为它真正隐藏了实现”，等等。引用C++ FAQ的话：
封装是为了代码，而不是为了人（source）
举个例子，开源软件OpenThreads，这是OpenSceneGraph使用的线程库。主要思想是从头文件（例如<Thread.h>）中移除所有特定于平台的代码，因为内部状态变量（例如线程句柄）在不同平台上有所不同。这样一来，可以在不了解其他平台特殊性的情况下编译代码与你的库进行交互，因为一切都被隐藏起来。
我主要考虑将PIMPL用于作为其他模块使用的API类。这样做有很多好处，因为它可以使PIMPL实现中所做的更改的重新编译不会影响项目的其余部分。此外，对于API类，它们提供了二进制兼容性（模块实现的更改不会影响那些模块的客户端，因为新实现具有相同的二进制接口-由PIMPL公开的接口）。
至于将PIMPL用于每个类，我会谨慎考虑，因为所有这些好处都是有代价的：需要额外的间接层才能访问实现方法。
我认为这是解耦最基本的工具之一。
在嵌入式项目（机顶盒）中，我使用了 PIMPL（以及 Exceptional C++ 中的许多其他惯用语）。
我们项目中这种惯用语的特别目的是隐藏 XImpl 类所使用的类型。具体来说，我们用它来隐藏不同硬件实现的细节，其中不同的头文件将被引入。对于一个平台，我们有不同的 XImpl 类实现，而对于另一个平台，则有不同的实现。类 X 的布局保持不变，无论平台如何。
我过去经常使用这种技术，但后来发现自己逐渐放弃了。
当然，将实现细节隐藏在类的用户之外是一个好主意。但您也可以通过让类的用户使用抽象接口来实现此目的，而具体实现则是具体类。
pImpl的优点：
假设只有一个实现此接口，则不使用抽象类/具体实现更清晰
如果您有一组类（一个模块），这些类访问相同的“impl”，但模块的用户仅使用“公开”类。
如果假定这是不好的事情，则没有v表。
pImpl的缺点（其中抽象接口效果更好）
虽然您可能只有一个“生产”实现，但使用抽象接口，您也可以创建适用于单元测试的“mock”实现。
（最大的问题）。在unique_ptr和moving出现之前，您的选择受到限制，以便存储pImpl。原始指针会导致类不可复制的问题。旧的auto_ptr无法与向前声明的类一起使用（在所有编译器上都是如此）。因此，人们开始使用shared_ptr，这使您的类能够复制，但两个副本都具有相同的底层shared_ptr，这可能是意外的（修改一个，两个都被修改）。因此，解决方案通常是使用内部原始指针使类不可复制，并返回指向它的shared_ptr。因此需要两个new调用。（实际上3个，因为旧的shared_ptr会给您第二个）
从技术上讲，不太符合const-correct，因为constness未传播到成员指针。
总的来说，我因此已经多年不再使用pImpl，而改用抽象接口（和工厂方法来创建实例）。
我认为这种方式的一个好处是它可以让程序员快速地实现某些操作:
X( X && move_semantics_are_cool ) : pImpl(NULL) {
this->swap(move_semantics_are_cool);
}
X& swap( X& rhs ) {
std::swap( pImpl, rhs.pImpl );
return *this;
}
X& operator=( X && move_semantics_are_cool ) {
return this->swap(move_semantics_are_cool);
}
X& operator=( const X& rhs ) {
X temporary_copy(rhs);
return this->swap(temporary_copy);
}
顺便说一下，我希望自己没有误解移动语义。
const unique_ptr<XImpl>而不是XImpl*来实现pimpl。 - Neil G