智能指针:告别内存泄漏的利器----《Hello C++ Wrold!》(27)--(C/C++)

智能指针:告别内存泄漏的利器----《Hello C++ Wrold!》(27)--(C/C++)

文章目录

前言

在 C++ 编程中,动态内存管理始终是开发者面临的核心挑战之一。手动使用new分配内存、delete释放内存的模式,不仅需要开发者时刻关注内存生命周期,更可能因疏忽导致内存泄漏(忘记调用delete)、二次释放(重复调用delete),或是在异常抛出时因执行流跳转跳过delete语句等问题 —— 这些隐患轻则导致程序性能退化,重则引发崩溃或不可预期的运行错误,成为项目中难以排查的 “隐形 bug”。

为解决这一痛点,C++ 标准库引入了智能指针这一核心工具。它基于 “资源获取即初始化”(RAII)的设计思想,将动态内存资源封装为对象的成员,利用 C++ 对象自动调用析构函数的特性,实现内存的 “自动释放”,从根本上减少手动管理内存的负担与风险。

本文将系统梳理智能指针的核心作用、实现原理,并针对 C++ 标准库中不同类型的智能指针(auto_ptr、unique_ptr、shared_ptr、weak_ptr)展开详细解析:包括它们的设计逻辑、模拟实现代码、适用场景,以及如何规避shared_ptr循环引用等典型问题。同时,文中还将补充 “删除定制器” 等进阶用法,帮助开发者根据实际需求灵活应对复杂的内存管理场景,最终掌握高效、安全的 C++ 动态内存管理方案。

智能指针的作用

作用:如果正确使用了智能指针的话,就不用自己手动delete

自己手动delete容易忽略的地方:在抛异常时容易跳过自己写的delete或者自己忘记delete

智能指针的实现和原理

原理:资源交给对象管理,对象生命周期内,资源有效;对象生命周期到了,释放资源–用的是RAII思想

–在实现的时候要让这个对象的用法像指针一样哈
智能指针的实现:template<classT>classSmartPtr{public:SmartPtr(T* ptr):_ptr(ptr){}~SmartPtr(){delete _ptr;} T&operator*(){return*_ptr;} T*operator->(){return _ptr;}private: T* _ptr;}; 用的话就eg:SmartPtr<string>sp(newstring("renshen"));
但是这种智能指针有个问题:

库里面的智能指针

不需要拷贝的场景,一般使用unique_ptr

需要拷贝的场景,一般使用shared_ptr–但是要小心循环引用

std::auto_ptr

这个是C++98实现的 原理其实就是管理权的转移–eg:在拷贝,会把被拷贝对象的资源管理权转移给拷贝对象,被拷贝对象悬空

这个智能指针也是基于RAII思想搞出来的
这个智能指针有很大的弊端:如果管理权被转移了的话,之前那个指针就会变成空指针

–因此很多公司都是明令禁止使用的

auto_ptr的模拟实现

