Pimpl 习语的实践

Question

SO 上有一些关于 pimpl 惯用法 的问题，但我更好奇它在实践中的使用频率。

我知道性能和封装之间存在一些权衡，再加上额外的重定向带来的一些调试烦恼。

那么，这是应该在每个班级中采用，还是全有或全无的基础上采用？ 这是最佳实践还是个人偏好？

我意识到这有些主观，所以让我列出我的首要任务：

• 代码清晰度
• 代码可维护性
• 性能

我总是假设我需要在某个时候将我的代码公开为库，所以这也是一个考虑因素。

编辑：任何其他选项来完成同样的事情将是受欢迎的建议。

Answer 1

我想说的是，你是否在每堂课上这样做，还是在全有或全无的基础上进行，取决于你首先为什么选择 pimpl 习惯用法。 在构建库时，我的原因是以下之一：

• 想要隐藏实现以避免泄露信息（是的，这不是一个 FOSS 项目:)
• 想要隐藏实现以便减少客户端代码的依赖性。 如果您构建共享库 (DLL)，则可以更改 pimpl 类，甚至无需重新编译应用程序。
• 希望减少使用该库编译类所需的时间。
• 想要修复命名空间冲突（或类似的）。

这些原因都不会促使我们采取“全有或全无”的方法。 在第一种情况下，您只需简化要隐藏的内容，而在第二种情况下，对于您希望更改的类来说，这样做可能就足够了。 另外，出于第三个和第四个原因，隐藏重要的成员只会带来好处，而这些成员又需要额外的标头（例如，第三方库的标头，甚至是 STL 的标头）。

无论如何，我的观点是，我通常不会发现这样的东西太有用：

class Point {
  public:      
    Point(double x, double y);
    Point(const Point& src);
    ~Point();
    Point& operator= (const Point& rhs);

    void setX(double x);
    void setY(double y);
    double getX() const;
    double getY() const;

  private:
    class PointImpl;
    PointImpl* pimpl;
}

在这种情况下，你会开始权衡，因为需要取消引用指针，并且无法内联方法。 但是，如果您仅对重要的类执行此操作，那么通常可以容忍轻微的开销，不会出现任何问题。

Answer 2

pimpl ideom 的最大用途之一是创建稳定的 C++ ABI。 几乎每个 Qt 类都使用“D”指针，这是一种pimpl。 这允许在不破坏 ABI 的情况下执行更容易的更改。

Answer 3

代码清晰度

代码清晰度是非常主观的，但在我看来，具有单个数据成员的标头比具有许多数据成员的标头更具可读性。 然而，实现文件的噪音较大，因此清晰度会降低。 如果该类是基类，主要由派生类使用而不是维护，那么这可能不是问题。

可维护性

对于 pimpl 类的可维护性，我个人发现每次访问数据成员时额外的取消引用很乏味。 如果数据纯粹是私有的，则访问器无济于事，因为无论如何您都不应该为其公开访问器或修改器，并且您将不得不不断取消引用 pimpl。

对于派生类的可维护性，我发现该习惯用法在所有情况下都是纯粹的胜利，因为头文件列出了更少的不相关细节。 所有客户端编译单元的编译时间也得到了改进。

性能

在许多情况下，性能损失很小，但在少数情况下，性能损失却很严重。 从长远来看，它的数量级与虚拟函数的性能损失相当。 我们讨论的是每个数据成员的每次访问的额外取消引用，加上 pimpl 的动态内存分配，以及销毁时的内存释放。 如果 pimpl 类不经常访问其数据成员，则 pimpl 类对象会经常创建并且是短暂的，那么动态分配可能会超过额外的取消引用。

决定

我认为性能至关重要的类，例如一次额外的取消引用或内存分配会产生显着的差异，无论如何都不应该使用 pimpl。 如果编译时间显着改善，那么性能下降并不显着并且头文件被广泛 #include 的基类可能应该使用 pimpl。 如果编译时间没有减少，则取决于您的代码清晰度品味。

对于所有其他情况，这纯粹是一个品味问题。 在做出决定之前，先尝试一下并测量运行时性能和编译时性能。

