跟我学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文件(编译单元)中包含相关头文件,否则编译不通过。这样,声明和定义对编译器就没有区别了。
引申到其它默认的函数,如拷贝构造函数和赋值函数也会有这个问题,遇到了需要想起这个产生的原因,此处就不再赘述。

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

你可能感兴趣的:(C++,C++11,c++)