答案：C++智能指针与容器结合使用可实现安全的内存管理。通过std::unique_ptr实现独占所有权，确保容器销毁时自动释放资源；用std::shared_ptr实现共享所有权，配合引用计数避免内存泄漏。两者均遵循RAII原则，提升异常安全性和代码清晰度。使用时需注意unique_ptr的移动语义、shared_ptr的循环引用及性能开销，推荐emplace_back和make_unique/make_shared优化构造。
C++智能指针与容器的结合使用，核心在于理解它们各自的生命周期管理机制，并选择合适的智能指针来适配容器的存储语义。说白了，就是如何让容器安全地管理那些我们通过
new
出来的动态对象，避免内存泄漏，同时又能享受C++标准库容器带来的便利。这其中涉及到的不仅仅是语法糖，更是对资源管理哲学的一种深刻实践。
解决方案
当我们需要在C++容器中存放动态分配的对象时，直接使用裸指针无疑是埋下了一颗定时炸弹。手动管理内存的复杂性，尤其是在异常发生时，极易导致内存泄漏。智能指针的引入，就是为了解决这个痛点，它利用RAII（Resource Acquisition Is Initialization）原则，将资源的生命周期与对象的生命周期绑定，从而实现自动化的内存管理。
具体到实践中，我们通常会根据对象的拥有权语义来选择
std::unique_ptr
或
std::shared_ptr
。
1. 独占所有权场景：使用
std::unique_ptr
立即学习“C++免费学习笔记（深入）”；
如果容器中的每个元素都应该独占它所指向的对象，也就是说，当元素从容器中移除或容器本身被销毁时，它所管理的对象也应该被销毁，那么
std::unique_ptr
是最佳选择。
#include #include #include 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_ptrstd::vector<std::unique_ptr> objects;// 添加元素// 方式一：直接创建并移动objects.push_back(std::make_unique(1));// 方式二：使用 emplace_back，可能更高效，避免临时对象objects.emplace_back(std::make_unique(2));// 方式三：从现有 unique_ptr 移动auto temp_ptr = std::make_unique(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 #include #include 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_ptrstd::vector<std::shared_ptr> resources;// 创建一个共享资源auto s_ptr1 = std::make_shared(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(200));// 此时，s_ptr1 的引用计数是 3，resources[2] 的引用计数是 1std::cout << "s_ptr1 ref count: " << s_ptr1.use_count() <value = 101;std::cout << "s_ptr1 value: " <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
里塞了一堆
new MyObject()
出来的指针，然后容器可能在某个地方
clear()
了，或者在某个函数返回时被销毁了。如果忘记对每个指针调用
delete
，那些对象就永远地躺在内存里了，直到程序结束。这还不算完，如果容器里存储的指针指向的对象被提前
delete
了，而容器里的指针还在，那么这个指针就成了悬空指针（dangling pointer），后续的访问将是未定义行为，程序随时可能崩溃。
智能指针，尤其是
std::unique_ptr
和
std::shared_ptr
，它们的出现就是为了解决这些“人祸”。它们的核心理念是RAII（Resource Acquisition Is Initialization），简单讲就是“资源在构造时获取，在析构时释放”。
自动化内存管理： 这是最显著的优点。你把
std::unique_ptr
放到容器里，当容器元素被移除、容器被销毁，或者
unique_ptr
本身被重置时，它会自动调用其内部裸指针的
delete
操作。
shared_ptr
也类似，只是它会等到最后一个引用消失时才释放。这意味着我们程序员可以把注意力更多地放在业务逻辑上，而不是繁琐且容易出错的内存管理细节上。异常安全： 在C++中，如果一个函数在执行过程中抛出异常，那么栈上的局部变量会被正确地销毁。如果这些局部变量是智能指针，它们会负责释放所管理的内存，从而防止内存泄漏。而裸指针则不会，一旦异常抛出，后面的
delete
语句可能就永远执行不到了。避免悬空指针和重复释放：
unique_ptr
通过移动语义确保了独占性，一个资源在任何时候都只有一个
unique_ptr
拥有。
shared_ptr
则通过引用计数来确保资源只在所有拥有者都放弃后才释放，避免了重复释放的风险。虽然
shared_ptr
在某些情况下仍可能导致循环引用，但有
std::weak_ptr
作为解决方案。代码意图更清晰： 当你看到
std::vector<std::unique_ptr>
时，你立刻就知道这个容器拥有它里面对象的所有权，并且每个对象是独一无二的。而
std::vector<std::shared_ptr>
则表明这些对象是共享的，可能有其他地方也持有它们的引用。这种明确的语义表达，对代码的可读性和维护性是极大的提升。
所以，与其说智能指针是“额外”的，不如说它是现代C++中不可或缺的基石，它让我们的代码更健壮、更安全，也更易于理解。
在使用
std::unique_ptr
std::unique_ptr
与容器时，有哪些需要注意的细节和常见误区？
std::unique_ptr
和容器的结合，在我看来是处理对象独占所有权场景的最佳实践。但它毕竟是“独占”的，这就带来了一些使用上的特殊性，如果不注意，很容易踩坑。
首先，最核心的特性是不可复制性。
std::unique_ptr
的设计理念就是“独此一份”，它不允许你通过拷贝构造或拷贝赋值来创建另一个指向相同资源的
unique_ptr
。所以，像
std::vector<std::unique_ptr> vec; auto p = std::make_unique(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(4));
。
emplace_back
可以直接在容器内部构造元素，而
std::make_unique
则负责创建对象并返回一个
unique_ptr
，这个
unique_ptr
会直接被移动到容器中。
另一个常见的误区是迭代器失效与所有权转移。当你从容器中删除一个
unique_ptr
元素时，该元素所管理的对象会被自动销毁。这很棒。但如果你想“取出”一个元素，而不是销毁它，你需要一些技巧。例如，要从
std::vector<std::unique_ptr>
中取出第
i
个元素的所有权，你不能直接
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_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
与容器结合，它又有哪些性能或设计考量？
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> vec; vec.emplace_back(std::make_shared(1));
。
在我看来，选择
shared_ptr
与容器结合，更多的是一种设计上的考量。它允许你构建更灵活、更具弹性的对象关系，但这种灵活性是以一定的性能和内存开销为代价的。在设计系统时，我总是会先问自己：这个对象真的需要被多个地方共享吗？如果不是，
unique_ptr
通常是更好的选择。如果确实需要共享，那么
shared_ptr
无疑是强大的工具，但一定要警惕循环引用和多线程访问对象本身的安全性问题。
以上就是C++智能指针与容器结合使用方法的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1475880.html
微信扫一扫 
支付宝扫一扫 
