22.在使用Pimpl时，记得在实现文件中定义special function

Pimpl技术

 
Pimpl技术在Effective C++中多有涉及，详见Effective C++ Item31。

Pimpl声明

举例而言，假设Widget定义如下：

class Widget { // in header "widget.h"
public:
    Widget();
    …
private:
    std::string name;
    std::vector<double> data;
    Gadget g1, g2, g3; // Gadget is some user-defined type
};

因为Widget的数据成员是std::string，std::vector和Gadget，这意味着Widget客户端程序必须#include<string>，<vector>和gadget.h。

在C++ 98中应用Pimpl Idiom可以让Widget用原始指针替换其数据成员，该指针指向已声明但尚未定义的结构：

class Widget { // still in header "widget.h"
public:
    Widget();
    ~Widget(); // dtor is needed—see below
    …
private:
    struct Impl; // declare implementation struct
    Impl *pImpl; // and pointer to it
};

已声明但未定义的类型称为incomplete类型,Widget::Impl就是这种类型。使用不完整类型可以做的事情非常少，但至少可以声明一个指向它的指针。由于Widget不再涉及std::string，std::vector和Gadget，因此客户端代码不再需要#include上述头文件。这不仅仅加快了编译速度，这也意味着如果这些头文件的某些内容发生变化，Widget客户端不会受到影响（编译分离）。

---

Pimpl实现

Pimpl Idiom关于data member分配和释放代码在实现文件中，对于widget.cpp中的Widget，有：

#include "widget.h" // in impl. file "widget.cpp"
#include "gadget.h"
#include <string>
#include <vector>
struct Widget::Impl { // definition of Widget::Impl
    std::string name;
    std::vector<double> data;
    Gadget g1, g2, g3;
};
Widget::Widget():pImpl(new Impl){}
Widget::~Widget(){ delete pImpl; }

我们可以看到，原先的头文件依存性仍然存在，只不过现在由Widget.cpp执行#include语句，Widget.cpp仅由其实现者使用，而Widget.h由客户端代码使用，这保证了编译分离性质，此外，Widget析构必须释放impl对象，这是pimpl的必要条件。但上述都是C++98中的实现，现在看来，原始指针似乎过于粗糙了一些，因此我们理当追随时代的进步，以std::unique_ptr取代raw pointer:

class Widget { // in "widget.h"
public:
    Widget();
    …
private:
    struct Impl;
    std::unique_ptr<Impl> pImpl; // use smart pointer
};

实现文件如下所示：

#include "widget.h" // in "widget.cpp"
#include "gadget.h"
#include <string>
#include <vector>
struct Widget::Impl {
    std::string name;
    std::vector<double> data;
    Gadget g1, g2, g3;
};
Widget::Widget():pImpl(std::make_unique<Impl>()){} // C++14

显然。智能指针的引入至少帮助我们省去了写析构函数的烦恼。
上述代码可以编译，但客户端代码在使用时会出现问题：

#include "widget.h"
Widget w; // error!

一般来说，报错内容关于无法将sizeof或delete应用于incomplete type。但众所周知，unique_ptr支持incomplete type且Pimpl是unique_ptr大展身手的最佳场景之一，让上述代码能够工作很容易，但我们需要加深对该问题的理解。

---

问题分析

 
问题之所以会产生在于析构Widget时存在问题。根据Item17所述的通用规则，编译器应当在用户并未声明析构函数时为我们生成析构函数。在该析构函数中，编译器插入代码以调用Widget的数据成员pImpl的析构函数。pImpl是一个std::unique_ptr<Widget::Impl>，即使用默认删除器的std :: unique_ptr。默认删除器是一个在std ::unique_ptr内的原始指针上使用delete的函数,其会使用C++11中的static_assert确保原始指针并未指向一个incomplete类型。当编译器生成用于析构Widget的代码时，它会遇到一个失败的static_assert，而这正是导致错误的原因。

---

问题解决

 
要解决上述问题，只需要确保在生成析构std::unique_ptr<Widget::Impl>的代码时，Widget::Impl是一个complete类型。一个类型将会在编译器看到其定义时变为complete，且我们在widget.cpp中定义了Widget::Impl。 那么，成功编译的关键在于让编译器在Impl已被声明后，在Widget.cpp中看到Widget的析构函数（在其中编译器会生成析构unique_ptr的代码）已被定义。那么解决方案来了：在Widget.h中声明析构函数，但不作出定义：

class Widget { // as before, in "widget.h"
public:
    Widget();
    ~Widget(); // declaration only
    …
private: // as before
    struct Impl;
    std::unique_ptr<Impl> pImpl;
};

