C++智能指针与容器结合使用方法

落枫小哥_1782

发布时间：2025-09-18 11:01:01

584人浏览过

来源于php中文网

原创

答案：C++智能指针与容器结合使用可实现安全的内存管理。通过std::unique_ptr实现独占所有权，确保容器销毁时自动释放资源；用std::shared_ptr实现共享所有权，配合引用计数避免内存泄漏。两者均遵循RAII原则，提升异常安全性和代码清晰度。使用时需注意unique_ptr的移动语义、shared_ptr的循环引用及性能开销，推荐emplace_back和make_unique/make_shared优化构造。

c++智能指针与容器结合使用方法

C++智能指针与容器的结合使用，核心在于理解它们各自的生命周期管理机制，并选择合适的智能指针来适配容器的存储语义。说白了，就是如何让容器安全地管理那些我们通过

new

出来的动态对象，避免内存泄漏，同时又能享受C++标准库容器带来的便利。这其中涉及到的不仅仅是语法糖，更是对资源管理哲学的一种深刻实践。

解决方案

当我们需要在C++容器中存放动态分配的对象时，直接使用裸指针无疑是埋下了一颗定时炸弹。手动管理内存的复杂性，尤其是在异常发生时，极易导致内存泄漏。智能指针的引入，就是为了解决这个痛点，它利用RAII（Resource Acquisition Is Initialization）原则，将资源的生命周期与对象的生命周期绑定，从而实现自动化的内存管理。

具体到实践中，我们通常会根据对象的拥有权语义来选择

std::unique_ptr

或

std::shared_ptr

。

1. 独占所有权场景：使用

std::unique_ptr

立即学习“C++免费学习笔记（深入）”；

如果容器中的每个元素都应该独占它所指向的对象，也就是说，当元素从容器中移除或容器本身被销毁时，它所管理的对象也应该被销毁，那么

std::unique_ptr

是最佳选择。

#include <vector>
#include <memory>
#include <iostream>

class MyObject {
public:
    int id;
    MyObject(int i) : id(i) { std::cout << "MyObject " << id << " created." << std::endl; }
    ~MyObject() { std::cout << "MyObject " << id << " destroyed." << std::endl; }
    void do_something() { std::cout << "MyObject " << id << " doing something." << std::endl; }
};

// 示例：std::vector 存储 std::unique_ptr
std::vector<std::unique_ptr<MyObject>> objects;

// 添加元素
// 方式一：直接创建并移动
objects.push_back(std::make_unique<MyObject>(1));

// 方式二：使用 emplace_back，可能更高效，避免临时对象
objects.emplace_back(std::make_unique<MyObject>(2));

// 方式三：从现有 unique_ptr 移动
auto temp_ptr = std::make_unique<MyObject>(3);
objects.push_back(std::move(temp_ptr)); // temp_ptr 此时为空

// 访问元素
objects[0]->do_something();
objects.back()->do_something();

// 移除元素（例如，移除最后一个）
// 当 unique_ptr 被销毁时，它指向的对象也会被销毁
objects.pop_back(); // MyObject 3 destroyed.

// 容器销毁时，所有 MyObject 都会被销毁
// (示例中省略了 main 函数的结束，但原理一致)

这里要强调的是，

std::unique_ptr

是不可复制的，只能通过移动语义转移所有权。这意味着你不能直接将一个

unique_ptr

赋值给另一个，也不能将其作为函数参数按值传递（除非你打算转移所有权）。在容器中，这通常意味着使用

std::move

或者

emplace_back

配合

std::make_unique

来构造元素。

2. 共享所有权场景：使用

std::shared_ptr

如果多个智能指针可以共同拥有一个对象，并且只有当所有拥有者都放弃所有权时，对象才会被销毁，那么

std::shared_ptr

就是你的选择。这在需要共享数据、实现观察者模式或缓存机制时非常有用。

#include <vector>
#include <memory>
#include <iostream>

