PIMPL 习惯用法真的在实践中使用吗？

Question

我正在阅读 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;
};

这看起来很有趣，但我以前从未见过这种做法，无论是在我工作过的公司中，还是在我工作过的开源项目中。看过源代码。所以，我想知道这种技术是否真的应用于实践。

我应该在任何地方使用它还是谨慎使用？这种技术是否建议用于嵌入式系统（性能非常重要）？

Answer 1

我想我应该添加一个答案，因为尽管有些作者暗示了这一点，但我认为这一点还不够明确。

PIMPL的主要目的是解决N*M问题。这个问题在其他文献中可能有其他名称，但这里是一个简短的总结。

你有某种继承层次结构，如果你要向你的层次结构添加一个新的子类，它将需要你实现 N 或 M 个新方法。

这只是一个近似的手动解释，因为我最近才意识到这一点，所以我自己承认我还不是这方面的专家。

对现有观点的讨论

但是，我在几年前遇到过这个问题以及类似的问题，并且我对给出的典型答案感到困惑。 （大概我几年前第一次了解 PIMPL，并发现了这个问题和其他类似的问题。）

1. 启用二进制兼容性（编写库时）
2. 减少编译时间
3. 隐藏数据

考虑到上述“优点”，它们都不是特别引人注目的我认为使用 PIMPL 的原因。因此我从未使用过它，并且我的程序设计因此受到影响，因为我放弃了 PIMPL 的实用性以及它真正可以用来完成的任务。

请允许我对每一项进行评论以解释：

1.

二进制兼容性仅在编写库时才有意义。如果您正在编译最终的可执行程序，那么这没有关系，除非您正在使用其他人的（二进制）库。 （换句话说，您没有原始源代码。）

这意味着这种优势的范围和实用性有限。只有编写以专有形式提供的库的人才会对它感兴趣。

2.

我个人认为这在当今很少有编译时间至关重要的项目中没有任何意义。也许这对于 Google Chrome 的开发者来说很重要。可能显着增加开发时间的相关缺点可能会抵消这一优点。我可能是错的，但我发现这不太可能，特别是考虑到现代编译器和计算机的速度。

3.

我并没有立即看到 PIMPL 带来的优势。通过传送头文件和二进制目标文件可以实现相同的结果。如果我面前没有具体的例子，很难理解为什么 PIMPL 在这里是相关的。相关的“东西”是传送二进制目标文件，而不是原始源代码。

PIMPL 实际上是做什么的：

你必须原谅我的回答有些含糊。虽然我不是软件设计这一特定领域的完全专家，但我至少可以告诉您一些相关信息。这些信息大部分是从设计模式中重复的。作者将其称为“桥模式”，又名“句柄”，又名“主体”。

本书中给出了编写窗口管理器的示例。这里的关键点是窗口管理器可以实现不同类型的窗口以及不同类型的平台。

例如，可能有一个

• Window
• 图标窗口
• 带 3D 加速的全屏窗口
• 一些其他奇特的窗口
• 这些是可以渲染的窗口类型

以及

• Microsoft Windows 实现
• OS X 平台实现
• Linux X Window Manger
• Linux Wayland
• 这些是不同类型的渲染引擎，具有不同的操作系统调用，也可能具有根本不同的功能

上面的列表与另一个答案中给出的类似，其中另一个用户描述了编写应该与不同类型一起工作的软件DVD 之类的硬件玩家。 （我完全忘记了这个例子是什么。）

与《设计模式》书中所写的相比，我在这里给出的示例略有不同。

要点是有两种不同类型的事物应该使用继承层次结构来实现，但是使用单个继承层次结构在这里是不够的。 （N*M 问题，复杂度就像每个项目符号列表中事物数量的平方一样，这对于开发人员来说是不可行的。）

因此，使用 PIMPL，可以分离出窗口的类型并提供一个指针到实现类的实例。

因此 PIMPL：

• 解决了 N*M 问题
• 将使用继承进行建模的两个根本不同的事物解耦，从而存在 2 个或更多层次结构，而不仅仅是一个整体
• 允许运行时交换确切的实现行为（通过更改指针）。这在某些情况下可能是有利的，而单个整体强制静态（编译时）行为选择而不是运行时行为选择

可能还有其他方法来实现这一点，例如使用多重继承，但这通常是一种更复杂和困难的方法，至少根据我的经验。

Answer 2

所以，我想知道这种技术真的在实践中得到应用吗？我应该在任何地方使用它还是谨慎使用它？

当然是用的。我在我的项目中，几乎在每堂课上都使用它。

---

使用 PIMPL 习惯用法的原因：

二进制兼容性

当您开发库时，您可以向 XImpl 添加/修改字段，而不会破坏与客户端的二进制兼容性（这将意味着崩溃！）。由于当您向 Ximpl 类添加新字段时，X 类的二进制布局不会改变，因此在次要版本更新中向库添加新功能是安全的。