Answer 4

当您使用强异常保证来实现 std::swap 和 operator= 时，pImpl 非常有用。 我倾向于说，如果你的班级支持其中任何一个，并且有多个重要领域，那么它通常不再取决于偏好。

否则，这取决于您希望客户端通过头文件与实现绑定的紧密程度。 如果二进制不兼容的更改不是问题，那么您可能不会在可维护性方面受益匪浅，尽管如果编译速度成为问题，通常会节省一些费用。

性能成本可能更多地与内联损失有关，而不是与间接有关，但这是一个疯狂的猜测。

您可以稍后添加 pImpl，并声明从今天起客户端将不必仅仅因为您添加了私有字段而重新编译。

因此，这一切并不意味着采取全有或全无的方法。 您可以有选择地选择对您有利的课程，而不是对您没有好处的课程，然后再改变主意。 例如，将迭代器实现为 pImpl 听起来像是太多的设计......

Answer 5

这个习惯对于大型项目的编译时间有很大帮助。

外部链接

这也不错

Answer 6

当我想避免头文件污染我的代码库时，我通常使用它。 Windows.h 就是一个完美的例子。 它的行为太恶劣了，我宁愿自杀也不愿让它到处可见。 因此，假设您想要一个基于类的 API，将其隐藏在 pimpl 类后面就可以巧妙地解决问题。 （如果您满足于仅公开单个函数，那么这些函数当然可以前向声明，而无需将它们放入 pimpl 类中）

我不会到处使用 pimpl，部分原因是性能之所以成功，部分原因是因为需要做大量的额外工作才能获得通常很小的好处。 它为您提供的主要功能是实现和接口之间的隔离。 通常，这并不是一个非常高的优先级。

Answer 7

我在自己的库中的几个地方使用了这个习惯用法，在这两种情况下都将接口与实现清晰地分开。 例如，我有一个在 .h 文件中完全声明的 XML 阅读器类，该类具有指向 RealXMLReader 类的 PIMPL，该类声明为 & 。 在非公共 .h 和 .cpp 文件中定义。 RealXMlReader 又是我使用的 XML 解析器（当前为 Expat）的便捷包装器。

这种安排允许我将来从 Expat 更改为另一个 XML 解析器，而不必重新编译所有客户端代码（当然我仍然需要重新链接）。

请注意，我这样做并不是出于编译时性能的原因，只是为了方便。 有一些 PIMPL fabnatics 坚持认为，任何包含三个以上文件的项目都将无法编译，除非您自始至终都使用 PIMPL。 值得注意的是，这些人从未拿出任何实际证据，而只是模糊地提到“Latkos”和“指数时间”。

Answer 8

当我们有右值语义时，pImpl 将工作得最好。

pImpl 的“替代方案”也将实现隐藏实现细节，即使用抽象基类并将实现放入派生类中。 用户调用某种“工厂”方法来创建实例，并且通常会使用指向抽象类的指针（可能是共享指针）。

pImpl 背后的基本原理可能是：

• 节省 v 表。 是的，但是您的编译器会内联所有转发吗？您真的会保存任何内容吗？
• 如果您的模块包含多个彼此详细了解的类，尽管对于外界您是隐藏的。

pImpl 容器类的语义可以是：
- 不可复制，不可分配...因此，您可以在构造时“新建”您的 pImpl，并在销毁时“删除”
- 共享。 因此，您拥有shared_ptr，而不是Impl*

使用shared_ptr，只要类在析构函数处完成，您就可以使用前向声明。 即使是默认的析构函数也应该被定义（它可能会是）。

• 可交换。 您可以实现“可能为空”并实现“交换”。 用户可以创建一个实例，并向其传递一个非常量引用以使用“交换”来填充它。

• 两阶段建设。 您构造一个空的，然后对其调用“load()”来填充它。

共享是唯一一个我什至有点喜欢但没有右值语义的东西。 有了它们我们还可以正确实现不可复制不可分配。 我喜欢能够调用一个给我一个函数。

然而，我发现我现在更倾向于使用抽象基类而不是 pImpl，即使只有一种实现也是如此。