class SharedResource {
public:
    int value;
    SharedResource(int v) : value(v) { std::cout << "SharedResource " << value << " created." << std::endl; }
    ~SharedResource() { std::cout << "SharedResource " << value << " destroyed." << std::endl; }
};

// 示例：std::vector 存储 std::shared_ptr
std::vector<std::shared_ptr<SharedResource>> resources;

// 创建一个共享资源
auto s_ptr1 = std::make_shared<SharedResource>(100);

// 添加到容器，s_ptr1 和 resources[0] 现在共享所有权
resources.push_back(s_ptr1);

// 再次添加，s_ptr1, resources[0], resources[1] 都共享所有权
resources.push_back(s_ptr1);

// 也可以直接在容器中创建
resources.emplace_back(std::make_shared<SharedResource>(200));

// 此时，s_ptr1 的引用计数是 3，resources[2] 的引用计数是 1
std::cout << "s_ptr1 ref count: " << s_ptr1.use_count() << std::endl; // 输出 3

// 访问元素
resources[0]->value = 101;
std::cout << "s_ptr1 value: " << s_ptr1->value << std::endl; // 输出 101

// 移除容器中的一个元素
resources.pop_back(); // SharedResource 200 destroyed. (因为它的引用计数降为 0)
std::cout << "s_ptr1 ref count after pop_back: " << s_ptr1.use_count() << std::endl; // 输出 2

// s_ptr1 超出作用域或被重置时，如果它是最后一个拥有者，SharedResource 100 才会销毁。
// (示例中省略了 main 函数的结束)

std::shared_ptr

内部维护了一个引用计数，当这个计数降到零时，它所管理的对象才会被销毁。它的拷贝是廉价的，因为只是复制了指针和增加了引用计数。这使得它在多线程环境下尤其有用，但需要注意，它所管理的对象本身的线程安全性需要额外考虑。

为什么不直接用裸指针存放对象，智能指针能带来哪些实际好处？

说实话，我刚开始学C++的时候，对智能指针这种“额外”的东西是有点抗拒的，觉得裸指针不是挺好用的吗？

new

了就

delete

，多清晰。但真正在复杂的项目里摸爬滚打几年，尤其是在处理异常、多线程或者回调函数这些场景下，才深刻体会到裸指针带来的那种心智负担和潜在的灾难性后果。

直接用裸指针存放对象到容器里，最直接的问题就是内存泄漏。想象一下，你

std::vector<MyObject*>

里塞了一堆

new MyObject()

出来的指针，然后容器可能在某个地方

clear()

了，或者在某个函数返回时被销毁了。如果忘记对每个指针调用

delete

，那些对象就永远地躺在内存里了，直到程序结束。这还不算完，如果容器里存储的指针指向的对象被提前

delete

了，而容器里的指针还在，那么这个指针就成了悬空指针（dangling pointer），后续的访问将是未定义行为，程序随时可能崩溃。

智能指针，尤其是

std::unique_ptr

和

std::shared_ptr

，它们的出现就是为了解决这些“人祸”。它们的核心理念是RAII（Resource Acquisition Is Initialization），简单讲就是“资源在构造时获取，在析构时释放”。

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

自动化内存管理： 这是最显著的优点。你把
```
std::unique_ptr<MyObject>
```
放到容器里，当容器元素被移除、容器被销毁，或者
```
unique_ptr
```
本身被重置时，它会自动调用其内部裸指针的
```
delete
```
操作。
```
shared_ptr
```
也类似，只是它会等到最后一个引用消失时才释放。这意味着我们程序员可以把注意力更多地放在业务逻辑上，而不是繁琐且容易出错的内存管理细节上。
异常安全： 在C++中，如果一个函数在执行过程中抛出异常，那么栈上的局部变量会被正确地销毁。如果这些局部变量是智能指针，它们会负责释放所管理的内存，从而防止内存泄漏。而裸指针则不会，一旦异常抛出，后面的
```
delete
```
语句可能就永远执行不到了。
避免悬空指针和重复释放：
```
unique_ptr
```
通过移动语义确保了独占性，一个资源在任何时候都只有一个
```
unique_ptr
```
拥有。
```
shared_ptr
```
则通过引用计数来确保资源只在所有拥有者都放弃后才释放，避免了重复释放的风险。虽然
```
shared_ptr
```
在某些情况下仍可能导致循环引用，但有
```
std::weak_ptr
```
作为解决方案。
代码意图更清晰： 当你看到
```
std::vector<std::unique_ptr<MyObject>>
```
时，你立刻就知道这个容器拥有它里面对象的所有权，并且每个对象是独一无二的。而
```
std::vector<std::shared_ptr<MyObject>>
```
则表明这些对象是共享的，可能有其他地方也持有它们的引用。这种明确的语义表达，对代码的可读性和维护性是极大的提升。