template<classT>classauto_ptr{public:auto_ptr(T* ptr):_ptr(ptr){}~auto_ptr(){delete _ptr;} T&operator*(){return*_ptr;} T*operator->(){return _ptr;}auto_ptr(auto_ptr<T>& ap):_ptr(ap._ptr){ ap._ptr =nullptr;}//其实还有=号,->会把eg:sp1 = sp2的sp1原来的内存delete掉,然后管理权转移private: T* _ptr;}; 使用eg:A是一个类 auto_ptr<A>ap1(newA(5));//new A(5)这可不是什么匿名对象

std::unique_ptr

unique_ptr,shared_ptrweak_ptr是Boost库先实现的(底层和名字稍有不同),后来C++11也支持这几个智能指针的使用了
unique_ptr的话就是直接让智能指针不能拷贝和赋值+管理权转移

–这个智能指针也是基于RAII思想实现的

unique_ptr的模拟实现

template<classT>classunique_ptr{public:unique_ptr(T* ptr):_ptr(ptr){}~unique_ptr(){delete _ptr;} T&operator*(){return*_ptr;} T*operator->(){return _ptr;}unique_ptr(unique_ptr<T>& ap)=delete; unique_ptr<T>&operator=(unique_ptr<T>& ap)=delete;//除了这种办法:还能private这个成员函数,并且只声明不实现private: T* _ptr;}; 使用:unique_ptr<A>up1(newA(5));
引申:一般拷贝不让实现的话,赋值也不能实现–就像上面禁止就一起禁止了

std::shared_ptr

这个智能指针是最全面的–一般都是用的这个,然后有循环引用的时候搭配weak_ptr

–也是RAII思想实现的

原理:通过引用计数的方式来实现多个shared_ptr对象之间共享资源

shared_ptr的模拟实现

template<classT>classshared_ptr{public:shared_ptr(T* ptr =nullptr):_ptr(ptr),_pcount(newint(1)){}template<classD>shared_ptr(T* ptr, D del):_ptr(ptr),_pcount(newint(1)),_del(del){}~shared_ptr(){if(--(*_pcount)==0)//注意理解这里{_del(_ptr);delete _pcount;}} T&operator*(){return*_ptr;} T*operator->(){return _ptr;}shared_ptr(const shared_ptr<T>& sp):_ptr(sp._ptr),_pcount(sp._pcount){++(*_pcount);} shared_ptr<T>&operator=(const shared_ptr<T>& sp){if(_ptr == sp._ptr)return*this;//注意自己给自己赋值这个场景--一般都需要考虑if(--(*_pcount)==0){delete _ptr;delete _pcount;} _ptr = sp._ptr; _pcount = sp._pcount;++(*_pcount);return*this;//赋值的话一般return =前面的那个操作数} T*get()const{return _ptr;}private: T* _ptr;int* _pcount;//这里的计数 用静态的:static int count是不行的 function<void(T*)> _del =[](T* ptr){delete ptr;};//这个_del的类型很巧妙}; 用法: shared_ptr<A>sp1(newA(1)); 注意:shared_ptr<A>跟A可不是一个类型 
引申:编译器对越界访问的检查一般不是很彻底的

shared_ptr的一个弊端

shared_ptr在遇到循环引用的时候也是会内存泄漏的

std::weak_ptr

weak_ptr这个智能指针不是RAII思想的,他的唯一作用就是解决shared_ptr的循环引用问题的

这个智能指针可以访问资源,但是不参与资源释放的解决

weak_ptr不能管理资源!!!

注意:weak_ptr库里面实现了让他可以和shared_ptr相互转换

weak_ptr的模拟实现

template<classT>classweak_ptr{public:weak_ptr():_ptr(nullptr){}weak_ptr(const shared_ptr<T>& sp):_ptr(sp.get()){} weak_ptr<T>&operator=(const shared_ptr<T>& sp){ _ptr = sp.get();return*this;} T&operator*(){return*_ptr;} T*operator->(){return _ptr;}private: T* _ptr;};//weak_ptr其实也是可以转换成shared_ptr的,只是自己没有实现罢了

删除定制器

在智能指针使用过程中,可以会有new[]或者malloc出来的空间,这些空间用delete根本不行–此时就需要删除定制器了
库里面的话,是给unique_ptrshared_ptr配备了删除定制器的

这里的话,自己模拟实现一下shared_ptr的删除定制器(在上面的模拟实现里面自己写了的)

作业部分

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

Read more

超酷!前端人必备的 3 个 Skills:搞定高级 UI,拿捏最佳实践,最后一个直接拉满“续航”!

最近和几位前端开发者聊天,发现一个有趣的现象:AI 写代码越来越快,但代码质量的差距反而越来越大。 有人用 Cursor 写出来的页面,一眼就能看出是 AI 生成的——紫色渐变背景、Inter 字体、千篇一律的卡片布局。而有的人用同样的工具,却能产出让人眼前一亮的作品。 差距在哪里?不在 AI 工具本身,而在于你给 AI 注入了什么样的"技能包" 。 今天想分享前端开发必备的三个 Skills。前两个是干货分享,能立刻提升你的代码质量;第三个可能出乎你的意料,但确实是我最近的真实体会。 Skill 1: 让 AI 懂设计,告别"AI 味"的界面 你有没有遇到过这种情况——AI 生成的页面虽然能用,但总觉得哪里不对劲? 布局平庸、配色单调、

By Ne0inhk
基于 Spring Boot 的 Web 三大核心交互案例精讲

基于 Spring Boot 的 Web 三大核心交互案例精讲

—知识点专栏——JavaEE专栏— 作为 Spring Boot 初学者,理解后端接口的编写和前端页面的交互至关重要。本文将通过三个经典的 Web 案例——表单提交、AJAX 登录与状态管理、以及 JSON 数据交互——带您掌握前后端联调的核心技巧和 Spring Boot 的关键注解。 1. 案例一:表单提交与参数绑定(计算求和) 本案例展示最基础、最传统的 Web 交互方式:HTML 表单提交。 1.1 后端代码:CalcController.java 使用 @RestController 简化接口编写,并通过方法参数接收表单数据。 packagecn.overthinker.springboot;importorg.springframework.web.bind.annotation.RequestMapping;importorg.springframework.

By Ne0inhk
Flutter 三方库 react 泛前端核心范式框架鸿蒙原生层生态级双向超能适配:跨时空重塑响应式单向数据流拓扑与高度精密生命周期树引擎解耦视图渲染控制中枢(适配鸿蒙 HarmonyOS ohos)

Flutter 三方库 react 泛前端核心范式框架鸿蒙原生层生态级双向超能适配:跨时空重塑响应式单向数据流拓扑与高度精密生命周期树引擎解耦视图渲染控制中枢(适配鸿蒙 HarmonyOS ohos)

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 react 泛前端核心范式框架鸿蒙原生层生态级双向超能适配:跨时空重塑响应式单向数据流拓扑与高度精密生命周期树引擎解耦视图渲染控制中枢 前言 在 OpenHarmony 的大型应用开发中,面对如分布式协同白板、复杂仪表盘或多端动态配置等业务,如何优雅地组织繁杂的交互逻辑是每个架构师的宿命。虽然 Flutter 本身已有完善的 Widget 体系,但在处理极其深度的“逻辑-视图”分离时,借鉴前端 React 思想的库可以提供更高级的抽象。react 库(注:指 Dart 生态中模拟 React 核心 API 的封装库)为开发者提供了声明式、可组合的状态管理逻辑。本文将调研其在鸿蒙端的集成实战,探索逻辑复用的新边界。 一、原理解析 / 概念介绍 1.1 基础原理/概念介绍 react

By Ne0inhk
coding ability 展开第六幕(前缀和算法——一维到二维)超详细!!!!

coding ability 展开第六幕(前缀和算法——一维到二维)超详细!!!!

文章目录 * 前言 * 前缀和 * 寻找数组的中心下标 * 思路 * 除自身以外数组的乘积 * 思路 * 总结 * 总结 前言 本专栏上一篇已经把二分查找的习题结束啦 其实核心就是找出二段性,然后找出判断条件,然后选板子二分即可 今天我们来学习新的算法知识,前缀和 关于前缀和,可能大家在蓝桥杯或者一些算法比赛都听过 其实前缀和不难的,跟我一起来看看吧 前缀和 前缀和(Prefix Sum)是一种预处理数组的方法,通过构建一个辅助数组 s,使得 s[i] 表示原数组 a 前 i 个元素的和(索引从 0 到 i-1或者 0 到 i)。 核心作用:快速计算任意区间 [l, r] 的和,时间复杂度为 O(1)

By Ne0inhk