独占资源的std::unique_ptr
在C++98标准中，智能指针是通过auto_ptr来实现的，但是使用中缺点较多（不能调用delete[]等），所以基本被废弃了。auto_ptr可能最让人迷惑的是用拷贝构造的方式来实现move的部分语义，从而独占内存所有权，这与常规的拷贝构造语义完全不同，所以使用起来可能会让人十分迷惑，最终这些可能就是它不被人看好以至于废弃的原因吧。
C++11引入了右值引用后，move语义有了语法层面的支持，这给auto_ptr最初的设计理念提供了语言层面的支持，最终标准库提供了资源独占型的智能指针--std::unique_ptr。
std::unique_ptr是通过删除拷贝构造函数的方式禁止智能指针之间的拷贝，同时提供了移动构造函数来转移智能指针内实际指针的所有权，以此实现了资源独占。看一下它的所有构造：
我们可以看到copy版本的构造函数被显示删除了（C++11引入的新特性），同样的operator=版本的赋值构造也被显示的删除了，这样智能指针之间的复制，赋值就被禁止了。如果想转移指针的所有权只能通过移动构造函数。看一段代码
class UniquePtrTest
{
public:
class Obj
{
public:
Obj()
{
std::cout<<"Obj"<<std::endl;
}
~Obj()
{
std::cout<<"~Obj"<<std::endl;
}
int dummy;
};
static void execute()
{
std::unique_ptr<Obj> sp_obj(new Obj());
std::unique_ptr<Obj> sp_obj2(new Obj());
std::unique_ptr<Obj> sp_copy;
//sp_copy = sp_obj; //compile err
//std::unique_ptr<Obj> sp_copy(sp_obj); //compile err
sp_copy = std::move(sp_obj2);
std::unique_ptr<Obj> sp_move(std::move(sp_obj));
std::cout<<(sp_obj.get() == nullptr)<<std::endl; //sp_obj内的指针已经被置空
std::cout<<(sp_obj2.get() == nullptr)<<std::endl;
}
};
上面代码中已经明确显示了拷贝构造以及赋值操作是不能被编译通过的，如果想转移所有权，必须通过move函数来强制转换成右值，这样才能够进行移动资源所有权。这样的做法实际上是不安全的，除非使用者明确知道自己的意图，因为被移动资源的“老”智能指针内的成员指针已经被置空，再次使用的话会访问到一个nullptr（这里跟惯常的移动语义是相同的，有兴趣可以看一下std::unique_ptr的源码）。
同样的，由于std::unique_ptr是独占的，它的对象是不能通过值传递给函数的。
void test(std::unique_ptr<Obj> sp_ptr) //compile err
{
}
deleter
std::unique_ptr支持自定义deleter，可以看一下它的定义，它是有一个默认的模板参数的，这个参数就是它用到的deleter。
template <class _Tp, class _Dp = default_delete<_Tp> >
class _LIBCPP_TEMPLATE_VIS unique_ptr;
template <class _Tp>
struct _LIBCPP_TEMPLATE_VIS default_delete
{
#ifndef _LIBCPP_CXX03_LANG
_LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR default_delete() _NOEXCEPT = default;
#else
_LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR default_delete() _NOEXCEPT {}
#endif
template <class _Up>
_LIBCPP_INLINE_VISIBILITY default_delete(const default_delete<_Up>&,
typename enable_if<is_convertible<_Up*, _Tp*>::value>::type* = 0) _NOEXCEPT {}
_LIBCPP_INLINE_VISIBILITY void operator() (_Tp* __ptr) const _NOEXCEPT
{
static_assert(sizeof(_Tp) > 0, "default_delete can not delete incomplete type");
static_assert(!is_void<_Tp>::value, "default_delete can not delete incomplete type");
delete __ptr;
}
};
上面的代码是默认deleter的实现default_delete，实际上就是调用delete。它同样可以接受模板参数，并且通过偏特化的版本，提供了一个默认的delete[]版本。下面是代码
template <class _Tp>
struct _LIBCPP_TEMPLATE_VIS default_delete<_Tp[]>
{
public:
#ifndef _LIBCPP_CXX03_LANG
_LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR default_delete() _NOEXCEPT = default;
#else
_LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR default_delete() _NOEXCEPT {}
#endif
template <class _Up>
_LIBCPP_INLINE_VISIBILITY default_delete(const default_delete<_Up[]>&,
typename enable_if<__same_or_less_cv_qualified<_Up*, _Tp*>::value>::type* = 0) _NOEXCEPT {}
template <class _Up>
_LIBCPP_INLINE_VISIBILITY
void operator() (_Up* __ptr,
typename enable_if<__same_or_less_cv_qualified<_Up*, _Tp*>::value>::type* = 0) const _NOEXCEPT
{
static_assert(sizeof(_Tp) > 0, "default_delete can not delete incomplete type");
static_assert(!is_void<_Tp>::value, "default_delete can not delete void type");
delete [] __ptr;
}
};
这样std::unique_ptr很轻易的支持数组形式的指针。可以见一下代码
class UniquePtrTest
{
public:
class Obj
{
public:
Obj()
{
std::cout<<"Obj"<<std::endl;
}
~Obj()
{
std::cout<<"~Obj"<<std::endl;
}
int dummy;
};
static void execute()
{
std::unique_ptr<Obj, std::default_delete<Obj[]> > sp_int2(new Obj[3]);
}
};
当然也支持自定义deleter，看一下代码。
static void execute()
{
auto custom_deleter = [](Obj* ptr)
{
std::cout<<"custom_deleter"<<std::endl;
delete ptr;
};
std::unique_ptr<Obj, decltype(custom_deleter)> sp_custom(new Obj(), custom_deleter);
}
这里用到了lambda表达式，后续会专门一期介绍。自定义deleter就是自定义一个deleter的函数、lambda或者functor，当然需要把类型传入unique_ptr的模板参数中。
以上是对std::unique_ptr大致介绍，在很多资源第一无二（如线程等）的场景下它将发挥很大的作用，大大加强了开发效率和代码安全。
共享资源的std::shared_ptr
说到了资源独占型的智能指针，那就顺便提一下资源共享型的智能指针--std::shared_ptr。
从名字可以看出来std::shared_ptr是用来管理共享资源的指针的一个智能指针。它相对于unique_ptr而言，可以复制以及赋值，通过复制和赋值来传递引用计数对象从而达到对同一个指针进行引用计数管理。它没有内置的deleter，但是支持自定义deleter，所以如果用指向数组的指针的时候略显麻烦一些。还有就是它无法防止循环引用的问题，而且引用计数本身也有可能受到并发的影响。所以说shared_ptr还是有一定局限，不过确实很多场合需要用到它，所以使用的时候更准确的知道它的语义和实现，会让你少掉进一些陷阱中去。
结语
我个人倾向于能用std::unique_ptr就用它，实在需要共享数据的场景下有节制的使用std::shared_ptr。或许这是一种比较安全的选择。
