• 跟我学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_;
    };
    ......
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17

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

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

    也就是说,前向声明的老问题,必须在编译单元看到前向声明的类的完整的定义。但是为什么裸指针和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
    
    • 1
    • 2

    看一下相关代码:

    //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;
          }
    
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21

    那么为什么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;
    	...
         };
    
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21

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

    #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);
      }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15

    可以看到二者的形式还是有区别的。也就是说,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() {}
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45
    • 46
    • 47
    • 48
    • 49
    • 50
    • 51
    • 52
    • 53
    • 54
    • 55
    • 56
    • 57
    • 58
    • 59
    • 60
    • 61
    • 62
    • 63
    • 64
    • 65
    • 66

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

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

  • 相关阅读:
    Python数据分析实战-实现Mann-Whitney U检验(附源码和实现效果)
    arthas-线上排查问题工具
    Netty框架探索
    spring-2.5.6升级为spring-4.3.13过程记录
    Day04 Spring和SpringBoot
    七甲川荧光染料标记酸,Cy7 酸,Cy7-acid,CAS 943298-08-6参数及特性解析
    DateUtil时间工具类的基本使用
    雷达阵列天线孔径的概念及其相关意义
    代码随想录算法训练营Day61 | 总结和展望 | Python | 个人记录向
    支持国密ssl的curl编译和测试验证(上)
  • 原文地址:https://blog.csdn.net/fpcc/article/details/134099244