[译] GotW #100: Compilation Firewalls (Difficulty: 6/10)

[这是 GotW #24 的 C++11 更新版]

原文在这里 GotW #100: Compilation Firewalls (Difficulty: 6/10)

JG 问题

1. Pimpl 惯用法是什么？为什么要使用它？

Guru 问题

2. 怎样才是 Pimpl 惯用法在 C++11 中的最佳实现？

3. 类中的那些部分应该放到 impl 对象中？一些可能的选择包括：

  • 所有私有数据（非函数）
  • 所有私有成员
  • 所有私有和保护成员
  • 所有私有非虚成员
  • 全部都放到 impl 对象中，然后实现公有接口，每个实现仅仅简单的做函数转发（handle/body 的变体）

它们的每一个的缺点和优点是什么？你怎么选择？

4. impl 对象是否需要一个指向公开对象的反向指针？如果需要的话，它的最佳实现是什么？如果不需要的话，为什么？

解决方案

1. Pimpl 惯用法是什么？为什么要使用它？

在 C++ 中，当头文件中的类定义改变时，所有使用了这个类的用户都必须重新编译，甚至仅仅更改了那些用户无法访问的类的私有成员，也是如此。这是因为 C++ 的构建模型是基于文本包含的，并且 C++ 假定调用者知道以下两件事，而这些是会受到私有成员影响的：

  • 大小和布局：调用的代码必须知道一个类的大小和布局，包括私有数据成员。调用者总是知道被调用者的实现，这个约束导致了调用者和被调用者之间更紧密的耦合，但这是 C++ 对象模型的核心和哲学，因为保证编译器默认情况下可以直接访问对象，是允许编译器进行深度性能优化的重要组成部分。
  • 函数：调用的代码必须决定调用类的哪个成员，包括那些不可访问的，重载了非私有函数的私有函数——如果私有函数时更好的匹配，那么调用代码将编译失败。（C++ 经过深思熟虑的设计决定，由于安全问题，重载决议将在访问控制权限之前进行。举个例子，这可以保证当改变访问权限，把私有函数改为公有时，它不会改变合法的已有的代码的行为。）

为了减小编译依赖，最通常的技术是使用一个不透明的指针，隐藏实现的细节，下面是基本思路：

1
2
3
4
5
6
7

// Pimpl idiom - basic idea
class widget {
    // :::
private:
    struct impl;        // things to be hidden go here
    impl* pimpl_;       // opaque pointer to forward-declared class
};

类 widget 使用了 handle/body 惯用法的变体，参见 Coplien 的文章[1]，handle/body 过去主要用途是引用计数共享的实体，但是它还有更通用的隐藏实现的功能。为了方便，下面我会把类 widget 叫做可见类，impl 叫做 “Pimpl class” [2]

这个惯用法最大的好处是打破了编译时的依赖。首先，由于使用 Pimpl 可以消除多余的 #include，这使得编译过程更快了。我曾经在一个项目中仅仅把一些使用广泛的可见类转换为使用 Pimpls 就使得编译生成时间减少了一半。第二，它使得代码更改对编译的影响减小了，因为在类的 Pimpl 中的这一部分可以自由更改了——成员可以自由的添加或者删除，而不用重新编译客户端的代码。因为它可以在仅仅更改隐藏的成员时避免重新编译客户代码，所以它又被称为“编译防火墙”。

但是这还留下了一些问题：pimpl 应当是裸指针吗？哪些东西应该放到 Pimpl class 中？让我们看看这些和其他重要的细节吧。

2. 怎样才是 Pimpl 惯用法在 C++11 中的最佳实现？

避免使用裸指针和显式的 delete。仅仅使用标准 C++ 设施，最适当的选择是使用只能指针 unique_ptr 持有这个 Pimpl 对象，因为可见类是 Pimpl 对象的唯一所有者。使用 unique_ptr 也可以是代码变得简单。[3]

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// in header file
class widget {
public:
    widget();
    ~widget();
private:
    class impl;
    unique_ptr<impl> pimpl;
};

// in implementation file
class widget::impl {
    // :::
};

widget::widget() : pimpl{ new impl{ /*...*/ } } { }
widget::~widget() { }                   // or =default

注意这个模式的关键部分：

  • 使用 unique_ptr 来持有 Pimpl 对象是更好的选择。它比使用 shared_ptr 更高效，而且更能正确表达意图，Pimpl 对象是不应该共享的。
  • 在你自己的实现文件中定义和使用 Pimpl 对象。隐藏细节。
  • 在可见类的非内联构造函数中分配 Pimpl 对象。
  • 你仍然需要自己在可见类的实现文件中定义和实习它的析构函数，即使它和编译器生成的版本一模一样。这是因为虽然 unique_ptr 和 shared_ptr 可以实例化不完整的类型，但是 unique_ptr 的析构函数需要完整的类型，以便调用 delete（与 shared_ptr 不同，shared_ptr 可以在构造时获得更多的信息）。在实现 impl 的同时，自己实现它的析构函数，这可以有效的防止编译器自动生成析构函数。
  • 上面的模式没有生成默认的拷贝和转移语义，因为 C++11 编译器没有那么热心为你生成拷贝和转移操作。由于我们已经自己定义了析构函数，这使得编译器不再为我们生成转移构造和转移赋值。如果你想要支持拷贝和/或转移语义，和析构函数一样，你需要在实现中定义拷贝和转移操作。

C++11 中 Pimpl 另一个优势是，它是转移友好的，因为它仅仅需要拷贝单个指针就可以了。so cool。

让我们考虑一下上面提出的选择，哪些东西应该放到隐藏的 Pimpl 中。

什么是 Pimpl ？[4]

3. 类中的那些部分应该放到 impl 对象中？

一些可能的选择包括：

  • 所有私有数据（非函数）

选择1（得分：6/10）：这是一个好的开始，因为我们可以前向声明任何数据类，这比 #include 类的实际声明要好，它会造成代码依赖。

但是它也存在缺点：一个小问题，我们需要在可见类的实现中不停的写 pimpl-> 。还有个大问题，当增加和删除私有成员函数时，我们还是需要重新编译，而且在极少数情况下，如果重载了非私有函数的话，它会干扰重载决议。

有更好的选择吗？

  • 所有私有成员

选择2（得分：9/10）：这（几乎）是我最近的一贯做法。毕竟，在 C++中，我们说的“外部代码不应该也不能关心的部分”就是私有 private。

下面是三条注意事项，第一个就是我上面所说的“几乎”的原因：

  • 你不能隐藏虚函数到 Pimpl 中，即使虚函数是私有的。如果重写了继承来的虚函数，它必须出现在派生中，即使这个类是 final 类。如果虚函数是 new 函数，那么它必须出现在可见类中，这样才能让派生类重写。
  • 如果你需要使用可见类中的函数，那么 Pimpl 类的函数就需要一个指向可见类对象的反向指针，这增加了间接层。

  • 一个好的折中办法是，使用“选择2”的同时，把那些私有成员需要调用的非私有成员函数一起放到 Pimpl 中（参考下面的“反向指针”）。

  • 所有私有和保护成员

选择3（得分：0/10）：多余的把保护成员移动到 Pimpl 中式绝对错误的。虚成员和保护成员不应该移动到 Pimpl 中，因为这会让他们变得没有价值。毕竟，保护成员仅仅可以让派生类访问，如果让他们不可见或不可用那就没有任何价值了。派生类只能强制了解 Pimpl 的细节，然后再继承 Pimlp，然后维护一个并行的两个对象的继承体系。

但是，仍然有合理的原因把虚函数放到 Pimpl-like（body/implementation） 类中。但是它的动机和 Pimpl 惯用法是不同的，这是桥接模式[5]，它把一个类分成两部分，这两部分都可以包含实现以及独立的可扩展的虚函数。但是这是和 Pimpl 动机不同的另外的模式。

  • 所有私有非虚成员

选择4（得分：10/10）：这是理想的情况。为了避免保存或者传递一个反向指针，你可能需要把那些私有函数调用的公有函数也放到 Pimpl 中，然后在可见类中提供一个接口转发。但是你不应该移动保护成员和虚函数到 Pimpl 中，就像上面提到的。

  • 全部都放到 impl 对象中，然后实现公有接口，每个实现仅仅简单的做函数转发（handle/body 的变体）

选择5（得分：8/10某种情况下）：这在某种情况下是有用的，并且它可以有效避免反向指针，因为所有东西都在 Pimpl 类中了。主要的缺点是多了一层封装，并且它使得可见类无法通过继承来扩展了。

它们的每一个的缺点和优点是什么？你怎么选择？

完整的答案事实上比上面我们讨论的要简单的多。抛开经验和具体的分析，我们需要回顾，然后从第一条原则开始回答。

深呼吸，放松，好的。

主要考察的是面向对象语言[6]中的三个部分。它们是：

  1. 调用者的接口=公有成员。挺合适所有外部调用者可见和可用的部分。
  2. 派生类的接口=保护和虚成员，这些是仅派生类可见和可用的。
  3. 其他=私有和非虚成员，根据定义，这些是属于实现的细节。

仅仅第3条，所有第3条涵盖的内容，可以隐藏也应该隐藏到 Pimpl 中。这样我们就能继承所有上面提到的其他东西；举个例子，我们不能把虚成员放到 Pimpl 中，因为我们在第2条中提到的，派生类需要它可见。

上面的表格描述了不同设计的选择。包括 Pimpl，以及引出的其他设计，Coplien 提出的 Handle/Body ，还有桥接模式，虽然某些地方和 Pimpl 类似，但是它的动机和结构是非常不同的。

4. impl 对象是否需要一个指向公开对象的反向指针？如果需要的话，它的最佳实现是什么？如果不需要的话，为什么？

答案是：有时候，很不幸，是的。毕竟，我们所做的就是（人为地，不自然的）把对象分为两部分，来隐藏其中一部分。

考虑下面的情况：当可见类的一个函数被调用的时候，通常隐藏部分的函数或者数据是需要协助完成请求的。这没问题也很合理。但是上面已经讨论过，有时候 Pimpl 中的函数必须调用可见类中的非私有或者虚函数。这时候，需要一个指向可见类的指针。

有两个选择：

  • 在 Pimpl 中保存一个反向指针。这会带来轻微的开销，而且会一直保存着这个指针无论你用还是不用。此外，when you repeat yourself you can lie——如果你不小心维护指针的正确性让它指向正确的可见对象，反向指针会存在同步问题，举个例子，默认情况下转移操作之后，它就不再正确了。
  • （推荐）通过参数传递 this 指针给 Pimpl 中的函数（例如：pimpl->func(this, params)）。这仅仅会在函数调用(简单)时，带来栈上(廉价的)很小的空间开销，而且也不可能存在同步问题。但是，这意味着给每一个需要的隐藏函数增加个多余的参数。

感谢

感谢 Edd, pizer, and Howard Hinnant 阐明为什么 ~unique_ptr 需要 T 是完整类型, 并需要用户自己在外部实现类的析构函数；感谢 Stephan Lavavej and Alisdair Meredith 提醒我在转移构造和转移赋值时使用 =default；感谢 Howard Hinnant 指出即使使用了 =default，转移赋值函数仍然需要在实现文件中以非内联函数形式实现，因为它需要类型完整（确保能够 delete）。

注解

[1] James O. Coplien. “C++ Idioms” (EuroPLoP98).

[2] 一开始我使用 impl_ 作为指针的变量名。pimpl 是从 1996 年开始使用的，分享给我这个名字的是同学兼好友 Jeff Sumner，使用字母 “p” 作为指针变量的前缀，同时我也发现了之前变量名的可怕的双关。

[3] 这是 C++ 11 中最简单的模型。最主要的替代方案是使用 shared_ptr 或者裸指针来代替 unique_ptr，这两个的正确实现都比它复杂，存在潜在的错误，编译器生成的函数会产生不正确的行为：如果你使用 shared_ptr，你可以默认得到正确的析构函数，转移构造函数转移赋值函数，但是编译器生成的拷贝操作将是错误的，所以你需要手工明确的实现，或者使用 =delete 禁止它们（如果你忘记了，那你就默默得到了错误的语义），一个无用但是却存在的引用计数。如果你使用裸指针，你需要手动实现5个操作，析构函数，拷贝构造函数，拷贝赋值函数，转移构造函数，还有转移赋值函数。

[4] 不要发关于这个标题的笑话给我，大部分答案我都能想到。

[5] Gamma et al. Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1994).

[6] 一个类中不需要包含全部特性，举个例子，#2 不适用于那些不存在继承的值语义类。

C++, GotW
Comments

Comments