问题引出:
智能指针默认
删除器做的事情太简单啦,仅仅调用delete释放资源可能还不够
unique_
ptr类:
//第一个参数
智能指针底层资源的类型,第二个参数是
删除器,就是下面struct default_delete
//在
删除资源时会调用
删除器的operator()运算符重载,默认调用的是delete
ptr.
template<class _Ty,class _Dx> // = default_delete<_Ty>
class
unique_
ptr{ //...
1、智能指针删除器类
因为用自己实现的内存池在释放内存时需要buffer的大小才可以,用函数和labda表达式不知道如何实现,所以用删除器类实现自定义的智能指针删除器。
/* 智能指针删除器类 */
class CustomerDeleter
public:
CustomerDeleter(shared_ptr<RingMempool> MemPool, siz...
智能指针是用来实现指针指向的对象的共享的。其实现的基本思想:
每次创建类的新对象时,初始化指针并将引用计数置为1;
当对象作为另一对象的副本而创建时,拷贝构造函数拷贝指针并增加与之相应的引用计数;
对一个对象进行赋值时,赋值操作符减少左操作数所指对象的引用计数(如果引用计数减至0,则删除对象),并增加右操作数所指对象的引用计数;
调用析构函数时,减少引用计数(如果引用计数减至0,则删除基础对象);
重载“->”以及“*”操作符,使得智能指针有类似于普通指针的操作。
std::unique_ptr 占用空间与裸指针相同,大多数操作(包括解引用)的方法也相同。它表现的是 独占性拥有(exclusive ownership) 的语义,这意味着它不能被拷贝,是 move-only 类型;当其自身被销毁时,总会销毁其拥有的资源。而对象的销毁在作用域结束(即右大括号出现)时自动通过调用析构函数进行,此时 std::unique_ptr 默认对内部的裸指针进行 delete,因此你无需像裸指针一样操心什么时候要手动销毁。
(注:笔者尽己所能对MSVC的 std::unique_p.
1.1
智能指针
为了避免手动在堆中分配出的内存没有释放造成内存泄露的问题,
C++11提供了
智能指针。
智能指针将指针封装成一个栈对象。栈对象在生命周期结束自动销毁时会调用析构函数。
智能指针基本上也是在析构函数中做文章,实现的堆上内存管理。
C++11推荐使用的
智能指针有
unique_
ptr、
shared_
ptr和weak_
ptr三种。
1.2 内容简介
本文为std::
unique_
ptr的实现篇,介绍实现一个
UniquePtr类,实现与std::
unique_
ptr类似的功能。代码实现参考了st
C++中的
智能指针首先出现在“准”标准库boost中。
随着使用的人越来越多,为了让开发人员更方便、更安全的使用动态内存,
C++11也引入了
智能指针来管理动态对象。
在新标准中,主要提供了
shared_
ptr、
unique_
ptr、weak_
ptr三种不同类型的
智能指针。
接下来的几篇文章,我们就来总结一下这些
智能指针的使用。
今天,我们先来看看
shared_
ptr智能指针。
shared_
ptr 智能指针
shared_
ptr是一个引用计数
智能指针,用于共享对象的所有权也就是说它允许多个指针指向同一个对象。这一点与原始指针一致。
先来一段简单的代码,看看
shared_
ptr的简单使用:
我们前面介绍了unique_ptr智能指针,它对它所指向的对象资源具有专属所有权。这个就直接导致unique_ptr是无法进行复制操作的。有没有一种智能指针对象资源不具有专属所有权,也就是它可以进行复制操作。当然有的。那就是shared_ptr智能指针。shared_ptr也是对裸指针进行包装的类。
shared_ptr智能指针对它所指涉的对象资源具有共享所有权,也就是说指涉到该对象资源的所有的shared_ptr共同协作,确保在不再需要该对象的时刻将其进行析构。当最后一个指涉到该资源的shared_ptr不在指涉到对象资源时,该shared_ptr会对该对象资源进行析构。怎么判断是否是最后一
当我们使用QMultiMap的remove函数来
删除容
器中的某一个元素时,若是容
器中存放的是基本数据类型,则程序编译的时候没有任何问题,但是当容
器中存放的是
自定义的数据,这时若是
C++基础比较扎实的,应该不会出现编译报错的问题,但是
C++j基础不扎实的,就不会在
自定义数据类型中重写赋值运算符函数,故而导致使用remove
删除容
器中的元素时,会出现编译错误。
其实上述大致提到是因为
自定义数据类型需要重写赋值运算符。故而在
自定义数据类型中重写赋值运算符便可编译正常。究其原因是因为remove函数本身