当然，您还可以向 X/XImpl 添加新的公共/私有非虚拟方法，而不会破坏二进制兼容性，但这与标准标头/实现技术相同。

数据隐藏

如果您正在开发一个库，尤其是一个专有库，那么最好不要透露使用了哪些其他库/实现技术来实现您的库的公共接口。要么是因为知识产权问题，要么是因为您认为用户可能会对实现做出危险的假设，或者只是通过使用可怕的转换技巧来破坏封装。 PIMPL 解决/缓解了这个问题。

编译时间

编译时间减少了，因为当您向 XImpl 类添加/删除字段和/或方法时，只需重建 X 的源（实现）文件（这映射到在标准技术中添加私有字段/方法）。实际上，这是一个常见的操作。

使用标准标头/实现技术（无 PIMPL），当您向 X 添加新字段时，每个分配 X 的客户端（无论是在堆栈上还是在堆上）需要重新编译，因为它必须调整分配的大小。好吧，每个不分配 X 的客户端也都需要重新编译，但这只是开销（客户端生成的代码将是相同的）。

更重要的是，使用标准标头/实现分离，即使将私有方法 X::foo() 添加到 X，也需要重新编译 XClient1.cpp 和 Xh 已更改，即使 XClient1.cpp 由于封装原因不可能调用此方法！如上所述，它是纯粹的开销，并且与现实生活中的 C++ 构建系统的工作方式有关。

当然，当您只修改方法的实现时，不需要重新编译（因为您没有触及标头），但这与标准标头/实现技术相同。

---

是否建议在嵌入式系统（性能非常重要）中使用该技术？

这取决于你的目标有多强大。然而，这个问题的唯一答案是：衡量和评估你的所得和失去。另外，请考虑到，如果您不发布供客户在嵌入式系统中使用的库，则只有编译时间优势适用！

Answer 3

似乎很多库都使用它来保持 API 的稳定性，至少对于某些版本而言是这样。

但对于所有的东西来说，你不应该不小心地到处使用任何东西。使用前一定要三思。评估它给您带来了哪些优势，以及它们是否值得您付出的代价。

它可能给您带来的优势是：

• 有助于保持共享库的二进制兼容性
• 隐藏某些内部细节
• 减少重新编译周期

这些对您来说可能是也可能不是真正的优势。就像我一样，我不在乎几分钟的重新编译时间。最终用户通常也不这样做，因为他们总是从头开始编译一次。

可能的缺点是（也在这里，取决于实现以及它们是否对您来说是真正的缺点）：

• 由于比朴素变体更多的分配，导致内存使用量增加
• ，增加了维护工作量（您必须至少编写转发函数）
• 性能损失（编译器可能无法内联内容，因为它是类的简单实现）

因此请小心地为所有内容赋予一个值，并自己评估它。对我来说，几乎总是发现使用 PIMPL 惯用法并不值得付出努力。我个人只在一种情况下使用它（或至少是类似的东西）：

用于 Linux stat 调用的 C++ 包装器。这里，C 头文件中的结构体可能会有所不同，具体取决于 #defines 设置的内容。由于我的包装器标头无法控制所有这些，因此我仅在 .cxx 文件中使用 #include 来避免这些问题。

Answer 4

我同意所有其他人关于商品的看法，但让我提出一个限制的证据：与模板配合得不好。

原因是模板实例化需要实例化发生处可用的完整声明。 （这就是您看不到定义到 .cpp 文件中的模板方法的主要原因。）

您仍然可以引用模板化子类，但由于您必须全部包含它们，因此编译时“实现解耦”的每个优点（避免包含所有特定于平台的代码（缩短编译时间）都会丢失。

对于经典的OOP（基于继承）来说，这是一个很好的范例，但不适用于泛型编程（基于专业）。

Answer 5

其他人已经提供了技术上的优点/缺点，但我认为以下几点值得注意：

首先，不要教条。如果 PIMPL 适用于您的情况，请使用它 - 不要仅仅因为“它是更好的 OO，因为它确实隐藏了实现”等而使用它。引用 C++ 常见问题解答：