所以，与其说智能指针是“额外”的，不如说它是现代C++中不可或缺的基石，它让我们的代码更健壮、更安全，也更易于理解。

在使用

std::unique_ptr

与容器时，有哪些需要注意的细节和常见误区？

std::unique_ptr

和容器的结合，在我看来是处理对象独占所有权场景的最佳实践。但它毕竟是“独占”的，这就带来了一些使用上的特殊性，如果不注意，很容易踩坑。

首先，最核心的特性是不可复制性。

std::unique_ptr

的设计理念就是“独此一份”，它不允许你通过拷贝构造或拷贝赋值来创建另一个指向相同资源的

unique_ptr

。所以，像

std::vector<std::unique_ptr<MyObject>> vec; auto p = std::make_unique<MyObject>(1); vec.push_back(p);

这样的代码是编译不过的。这是初学者最容易遇到的障碍。

要解决这个问题，你需要显式地进行所有权转移。

使用
std::move
：当你有一个已经存在的
```
unique_ptr
```
实例，想把它放入容器，或者从容器中取出来并转移所有权给另一个
```
unique_ptr
```
，就必须用
```
std::move
```
。例如：
```
vec.push_back(std::move(p));
```
。
```
std::move
```
本质上是将一个左值强制转换为右值引用，从而允许调用
```
unique_ptr
```
的移动构造函数或移动赋值运算符。执行后，原来的
```
p
```
会变成空指针。
使用
emplace_back
配合
std::make_unique
：这是我个人最推荐的方式，因为它通常更高效，避免了不必要的临时对象创建和移动。
```
vec.emplace_back(std::make_unique<MyObject>(4));
```
。
```
emplace_back
```
可以直接在容器内部构造元素，而
```
std::make_unique
```
则负责创建对象并返回一个
```
unique_ptr
```
，这个
```
unique_ptr
```
会直接被移动到容器中。

另一个常见的误区是迭代器失效与所有权转移。当你从容器中删除一个

unique_ptr

元素时，该元素所管理的对象会被自动销毁。这很棒。但如果你想“取出”一个元素，而不是销毁它，你需要一些技巧。例如，要从

std::vector<std::unique_ptr<T>>

中取出第

个元素的所有权，你不能直接

auto p = vec[i];

（这会尝试拷贝），而是应该这样做：

auto p = std::move(vec[i]);

。之后，

vec[i]

处的

unique_ptr

就变成了空指针。如果你想从容器中完全移除这个元素，同时保留所有权，你可能需要先

std::move

出来，然后用

vec.erase()

或

vec.remove()

等方法删除空指针占位符。

再者，自定义删除器。

unique_ptr

允许你指定一个自定义的删除器（deleter），这在管理非堆内存资源时非常有用，比如文件句柄、数据库连接等。例如，

std::unique_ptr<FILE, decltype(&fclose)> file_ptr(fopen("test.txt", "w"), &fclose);

。当你将这样的

unique_ptr

放入容器时，容器会正确地管理这个带有自定义删除器的智能指针。

最后，要小心容器内部的排序或重新分配操作。对于

std::vector

，当容量不足发生重新分配时，所有元素都会被移动到新的内存区域。

std::unique_ptr

的移动语义在这里工作得很好，不会有额外开销。但如果你使用像

std::list

或

std::map

这样的容器，它们有不同的内存布局和元素管理方式，但