在定义了Widget::Impl后在Widget.cpp中定义析构函数：

#include "widget.h" // as before, in "widget.cpp"
#include "gadget.h"
#include <string>
#include <vector>
struct Widget::Impl {
    std::string name;
    std::vector<double> data;
    Gadget g1, g2, g3;
};
Widget::Widget():pImpl(std::make_unique<Impl>()){}
Widget::~Widget(){}

上述程序已经很好地完成了需求，如果你想要强调析构函数只需为默认生成的即可，你可以使用=default修饰之：

Widget::~Widget() = default; // same effect as above

---

Pimpl与move

 
使用Pimpl Idiom的类简直与move操作天生一对，在底层unique_ptr上执行move操作既高效又优雅。但正如Item 17所述，Widget中的析构函数声明阻止了编译器生成移动操作，因此如果要移动支持，则必须自己声明这些函数。鉴于默认生成的move操作没毛病，因此你可能会这样声明它们：

class Widget { // still in "widget.h"
public:
    Widget();
    ~Widget();
    Widget(Widget&& rhs) = default; // right idea, wrong code!
    Widget& operator=(Widget&& rhs) = default; 
    …
private: // as before
    struct Impl;
    std::unique_ptr<Impl> pImpl;
};

这种方法导致的问题与产生问题的根本原因都类似于之前。编译器生成的move operator=需要在重新分配之前销毁pImpl指向的对象，但在Widget头文件中，pImpl指向不完整的类型。而移动构造函数的问题在于编译器通常会生成代码以在移动构造函数内部出现异常时析构pImpl，但析构pImpl需要Impl为complete。

由于这个问题与之前完全一样，因此它们的解决方案也一样：

class Widget { // still in "widget.h"
public:
    Widget();
    ~Widget();
    Widget(Widget&& rhs); // declarations
    Widget& operator=(Widget&& rhs); // only
    …
private: // as before
    struct Impl;
    std::unique_ptr<Impl> pImpl;
};
#include <string> // as before,in "widget.cpp"
… 
struct Widget::Impl { … }; // as before
Widget::Widget():pImpl(std::make_unique<Impl>()){}
Widget::~Widget() = default; // as before
Widget::Widget(Widget&& rhs) = default;
Widget& Widget::operator=(Widget&& rhs) = default;

---

Pimpl与copy

 
编译器不会为具备move-only data member的class生成copy操作，因此我们应当手动完成声明（就算编译器真的完成了拷贝，它针对unique_ptr执行的也是浅拷贝（仅仅复制指针），而我们需要的是深拷贝（复制unique_ptr所指向的对象））。

照样画葫芦，我们在头文件中对copy操作完成声明,在原文件中完成定义：

class Widget { // still in "widget.h"
public:
    … // other funcs, as before
    Widget(const Widget& rhs); // declarations only
    Widget& operator=(const Widget& rhs);
private: // as before
    struct Impl;
    std::unique_ptr<Impl> pImpl;
};
#include "widget.h" // as before,
… // in "widget.cpp"
struct Widget::Impl { … }; // as before
Widget::~Widget() = default; // other funcs, as before
Widget::Widget(const Widget& rhs):pImpl(std::make_unique<Impl>(*rhs.pImpl)){}
Widget& Widget::operator=(const Widget& rhs){
    *pImpl = *rhs.pImpl;
    return *this;
}

值得注意的是，我们在copy操作中调用的是impl所具备的copy操作，从而确保了拷贝的正确性，此外，在构造函数中使用了make_unique以取代new。

---

Pimpl与shared_ptr

 
unique_ptr应用于Pimpl十分自然，这体现了资源的独占性，但如果我们将shared_ptr应用于Pimpl，则不必理会本小节所提倡的“将special function在头文件中声明，源文件中定义”，也就是说，下述代码是完全正确的：

class Widget { // in "widget.h"
public:
    Widget();
    … // no declarations for dtor or move operations
private:
    struct Impl;
    std::shared_ptr<Impl> pImpl; // std::shared_ptr instead of std::unique_ptr
};

客户端执行下述程序并不会报错：

Widget w1;
auto w2(std::move(w1)); // move-construct w2
w1 = std::move(w2); // move-assign w1

造成这一行为的原因很简单：unique_ptr的删除器是自身的一部分，而shared_ptr不是。为了保证高效性，unique_ptr删除器必须保证raw pointer为complete，而shared_ptr无需这种保证。

---

总结

1. Pimpl可以保证编译分离。
2. Pimpl中若是使用unique_ptr，则必须在头文件中声明special function，在源文件中定义special function。
3. 第2条规则并不适用于shared_ptr。