C++程序员应了解的那些事（8） PIMPL模式（指向实现的指针）
【1】C++之善用PIMPL技巧解決/改善C++编码时常碰到的2大问题。
（1）class增加private/protected成员时，使用此class的相关 .cpp(s) 需要重新编译。
（2）定义冲突与跨平台编译。
（1）class增加private/protected成员时，使用此class的相关 .cpp(s) 需要重新编译。
假设我们有一个A.h(class A)，并且有A/B/C/D 4个.cpp引用他，他们的关系如下图：
如果A class增加了private/protected成员（即A.h文件发生修改），A/B/C/D .cpp全部都要重新编译。因为make是用文件的时间戳记录来判断是否要从新编译，当make发现A.h比A/B/C/D .cpp4个文件新时，就会通知compiler重新编译他们，就算你的C++ compiler非常聪明，知道B/C/D文件只能存取A class public成员，make还是要通知compiler起来检查。三个文件也许还好，那五十个，一百个呢？
<解决方案>
//a.h
#ifndef A_H
#define A_H
#include <memory>
class A
{
public:
A();
~A();
void doSomething();
private:
struct Impl;
std::auto_ptr<impl> m_impl;
};
#endif有一定C++基础的人都知道，使用前置声明(forward declaration)可以减少编译依赖，这个技巧告诉compile指向 class/struct的指针，而不用暴露struct/class的实现。在这里我们把原本的private成员封裝到struct A::Impl里，用一个不透明的指针(m_impl)指向他，auto_ptr是个smart pointer(from STL)，会在A class object销毁时连带将资源销毁还给系统。
//a.cpp
#include <stdio.h>
#include "a.h"
//子类型A::Impl 实现
struct A::Impl
{
int m_count;
Impl();
~Impl();
void doPrivateThing();
};
A::Impl::Impl():
m_count(0)
{
}
A::Impl::~Impl()
{
}
void A::Impl::doPrivateThing()
{
printf("count = %d\n", ++m_count);
}
//CLASS A实现
A::A():m_impl(new Impl)
{
}
A::~A()
{
}
void A::doSomething()
{
m_impl->doPrivateThing();
} 上面我们可以看到A private数据成员和成员函数全部被封裝到struct A::Impl里，如此一来无论private成员如何改变都只会重新编译A.cpp，而不会影响B/C/D.cpp，节约大量编译时间。
（2）定义冲突与跨平台编译（非重点）
如果你运气很好公司配给你8 cores CPU、SSD、32G DDRAM，会觉得PIMPL是多此一举。
但定定义冲突与跨平台编译问题不是电脑牛叉能够解決的，举个例子，你想在Windows上使用framework(例如 Qt)不具备的功能，你大概会这样做：
//foo.h
#ifndef FOO_H
#define FOO_H
#include <windows.h>
class Foo
{
public:
Foo();
~Foo();
void doSomething();
private:
HANDLE m_handle;
};
#endifFoo private数据成员: m_handle和系统相关，某天你想把Foo移植到Linux，因为Linux是用int来作为file descriptor，为了与Windows相区分，最直接的方法是用宏：
//foo.h
#ifndef FOO_H
#define FOO_H
#ifdef _WIN32
#include <windows.h>
#else
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#endif
class Foo
{
public:
Foo();
~Foo();
void doSomething();
private:
#ifdef _WIN32
HANDLE m_handle;
#else
int m_handle;
#endif
};
#endif上面的做法会有什么问题？
①windows.h是个巨大的header file，有可能会增加引用此header file的其他.cpp(s)编译时间，而实际上这些.cpp并不需要windows.h里面的内容。
②windows.h会与framework冲突，虽然大部分的framework极力避免发生这种事情，但往往项目变得越来越大后常常出现这类编译错误，(Linux也可能发生)。
③对于Linux用户，Windows那些header file是多余的，对于Windows用户Linux header files是多余的，沒必要也不该知道这些细节。
【2】c++11 条款22：当使用Pimpl（指向实现的指针）时，在实现文件里定义特定的成员函数。
假如你曾经和过多的编译构建时间抗争过，你应该熟悉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去编译，那说明Widget客户端必须#include <string>, <vector>, 以及gadget.h。这些头文件增加了Widget客户端的编译时间，加上它们会使得客户端依赖于那些头文件的内容。假如一个头文件的内容改变了，Widget客户端必须重编译。标准头文件<string>和<vector>不会经常改变，但gadget.h有可能会经常修正。
<探讨1>把C++98中的Pimpl技术应用在这里可以把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
}; 因为Widget没有提及std::string，std::vector和Gadget类型，Widget客户端不再需要#include这些类型的头文件。这会加速编译，而且意味着即使这些头文件的内容发生改变，Widget客户端也不受影响。
一个已声明但未定义的类型被称作不完整类型。Widget::Impl 就是这样的类型。对一个不完整类型你可以做的事情很少，但是声明一个指向它的指针就是其中之一可做的事情。Pimpl技巧就利用这点。
Pimpl技巧的第一部分是声明一个指向不完整类型的指针的数据成员，第二部分是动态分配和析构该对象（对象里保存了在原始类里的数据成员）。分配和析构的代码放在实现文件里。比如对Widget，就到到Widget.cpp里：
#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; // with data members formerly
std::vector<double> data; // in Widget
Gadget g1, g2, g3;
};
Widget::Widget(): pImpl(new Impl) // allocate data members for this Widget object
{
}
Widget::~Widget() // destroy data members for this object
{
delete pImpl;
} 这里显示的#include指令表明对std::string, std::vector和 Gadget的总体依赖依然存在。然而这些依赖关系以及从Widget.h(对Widget客户端可见并被使用)转移到了Widget.cpp（只对Widget实现者可见并被使用）。我也已经标注了动态分配和析构Impl对象的代码。当Widget被销毁时需要析构该对象，这是Widget析构函数所必须做的。
但上面展示的是c++98的代码，这已经是上个世纪的标准了。它使用了原始指针，原始的new和delete，因此都是原始的。这一章的主旨是尽量使用智能指针而不用原始指针，假如我们需要的是在Widget构造函数里动态的分配一个Widget::Impl 对象，同时析构时自动释放对象，那么std::unique_ptr（见条款18）恰恰就是一个我们需要的工具！ 用std::unique_ptr代替原始的指向Impl的指针，产生如下的代码：
头文件如下：
class Widget { // in "widget.h"
public:
Widget();
…
private:
struct Impl;
std::unique_ptr<Impl> pImpl; // use smart pointer instead of raw pointer
};
实现文件如下：
#include "widget.h" // in "widget.cpp"
#include "gadget.h"
#include <string>
#include <vector>
struct Widget::Impl { // as before
std::string name;
std::vector<double> data;
Gadget g1, g2, g3;
};
// per Item 21, create std::unique_ptr via std::make_unique ！！
Widget::Widget() : pImpl(std::make_unique<Impl>())
{
} <探讨2>这段代码可以通过编译，但很可惜在少数的客户端不能使用。
#include "widget.h"
Widget w; // error!
错误信息依赖你使用的编译器，但大致信息会提到关于在不完整类型上使用了sizeof或delete。这些操作不能在该类型上使用。使用std::unique_ptr来实现Pimpl技巧的失败而发出告警：因为
①std::unique_ptr宣传是可以支持不完整类型的，而且
②PIMPL技巧是std::unique_ptr最常用的场景之一。
幸运的是，使这些代码工作很容易，需要基本了解这个问题的产生原因。
这个问题主要是w被销毁时（比如超出范围）所执行的代码引起的。被销毁时析构函数被调用，在定义std::unique_ptr的类里，我们没有声明析构函数，因为我们没有代码要放到其中。根据编译器会生成特定成员函数的基本规则（见条款17），编译器为我们产生了一个析构函数。在析构函数内，编译器插入代码调用Widget的数据成员pImpl的析构函数，pImpl是std::unique_ptr<Widget::Impl>,std::unique_ptr使用默认删除器。这个默认删除器会去删除std::unique_ptr内部的原始指针，然而在删除前，c++11中典型的实现会使用static_assert去确保原始指针没有指向不完整类型。当编译器为Widget w的析构函数产生代码时，会遇到一个static_assert失败，于是就导致了错误发生。这个错误产生在w被销毁处，因为Widget的析构函数和其他的编译器产生的特殊的成员函数一样，都是内联函数。这个编译错误通常会指向w生成的代码行，因为正是创建对象的这行源代码导致了隐式析构。
为了修复这个问题，你只需要保证在生成析构std::unique<Widget::Impl>代码的地方，Widget::Impl是个完整类型。当类型的定义可以被看到时类型就是完整的。而Widget::Impl是定义在Widget.cpp文件中的。成功编译的关键是让编译器在widget.cpp中Widget::Impl定义之后看到Widget的析构函数的函数体。
这个很简单，在widget.h中声明Widget的析构函数，但是不在那里定义它：
class Widget { // as before, in "widget.h"
public:
Widget();
~Widget(); // declaration only
…
private: // as before
struct Impl;
std::unique_ptr<Impl> pImpl;
};
在widget.cpp中，Impl的定义之后再定义该析构函数：
#include "widget.h" // as before, in "widget.cpp"
#include "gadget.h"
#include <string>
#include <vector>
struct Widget::Impl { // as before, definition of
std::string name; // Widget::Impl
std::vector<double> data;
Gadget g1, g2, g3;
};
Widget::Widget() // as before
: pImpl(std::make_unique<Impl>())
{}
//或者Widget::~Widget() = default
//强调编译器生成的析构函数适用，在这里定义它只是要使得它的定义出现在Widget的实现文件中
Widget::~Widget() // ~Widget definition
{} 这端代码工作正常，代码也是最简短的。但如果你想强调编译器生成的析构将会做正确的事情，而你这里声明它只是要使得它的定义出现在Widget的实现文件中，那么你可以在析构函数的函数体后写上“=default”：
Widget::~Widget() = default; // same effect as above
<探讨3>
使用Pimpl技巧的类很天然的支持move操作，因为编译器生成的操作完全符合预期：在一个std::unique_ptr上执行move。正如条款17解释的，在Widget里声明了析构函数会阻止编译器产生move操作代码，因此，假如你需要支持move操作，你必须自己声明该函数。既然编译器产生的版本是正确的，你很有可能如下实现：
class Widget { // still in
public: // "widget.h"
Widget();
~Widget();
Widget(Widget&& rhs) = default; // right idea,
Widget& operator=(Widget&& rhs) = default; // wrong code! ××
…
private: // as before
struct Impl;
std::unique_ptr<Impl> pImpl;
}; 这个实现会导致和类里面没有析构函数一样的问题，编译器生成的move赋值操作需要在重分配前消毁掉pImpl指向的对象，但是在Widget的头文件里，pImpl指向的是一个不完整类型。move构造函数的情况有所不同，问题是编译器产生的代码在move构造函数中去销毁pImpl时会产生异常，而且销毁pImpl需要完整类型的Impl。
因为产生原因相同，所以修复办法也一样。把move操作函数的定义放到实现文件里：
头文件
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() // as before
: pImpl(std::make_unique<Impl>())
{}
Widget::~Widget() = default; // as before
Widget::Widget(Widget&& rhs) = default; // defini-
Widget& Widget::operator=(Widget&& rhs) = default; // tions
Pimpl技巧可以减少类实现和类使用者之间依赖关系的方法，但是理论上，Plimpl技巧并不能改变类本身。最初的Widget类包含了std::string,std::vector以及Gadget数据成员，我们假设Gadget类象std::string和std::vector一样也可以被拷贝，那么很自然的Widget类也会支持copy操作。我们必须自己写这些函数，因为（1）编译器不会给像std::unique_ptr一样的move-only类型产生copy函数，（2）即使产生了，那么产生的函数也只是拷贝std::unique_ptr(也就是浅拷贝)，而我们希望的是拷贝指针指向的内容（也就是执行深拷贝）。
根据我们目前熟悉的惯例，我们在头文件里声明在cpp文件里实现它们：
class Widget { // still in "widget.h"
public:
… // other funcs, as before
Widget(const Widget& rhs); // declarations
Widget& operator=(const Widget& rhs); // only
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) // copy ctor
: pImpl(std::make_unique<Impl>(*rhs.pImpl))
{}
Widget& Widget::operator=(const Widget& rhs) // copy operator=
{
*pImpl = *rhs.pImpl;
return *this;
}两个实现都很常规，这两个函数我们都是简单的拷贝Impl结构的域，从源对象（rhs）到目的对象（*this）。我们并没有一个个的拷贝域，是因为我们利用了编译器会为Impl类构造拷贝函数，这些拷贝函数会自动拷贝这些域的。于是我们通过调用Widget::Impl的编译器生成的拷贝函数去实现Widget的拷贝操作。在这个拷贝构造函数中，我们注意到还是遵循了条款21的建议，尽量用std::make_unique而不直接用new。
<探讨4>
为了实现Pimpl技巧，我们使用了std::unique_ptr灵巧指针，因为在对象（这里的Widget）中的pImpl指针对于相关的实现对象（这里的Widget::Impl对象）独享所有权的。更有趣的是如果我们这里用std::share_ptr来代替std::unique_ptr实现pImpl，会发现本款的建议不再适用。不需要再声明Widget的析构函数，也不需要用户声明的移动函数，编译器会很自然的产生一个move操作，会精确的按我们想要的去工作。这里我们看看widget.h里的代码：
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
客户端代码会#includes widget.h,
Widget w1;
auto w2(std::move(w1)); // move-construct w2
w1 = std::move(w2); // move-assign w1 编译正常，运行也如我们所期望：w1默认构造，值被移动到w2，然后值又被移动会w1，最后w1和w2都被销毁（这会导致Widget::Impl类对象被销毁）。
对于实现pImpl指针来说使用std::unique_ptr和std::shared_ptr的区别在于这两种灵巧指针对于定制删除器的支持不同。对于std::unique_ptr，删除器的类型是指针类型的一部分，这使得编译器会产生更小尺寸以及更高效的代码，当然产生的结果也是当编译器产生特定函数时（析构或移动函数），被指向的类型必须是完整的。对于std::shared_ptr，删除器的类型不是指针类型的一部分，这需要更大尺寸的运行时数据结构以及也许更慢的速度，但被指向的类型却不是必须的。
对于Pimpl技巧来说，在std::unique_ptr和std::shared_ptr的特性之间并没有一个妥协性，因为类之间必然像Widget和Widget::Impl之间的关系是独享所有权的，因此这里选择std::unique_ptr是更适合的。然而在其他某些情况下，存在共享所有权（因此std::shared_ptr因此更适合），就没有必要使用std::unique_ptr 。
综上：
①Pimpl技巧通过减少类的使用者和类实现之间的依赖而减少了编译次数。
②对于std::unique_ptr来实现pImpl指针，在文件中定义特定函数，在cpp文件中实现，即使默认的函数是可用的也要这样做。
③上述建议适用于std::unique_ptr，但不适用于std::shared_ptr。