unique_ptr

的移动语义仍然是其核心。总的来说，理解

unique_ptr

的移动语义是与容器结合使用的关键。它强制你思考所有权的转移，而不是简单的拷贝，这在编写资源安全的代码时非常有益。

何时选择

std::shared_ptr

与容器结合，它又有哪些性能或设计考量？

std::shared_ptr

与容器结合使用，通常发生在我们需要多个地方“共享”一个对象，并且这些地方都对这个对象的生命周期有贡献的场景。我个人觉得，

shared_ptr

的出现，极大地简化了某些复杂设计模式的实现，比如观察者模式、工厂模式返回共享对象，或者缓存管理。

何时选择

std::shared_ptr

：

共享所有权： 这是最核心的场景。如果一个对象不只被一个容器元素拥有，或者被容器元素拥有，同时也被其他独立的智能指针拥有，并且只有当所有拥有者都放弃所有权时，对象才应该被销毁，那么
```
shared_ptr
```
是唯一选择。
工厂函数返回对象： 当一个工厂函数创建了一个对象，并希望将所有权分配给调用者，但又允许调用者之间共享这个对象时，返回
```
std::shared_ptr
```
是常见的做法。
缓存机制： 在实现一个缓存系统时，缓存中的对象可能被多个客户端访问。当对象不再被任何客户端引用，并且缓存也决定释放它时，
```
shared_ptr
```
可以很好地管理其生命周期。
图结构或循环引用（需配合
std::weak_ptr
）：在构建图结构时，节点之间可能存在相互引用。如果都用
```
shared_ptr
```
，容易形成循环引用导致内存泄漏。此时，通常会将其中一个方向的引用设计为
```
std::weak_ptr
```
，而容器中可能存储
```
std::shared_ptr
```
。

性能或设计考量：

虽然

std::shared_ptr

带来了巨大的便利，但它并非没有代价，使用时需要权衡：

引用计数开销：
```
std::shared_ptr
```
内部维护了一个引用计数器（通常是原子操作，以支持多线程安全），每次拷贝、赋值或销毁
```
shared_ptr
```
时，都会涉及这个计数器的增减。原子操作比普通整数操作要慢，这会带来一定的性能开销。对于性能敏感的场景，如果
```
unique_ptr
```
能满足需求，优先考虑
```
unique_ptr
```
。
内存开销：
```
std::shared_ptr
```
除了存储指向对象的指针外，还需要额外存储一个控制块（control block），这个控制块包含了引用计数、弱引用计数以及自定义删除器等信息。这意味着每个
```
shared_ptr
```
实例会比裸指针或
```
unique_ptr
```
占用更多的内存。
潜在的循环引用： 这是
```
shared_ptr
```
最大的陷阱之一。如果两个或多个对象通过
```
shared_ptr
```
相互引用，形成一个环，即使外部不再有对这个环的
```
shared_ptr
```
引用，环内的对象的引用计数也永远不会降为零，导致内存泄漏。解决办法是使用
```
std::weak_ptr
```
来打破循环。
```
std::weak_ptr
```
不增加引用计数，可以观察
```
shared_ptr
```
所管理的对象，但不会阻止对象的销毁。
线程安全性：
```
std::shared_ptr
```
本身的引用计数操作是线程安全的。这意味着在多个线程中同时拷贝、赋值或销毁同一个
```
shared_ptr
```
实例是安全的。但是，
```
std::shared_ptr
```
所管理的对象本身的线程安全性不被保证。如果多个线程同时访问或修改
```
shared_ptr
```
指向的对象，你需要为该对象提供额外的同步机制（如互斥锁）。
std::make_shared
的优势：创建
```
shared_ptr
```
时，强烈建议使用
```
std::make_shared
```
而不是
```
new
```
。
```
std::make_shared
```
可以一次性分配对象和控制块所需的内存，减少了一次内存分配的开销，并且通常效率更高。例如：
```
std::vector<std::shared_ptr<MyObject>> vec; vec.emplace_back(std::make_shared<MyObject>(1));
```
。