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.cpp
In 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_deleter
w1 = 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中
#inclued "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;
搞定！
參考資料
- 當使用Pimpl慣用法，請在實現檔案中定義特殊成員函式 -
《Effective Modern Cpp》 - std::unique_ptr with an incomplete type won't compile - Stack Overflow
本文首發於我的個人部落格，歡迎大家來逛逛~~~