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

本文主要是介绍跟我学C++中级篇——Pimpl中的unique_ptr，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

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

#include <memory>
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<Impl> 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行voidoperator()(_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 <typename _Tp, typename _Dp = default_delete<_Tp>>class unique_ptr{template <typename _Up>using _DeleterConstraint =typename __uniq_ptr_impl<_Tp, _Up>::_DeleterConstraint::type;__uniq_ptr_data<_Tp, _Dp> _M_t;...};template<typename _Tp>class shared_ptr : public __shared_ptr<_Tp>{template<typename... _Args>using _Constructible = typename enable_if<is_constructible<__shared_ptr<_Tp>, _Args...>::value>::type;...};

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

#include <iostream>
#include <memory>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 <iostream>using namespace std;
//#include "cpimpl.h"//此处
#include "pimpla.h"
#include "testa.h"
int main() {cout << "Hello World!" << endl;return 0;
}
//========================================================
//testa.h
#include <memory>
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.hclass 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 <memory>
class CPimpl {
public:CPimpl();~CPimpl();
};//cpimpl.cpp
#include "cpimpl.h"CPimpl::CPimpl() {}
CPimpl::~CPimpl() {}

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

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

这篇关于跟我学C++中级篇——Pimpl中的unique_ptr的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---