1. 程式人生 > 實用技巧 >std::unique_ptr使用incomplete type的報錯分析和解決

std::unique_ptr使用incomplete type的報錯分析和解決

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>

這裡的_Tpelement_type_Dpdeleter_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!

看到了麼,這裡的兩個智慧指標w1w2,雖然使用了不同的刪除器,但他們是同一種類型,可以相互進行賦值等等操作。而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型別。所以,你只能把這一整段實現寫到原始檔中,而沒法在標頭檔案中宣告它們。

方法三

僅宣告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;

搞定!

參考資料

本文首發於我的個人部落格,歡迎大家來逛逛~~~

原文地址:
std::unique_ptr使用incomplete type的報錯分析和解決 | 肝!