跟我学C++中级篇——Pimpl中的unique_ptr

一、问题
在前面的Pimpl中提出个一个问题，就是如果把裸指针换成std::shared_ptr或std::unique_ptr会怎么样？然后这里再跟进一个问题，如果把std::unique_ptr变量默认置成nullptr又会怎么样？先看一下原来的例程（这里只展示部分）：

#include 
class PimplExample {
public:
	PimplExample();
 // ~PimplExample();//需要删除掉析构函数

  int GetA();
  int GetB(int);
  int GetC();

private:
  struct Impl;
  Impl *pimpl_;
  std::unique_ptr<Impl> ptr_;
  // std::shared_ptr ptr_;
};
......

结果是，如果只是换成 std::shared_ptr，没有问题，正常运行。但是如果换成std::unique_ptr，则程序会报一个错误：

error: invalid application of ‘sizeof’ to incomplete type ‘xxxClass’  static_assert(sizeof(_Tp)>0

也就是说，前向声明的老问题，必须在编译单元看到前向声明的类的完整的定义。但是为什么裸指针和std::shared_ptr没有问题呢？

二、解决
要想解决问题就得先看一下std::shared_ptr和std::unique_ptr的定义的方式，弄明白了这二者的不同，就明白了为什么裸指针也没有问题。先看一下出错的位置：

/usr/include/c++/11/bits/unique_ptr.h:361:17:   required from ‘std::unique_ptr<_Tp, _Dp>::~unique_ptr()
/usr/include/c++/11/bits/unique_ptr.h:83:23: error: invalid application of ‘sizeof’ to incomplete type

看一下相关代码：

//361行
      ~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)
	  get_deleter()(std::move(__ptr));//361
	__ptr = pointer();
      }
//83行
     void
      operator()(_Tp* __ptr) const
      {
	static_assert(!is_void<_Tp>::value,
		      "can't delete pointer to incomplete type");
	static_assert(sizeof(_Tp)>0,   //83
		      "can't delete pointer to incomplete type");
	delete __ptr;
      }

那么为什么std::unique_ptr会调用删除器，这就得看一下二者的源码设计的不同了：

  template >
    class unique_ptr
    {
      template 
	using _DeleterConstraint =
	  typename __uniq_ptr_impl<_Tp, _Up>::_DeleterConstraint::type;

      __uniq_ptr_data<_Tp, _Dp> _M_t;
      ...
    };

     template
    class shared_ptr : public __shared_ptr<_Tp>
    {
      template
	using _Constructible = typename enable_if<
	  is_constructible<__shared_ptr<_Tp>, _Args...>::value
	>::type;
	...
     };

虽然二者都可以在实现的时候儿自定义删除器，但自定义的方式略有不同。这里先扯远一些，看一下自定义二者的删除器的方式：

#include 
#include 

void udeleter(int *p){
//to do
}
void sdeleter(int *p){
//to do
}

int main() {
  {
    std::unique_ptr<int, decltype(udeleter)> puPtr(new int(1), udeleter);
    std::shared_ptr<int> psPtr(new int(5), sdeleter);
  }

可以看到二者的形式还是有区别的。也就是说，shared_ptr的删除器是可选择的，而unique_ptr是必须的，如果没有会自动生成一个。而这个自动生成的过程，就是前面出现问题的原因。所以在编译器工作的时候儿，它会去查找这个删除器是否有问题，而如果删除器内看不到完整的数据定义类型，则就会出现前面的问题。否则没有检查直接调用后面的delete __ptr程序必须崩溃。说到此处，还得再说一下，二者调用删除的内在方式也有不同，shared_ptr是判断refcount也就是引用计数器，其为0则调用删除器（然后再调用析构函数），而unique_ptr就是直接析构函数，标准规定了， NULL,nullptr是不需要调用析构的。所以在写这两个的删除器时，传入nullptr导致的结果会有所不同。这个一定要注意，有兴趣可以自己搞个例程来一下。
好，问题原因找到了，解决方法呢？很简单，有几种方法：
1、直接自己搞一个删除器
2、把unique_ptr改成shared_ptr
3、编写自己的析构函数，但不能在头文件中编写。
代码非常简单，这里就不再写了。

三、扩展
上面的代码问题前向声明中是一个小问题，但再扩展一下，如果给智能指针默认赋值为nullptr会是什么情况？好，在上面的代码试一下，会发现，没啥问题，一切正常。一切正常才会引出下面的问题。将扩展的问题展开一下，如果遇到前向声明的类再次为外部的类前向声明使用呢？或者说前向声明的类的头文件为别的类使用呢？看一下代码：

//main.cpp
#include 

using namespace std;
//#include "cpimpl.h"//此处
#include "pimpla.h"
#include "testa.h"
int main() {
  cout << "Hello World!" << endl;
  return 0;
}
//========================================================
//testa.h
#include 
class PimplA;
class TestA {
public:
  TestA();
  ~TestA();

private:
  std::unique_ptr<PimplA> m_pa = nullptr;
};

//testa.cpp
#include "testa.h"
#include "pimpla.h"

TestA::TestA() {}
TestA::~TestA() {}
//========================================================
//pimpla.h

class CPimpl;
class PimplA
{
public:
    PimplA();
    ~PimplA();
    private:
  std::unique_ptr<CPimpl> m_apc = nullptr;
};


//pimpla.cpp
//#include "cpimpl.h"//同main.cpp中原因一致
#include "pimpla.h"

PimplA::PimplA(){}
PimplA::~PimplA() {}

//=======================================================

//cpimpl.h
#include 
class CPimpl {
public:
  CPimpl();
  ~CPimpl();
};

//cpimpl.cpp
#include "cpimpl.h"

CPimpl::CPimpl() {}
CPimpl::~CPimpl() {}

在上面的代码中，如果在main.cpp中注释掉相关的头文件，则会发现，如果没有给前向声明的指针赋值为nullptr,编译运行没有问题，但赋值后，如果没有头文件的包含，则直接报文章开始的不完全定义类型错误。
这里简单解释一下，如果没有赋值为nullptr，编译器把其判断成一个声明，则不再需要查看其定义；反之，则认为其已经定义，那么必须看到完整的数据类型定义。那为什么不二次包含时没有问题呢，原因也很简单，因为无论如何，开发者都会在自己cpp文件（编译单元）中包含相关头文件，否则编译不通过。这样，声明和定义对编译器就没有区别了。
引申到其它默认的函数，如拷贝构造函数和赋值函数也会有这个问题，遇到了需要想起这个产生的原因，此处就不再赘述。

四、总结
基础知识往往是解决问题的一个重要的切入点，这也是总说的“基础不牢，地动山摇”的原因。但往往单纯讲基础知识，很多人都能侃侃而谈，真到解决问题了，不知道如何下手。这就需要不断的锤炼自己的解决问题的思想了。