Pimpl(Pointer to implementation)很多同学都不陌生，但是从原始指针升级到C++11的独占指针std::unique_ptr时，会遇到一个incomplete type的报错，本文来分析一下报错的原因以及分享几种解决方法~
首先举一个传统C++中的Pimpl的例子
// widget.h// 预先声明class Impl;class Widget{ Impl * pImpl;};很简单，没什么问题，但是使用的是原始指针，现在我们升级到std::unique_ptr
// widget.h// 预先声明class Impl;class Widget{ std::unique_ptr<Impl> pImpl;};很简单的一次升级，而且也能通过编译，看似也没问题，但当你创建一个Widget的实例
// pimpl.cpp#include "widget.h"Widget w;
这时候，问题来了
$ g++ pimpl.cppIn file included from /usr/include/c++/9/memory:80, from widget.h:1, from pimpl.cpp:1:/usr/include/c++/9/bits/unique_ptr.h: In instantiation of 'void std::default_delete<_Tp>::operator()(_Tp*) const [with _Tp = Impl]’:/usr/include/c++/9/bits/unique_ptr.h:292:17: required from 'std::unique_ptr<_Tp, _Dp>::~unique_ptr() [with _Tp = Impl; _Dp = std::default_delete<Impl>]’widget.h:5:7: required from here/usr/include/c++/9/bits/unique_ptr.h:79:16: error: invalid application of 'sizeof’ to incomplete type 'Impl’79 | static_assert(sizeof(_Tp)>0, | ^~~~~~~~~~~
从报错我们可以看出，std::unique_ptr中需要静态检测类型的大小static_assert(sizeof(Impl)>0，但是我们的Impl是一个预先声明的类型，是incomplete type，也就没法计算，所以导致报错。
想要知道怎么解决，首先需要知道std::unique_ptr为啥需要计算这个，我们来看一下STL中相关的源码，从报错中得知是unique_ptr.h的292行，调用了79行，我们把前后相关源码都粘出来（来自g++ 9.3.0中的实现）
// 292行附近 /// Destructor, invokes the deleter if the stored pointer is not null. ~unique_ptr() noexcept {static_assert(__is_invocable<deleter_type&, pointer>::value, "unique_ptr's deleter must be invocable with a pointer");auto& __ptr = _M_t._M_ptr();if (__ptr != nullptr)// 292行在这里 get_deleter()(std::move(__ptr));__ptr = pointer(); }// 79行附近 /// Primary template of default_delete, used by unique_ptr template<typename _Tp> struct default_delete { /// Default constructor constexpr default_delete() noexcept = default; /** @brief Converting constructor. * * Allows conversion from a deleter for arrays of another type, @p _Up, * only if @p _Up* is convertible to @p _Tp*. */ template<typename _Up, typename = typename enable_if<is_convertible<_Up*, _Tp*>::value>::type> default_delete(const default_delete<_Up>&) noexcept { } /// Calls @c delete @p __ptr void operator()(_Tp* __ptr) const {static_assert(!is_void<_Tp>::value, "can't delete pointer to incomplete type");// 79行在这里static_assert(sizeof(_Tp)>0, "can't delete pointer to incomplete type");delete __ptr; } };std::unique_ptr中的析构函数，调用了默认的删除器default_delete，而default_delete中检查了Impl，其实就算default_delete中不检查，到下一步delete __ptr;，还是会出问题，因为不完整的类型无法被delete。
原因已经知道了，那么解决方法就呼之欲出了，这里提供三种解决方法：
方法一：改用std::shared_ptr
方法二：自定义删除器，将delete pImpl的操作，放到widget.cpp源文件中
方法三：仅声明Widget的析构函数，但不要在widget.h头文件中实现它
其中我最推荐方法三，它不改变代码需求，且仅做一点最小的改动，下面依次分析
改用std::shared_ptr
// widget.h// 预先声明class Impl;class Widget{ std::shared_ptr<Impl> pImpl;};改完就能通过编译了，这种改法最简单。但是缺点也很明显：使用shared_ptr可能会改变项目的需求，shared_ptr也会带来额外的性能开销，而且违反了“尽可能使用unique_ptr而不是shared_ptr”的原则（当然这个原则是我编的，哈哈）
那为什么unique_ptr不能使用预先声明的imcomplete type，但是shared_ptr却可以？
因为对于unique_ptr而言，删除器是类型的一部分：
template<typename _Tp, typename _Dp> class unique_ptr<_Tp[], _Dp>
这里的_Tp是element_type，_Dp是deleter_type
而shared_ptr却不是这样：
template<typename _Tp> class shared_ptr : public __shared_ptr<_Tp>
那为什么unique_ptr的删除器是类型的一部分，而shared_ptr不是呢？
答案是设计如此！哈哈，说了句废话。具体来说，删除器不是类型的一部分，使得你可以对同一种类型的shared_ptr，使用不同的自定义删除器
auto my_deleter = [](Impl * p) {...};std::shared_ptr<Impl> w1(new Impl, my_deleter);std::shared_ptr<Impl> w2(new Impl); // default_deleterw1 = w2; // It's OK!看到了么，这里的两个智能指针w1和w2，虽然使用了不同的删除器，但他们是同一种类型，可以相互进行赋值等等操作。而unique_ptr却不能这么玩
auto my_deleter = [](Impl * p) {...};std::unique_ptr<Impl, decltype(my_deleter)> w1(new Impl, my_deleter);std::unique_ptr<Impl> w2(new Impl); // default_deleter// w1的类型是 std::unique_ptr<Impl, lambda []void (Impl *p)->void>// w2的类型是 std::unique_ptr<Impl, std::default_delete<Impl>>w1 = std::move(w2); // 错误！类型不同，没有重载operator=道理我都明白了，那为什么要让这两种智能指针有这样的区别啊？
答案还是设计如此！哈哈，具体来说unique_ptr本身就只是对原始指针的简单封装，这样做不会带来额外的性能开销。而shared_ptr的实现提高了灵活性，但却进一步增大了性能开销。针对不同的使用场景所以有这样的区别。
自定义删除器，将delete pImpl的操作，放到widget.cpp源文件中
// widget.h// 预先声明class Impl;class Widget{ struct ImplDeleter final { constexpr ImplDeleter() noexcept = default; void operator()(Impl *p) const; }; std::unique_ptr<Impl, ImplDeleter> pImpl = nullptr;};然后在源文件widget.cpp中
#include "widget.h"#include "impl.h"void Widget::ImplDeleter::operator()(Impl *p) const{ delete p;}这种方法改起来也不复杂，但是弊端也很明显，std::make_unique没法使用了，只能自己手动new，直接看源码吧
template<typename _Tp, typename... _Args> inline typename _MakeUniq<_Tp>::__single_object make_unique(_Args&&... __args) { return unique_ptr<_Tp>(new _Tp(std::forward<_Args>(__args)...)); }看出问题在哪了么？这里返回的是默认删除器类型的unique_ptr，即std::unique_ptr<Impl, std::default_delete<Impl>>，如方法一中所说，是不同删除器类型的unique_ptr是没法相互赋值的，也就是说：
pImpl = std::make_unique<Impl>(); // 错误！类型不同，没有重载operator=pImpl = std::unique_ptr<Impl, ImplDeleter>(new Impl); // 正确！每次你都要写这么一大串
当然你也可以实现一个make_impl，并且using一下这个很长的类型，比如：
using unique_impl = std::unique_ptr<Impl, ImplDeleter>;template<typename... Ts>unique_impl make_impl(Ts && ...args){ return unique_impl(new Impl(std::forward<Ts>(args)...));}// 调用pImpl = make_impl();看似还凑合，但总的来说，这样做还是感觉很麻烦。并且有一个很头疼的问题：make_impl作为函数模板，没法声明和定义分离，而且其中的用到了new，需要完整的Impl类型。所以，你只能把这一段模板函数写在源文件中，emmm，总感觉不太对劲。
仅声明Widget的析构函数，但不要在widget.h头文件中实现它
// widget.h// 预先声明class Impl;class Widget{ Widget(); ~Widget(); // 仅声明 std::unique_ptr<Impl> pImpl;};// widget.cpp#include "widget.h"#include "impl.h"Widget::Widget() : pImpl(nullptr){}Widget::~Widget() = default; // 在这里定义这样就解决了！是不是出乎意料的简单！并且你也可以正常的使用std::make_unique来进行赋值。唯一的缺点就是你没法在头文件中初始化pImpl了
但也有别的问题，因为不光是析构函数中需要析构std::unique_ptr，还有别的也需要，比如移动构造、移动运算符等。所以在移动构造、移动运算符中，你也会遇到同样的编译错误。解决方法也很简单，同上面一样：
// widget.h// 预先声明class Impl;class Widget{ Widget(); ~Widget(); Widget(Widget && rhs); // 同析构函数，仅声明 Widget& operator=(Widget&& rhs); std::unique_ptr<Impl> pImpl;};// widget.cpp#include "widget.h"#include "impl.h"Widget::Widget() : pImpl(nullptr){}Widget::~Widget() = default;Widget(Widget&& rhs) = default; //在这里定义Widget& operator=(Widget&& rhs) = default;搞定！
本文首发于我的个人博客，欢迎大家来逛逛~~~
联系客服