封装是针对代码的，而不是针对人的 (来源）

只是为了给您提供一个开源软件的使用示例以及原因：OpenThreads，OpenSceneGraph。主要思想是从标头（例如，）中删除所有特定于平台的代码，因为内部状态变量（例如，线程句柄）因平台而异。这样，人们就可以针对您的库编译代码，而无需了解其他平台的特性，因为一切都是隐藏的。

Answer 6

我主要考虑将 PIMPL 用于公开供其他模块用作 API 的类。这有很多好处，因为它使得重新编译 PIMPL 实现中所做的更改不会影响项目的其余部分。此外，对于 API 类，它们促进了二进制兼容性（模块实现中的更改不会影响这些模块的客户端，它们不必重新编译，因为新实现具有相同的二进制接口 - PIMPL 公开的接口）。

至于对每个类使用 PIMPL，我会谨慎考虑，因为所有这些好处都是有代价的：需要额外的间接级别才能访问实现方法。

Answer 7

我认为这是最基本的解耦工具之一。

我在嵌入式项目 (SetTopBox) 上使用 PIMPL（以及 Exceptional C++ 中的许多其他惯用语）。

在我们的项目中，这个习惯用法的特殊目的是隐藏 XImpl 类使用的类型。
具体来说，我们用它来隐藏不同硬件的实现细节，其中会引入不同的标头。我们为一个平台提供了不同的 XImpl 类实现，而为另一个平台提供了不同的实现。无论平台如何，X 类的布局都保持不变。

Answer 8

我过去经常使用这种技术，但后来发现自己正在放弃它。

当然，向类的用户隐藏实现细节是一个好主意。但是，您也可以通过让类的用户使用抽象接口并将实现细节作为具体类来实现这一点。

pImpl 的优点是：

1. 假设这个接口只有一个实现，不使用抽象类/具体实现会更清晰

2. 如果您有一套类（一个模块），其中多个类访问相同的“impl”，但该模块的用户只会使用“公开”的类。

3. 如果这被认为是一件坏事，则没有 v-table。

我发现 pImpl 的缺点（抽象接口效果更好）

1. 虽然您可能只有一个“生产”实现，但通过使用抽象接口，您还可以创建一个适用于单元测试的“模拟”实现。

2. （最大的问题）。在 unique_ptr 和移动之前，您对于如何存储 pImpl 的选择有限。原始指针和您的类不可复制的问题。旧的 auto_ptr 不能与前向声明的类一起使用（无论如何不是在所有编译器上）。因此，人们开始使用shared_ptr，这很好地使您的类可复制，但当然，两个副本都具有您可能意想不到的相同的底层shared_ptr（修改一个副本，然后两个副本都被修改）。因此，解决方案通常是对内部指针使用原始指针，并使该类不可复制，然后返回一个shared_ptr。所以两次调用 new。 （实际上，旧的shared_ptr的3个给了你第二个）。

3. 从技术上讲，并不是真正的常量正确，因为常量不会传播到成员指针。

总的来说，多年来我已经从 pImpl 转向抽象接口的使用（以及创建实例的工厂方法）。

Answer 9

这是我遇到的一个实际场景，这个习惯用法很有帮助。我最近决定在游戏中支持 DirectX 11 以及我现有的 DirectX 9 支持引擎。

该引擎已经封装了大部分DX功能，因此没有直接使用DX接口；它们只是在标头中定义为私有成员。该引擎使用 DLL 文件作为扩展，添加键盘、鼠标、操纵杆和脚本支持，与许多其他扩展一样简单。虽然大多数 DLL 不直接使用 DX，但它们需要 DX 知识和链接，只是因为它们引入了公开 DX 的标头。
添加 DX 11 后，这种复杂性会急剧增加，但没有必要。将 DX 成员移至仅在源中定义的 PIMPL 中，消除了这种强制。

除了减少库依赖性之外，当我将私有成员函数移至 PIMPL 中时，我公开的接口变得更加清晰，仅公开前端接口。

Answer 10

正如许多其他人所说，Pimpl 惯用法允许实现完整的信息隐藏和编译独立性，但不幸的是，代价是性能损失（额外的指针间接寻址）和额外的内存需求（成员指针本身）。在嵌入式软件开发中，额外的成本可能至关重要，特别是在必须尽可能节省内存的情况下。
使用 C++ 抽象类作为接口将以相同的成本获得相同的好处。
这实际上表明了 C++ 的一个很大缺陷，即如果不重复类似 C 的接口（以不透明指针作为参数的全局方法），就不可能在没有额外资源缺点的情况下实现真正的信息隐藏和编译独立性：这主要是因为类的声明必须由其用户包含，它不仅导出用户需要的类的接口（公共方法），而且还导出用户不需要的类的内部结构（私有成员）。

Answer 11

我看到的一个好处是它允许程序员以相当快的方式实现某些操作：

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);
}

PS：我希望我没有误解移动语义。

Answer 12

它在很多项目的实践中都有使用。它的实用性在很大程度上取决于项目的类型。使用此功能的更突出的项目之一是Qt，其基本思想是对用户（使用 Qt 的其他开发人员）隐藏实现或特定于平台的代码。

这是一个崇高的想法，但有一个真正的缺点：调试
只要隐藏在私有实现中的代码具有优质的质量，这一切都很好，但是如果其中存在错误，那么用户/开发人员就会遇到问题，因为它只是指向隐藏实现的愚蠢指针，即使他/她有实现源代码。

因此，几乎所有的设计决策都有利有弊。