c++智能指针shared_ptr用法_c++内存管理教程

9次阅读

shared_ptr 初始化必须用 make_shared,直接 new 构造易致内存泄漏;拷贝赋值增引用计数,归零才释放;循环引用需 weak_ptr 破;get()仅限 C 接口等极少数场景。

c++ 智能指针 shared_ptr 用法_c++ 内存管理教程

shared_ptr 初始化必须用 make_shared

直接用 new 构造 shared_ptr 是危险的,容易导致内存泄漏或异常安全问题。比如:shared_ptr p(new int(42), [](int* p) {delete p;}); 看似可控,但若构造函数中抛异常(如自定义删除器抛出),new int(42) 分配的内存就没人接管了。

正确做法永远优先用 make_shared

auto p = std::make_shared(42); auto s = std::make_shared("hello");

make_shared 一次性分配控制块和对象内存,效率更高,且天然异常安全。只有极少数场景(如需自定义删除器且无法适配 make_shared)才考虑带裸指针的构造,此时务必确保 newshared_ptr 构造在同一条表达式中、无其他可能抛异常的操作干扰。

shared_ptr 的拷贝与赋值会增加引用计数

每次拷贝、赋值、作为参数传入函数(非引用)、从函数返回,都会触发引用计数 +1;离开 作用域 或重置时 -1。计数归零才真正释放资源。

立即学习C++ 免费学习笔记(深入)”;

常见误判点:

  • 以为 std::vector<:shared_ptr>> 存的是“轻量指针”,其实每个元素都维护独立控制块 —— 大量拷贝仍开销可观
  • shared_ptr 当作普通指针传递给 C 风格 API(如 some_c_func(p.get()))后,忘了它不延长生命周期 —— 若原 shared_ptr 提前析构,get() 返回的裸指针立刻悬空
  • 循环引用:A 持有 B 的 shared_ptr,B 也持有 A 的 shared_ptr → 引用计数永不归零 → 内存泄漏

破循环引用必须用 weak_ptr 替换其中一端,例如:

struct Node {std::shared_ptr next;     std::weak_ptr prev; // 不参与计数 };

shared_ptr.get() 和 *p 的使用边界很窄

p.get() 只应出现在需要向遗留 C 接口传参、或调试打印地址等极少数场景。它返回的裸指针不具备所有权,也不影响引用计数 —— 不能拿它去 delete,也不能长期保存。

*pp-> 是安全的解引用方式,但前提是 p 非空。访问前应检查:

if (p) {std::cout << *p << "n";}

不要写 if (p.get()) —— 冗余且掩盖语义;更不要依赖隐式转换(if (p) {……} 已足够)。

reset() 和赋值 nullptr 的行为差异

p.reset()p = nullptr 效果相同:减少引用计数,若为 0 则释放资源,并将 p 置为空。但两者语义不同:

  • reset() 更明确表示“放弃所有权”,尤其适合配合自定义删除器使用(p.reset(nullptr, my_deleter)
  • p = nullptr 更符合直觉,且可链式赋值(p = q = nullptr;

注意:p.reset(p.get()) 是严重错误 —— 先释放再用已释放的指针重新构造,未定义行为。

复杂点在于:当多个 shared_ptr 指向同一对象时,任意一个调用 reset() 或赋值 nullptr,只影响自身引用计数,不影响其他副本。真正的销毁时机由最后一个存活者决定 —— 这正是它“共享”而非“独占”的本质。

text=ZqhQzanResources